Software migration aims to replace outdated software systems with new systems that are more manageable and meet the needs and requirements of users. Nowadays, many migrations are automated (using a migration tool). Application modernisation projects are generally large and multiannual projects. Being part of the critical systems of companies, the execution of this type of project has a set of risks that have an impact on business operations. The seemingly most common approach is to do incremental modernizations. First, you often only replace the operating system (and hardware) by keeping the application code unchanged. After this migration, modernization can be continued in a phased manner, progressively reducing legacy code in favour of code converted to the new programming language.
In the end, the system will be fully converted to the new technology, and there should be no software left with dependencies of legacy technologies. The migration strategy is critical to determining how the system will continue to support the business throughout the migration and modernization effort. Decision-making in this area is a process that takes place in an organisational context. Decision-making in the “real world” of commercial organizations must usually be based on “limited rationality”. The principle of this concept is the balance between the information available inside and outside the organization, the cognitive capacity of decision-makers and the time limit for decision making.
When to Think of Software Modernization?
Software migration comes into focus as system management increasingly signals that it can no longer (simply, with limited costs) meet the ever-increasing wishes and requirements of the user organization. But keeping the current system operational is also becoming increasingly difficult and expensive, as there are fewer and fewer experts who still have sufficient knowledge of the outdated system and the outdated hardware infrastructure is increasingly difficult to obtain.
---
All software systems can migrate to modern environments. But migration is most useful with old systems, such as COBOL systems and old VB6 systems, as these are often mission-critical systems and have a major impact on the organization. Most migrations are carried out to a .NET variant. For example, COBOL systems can be migrated to COBOL.NET and VB6 systems to VB.NET or ASP.NET.
Why Migrate?
Purchasing standard packages is often not enough because most standard packages only cover some of the required functionality. The organization has to adapt to the software, if at all possible. Most companies can’t get away with standard packages and look at customization. Customization can provide all the necessary functionality, but is often expensive, requires a long development and testing process and has a big impact on the organization.
How to Migrate?
Most migrations are performed using a migration tool. This has considerably less impact on the organization than new construction and is considerably cheaper. However, a disadvantage of migration, especially compared to new construction, is that it is not usually used for all the modern functionality of the new environment.
COBOL software migrates to .NET using a tool (e.g. Application Development Framework (ADF) from COSS-Solutions. The COBOL programs are stripped of all ballast as screen handling, key handling, file and database approach etc. These cases are taken over by .NET. The business logic, which can often be maintained by our people, remains and becomes in .NET classes.
VB6 migrations also use a migration tool. There are tools which can migrate VB6 to VB.NET, ASP.NET, C#.NET and C++. These tools can be added as add-ins to Visual Studio 2008. They include a GUI generator, error handler, modules-to-class converter, goto-remover, etc. The migration tools enforce programming standards, and migration to .NET also involves converting the software to an object-oriented structure.
The Benefits of Migrating
When COBOL systems are migrated, it is immediately noticeable that the business logic (the heart of a COBOL program) is still maintainable by the old “cobblers” within the organization. Within a week, they have usually mastered the use of Visual Studio and can continue their work. Users are free of the old-fashioned, character-oriented green screens and get screens and menus like in Windows. They can use the mouse which makes the screen a lot more user-friendly. Authorizations are now regulated by default (within .NET) and removed from the COBOL software. This significantly simplifies management and increases reliability. The software now finds a connection with modern developments such as intranet and internet.
Vb6’s support was finally stopped in March 2008. There are no more new developments. Also, the structure of VB6 software is not object-oriented and VB6 is not really “web-based”: this can only be achieved with ActiveX controls. Migrating to VB.NET or ASP.NET will permanently solve this problem.
