The Components of a Migration
In our experience there are five main components to any migration: hardware migration, program/language migration, database migration, screen/presentation migration and regression testing. The hardware issues are beyond the scope of this article. These issues have components that are unique for each platform that is being migrated to or from. Suffice it to say that it is usually the decision to migrate the hardware (e.g. mainframe to NT or Unix) that drives the decision to migrate the software. While these issues are important, they are only significant for the software migration in how they affect the choices available for the other four components. For each of the remaining components there are some issues and considerations that anyone facing a migration should study. This is followed by a discussion of the methodology that has worked very well in the many migrations Progeni has been involved with over the years.
Language Migration Issues
In most migrations of legacy systems, the language is either COBOL or a proprietary 4GL such as Mantis or System Z. There have been numerous versions of COBOL and each system manufacturer created versions of COBOL that are optimized for their platform. As a result, migrating COBOL code from one platform to another can be an adventure. Also many of today's micro based COBOL products carry runtime license fees.
Likewise 4GL languages tend to be highly proprietary. The 4GLs, while often efficient to use once you know them, are often inflexible and slow to take advantage of new technologies (such as the Web). Because many of them involve a run-time interpreter, any enhancements or change in functionality MUST come from the vendor. These run-time interpreters carry most of the enhanced functionality of the programming environment. All programs make calls to the run-time to invoke various functions. This can create a system bottleneck. Another consideration is the not inconsequential run-time license costs charged by many 4GLs.
Because of the high functionality of the source language in a typical 4GL and because the implementation of this functionality is hidden in the run-time, the applications are very difficult to migrate manually. Frequently such applications are therefore not migrated but rather rewritten with the hope that all the functionality of the old system can be duplicated. In fact I only know of one 4GL that isn’t proprietary, has NO runtime fees and affords easy migration: 1Spec from The Progeni Corporation.
Database Migration Issues
Older database technologies are often difficult to use and administer. It's also becoming increasingly difficult to find DBAs who are knowledgeable in these databases. However, because they were designed and optimized specifically for the legacy systems on which they run, these database systems are often more efficient on their native platforms than even newer relational databases that run on the same system. So the migration from one database technology to another usually goes hand-in-hand with a migration to a new technology hardware platform as well. This is not necessarily a bad thing.
Screen/Presentation Migration Issues
Migration usually involves moving away from mainframe 'green screen' terminals. Since the system I/O is most likely being moved onto a Windows or Unix based monitor with GUI or Web capabilities, the inclination is to totally redesign all the current screens to take advantage of the new presentation capabilities of the GUI or Web. However, such changes can result in the need for massive changes in the underlying software and massive retraining effort for all users. Testing the new system also becomes much more difficult because transactions don’t happen in the same way as they did previously.
Testing Issues
The most important, least talked about and poorest planned component of most migrations is regression testing. Regression testing is a specialized form of system testing. Its purpose is to test a system where any changes made to that system were not intended to affect the functionality of the system. Such changes are usually a combination of hardware platform change, program language change, database change and screen/presentation change. In other words, the environment is changing, but the functionality of the system is not. When the database has been redesigned, the screens redesigned and the reports redesigned, how do you test this new system? How do you guarantee that the new system has the same functionality as the old system? It can be done, but the job is massive. Here at Progeni, we solve this problem with a product called ThreeRs, a Regression Testing tool built specifically to solve this problem.
Other General Issues
After the migration is complete, who is going to maintain this new modernized system? This is an often-overlooked issue that is of primary concern when outside consultants are hired to perform the migration. If you migrate a 4GL, IDMS, character terminal system to a Java, Oracle, Web system, all the programmers who really know the logic and functionality of the application will need extensive retraining and are, at best, novices in the new environment. If you bring in experts on the new environment they have no clue what the application is supposed to do, let alone how it does it and what business rules it follows. If you’ve redesigned the screens and transactions your experienced users are novices in the new system as well. An additional issue that often gets overlooked is the concept we call retrofit. A manual or hand coded migration tends to take a very long time, years sometimes. During this period normal updates and maintenance are going to be necessary to the old system. How and when do you integrate or retrofit these modifications into the new system?