Builder AU technical editor, David McAmis, takes a closer look at the steps you need to take to successfully migrate legacy applications.

As the cost of maintaining custom legacy applications increases, there are now a number of low-cost application servers that can be used to migrate these applications to other platforms and lower the total cost of ownership (TCO). In this article, we will take a look at the steps required to successfully migrate a legacy application to a more cost-effective platform for both development and maintenance costs.

Step 1: Documenting the Existing System

If we were to look at the Software Development Life Cycle, a key part of the process is actually gathering requirements from users on the functionality that they need in the application you will eventually build. In the case of migrating a legacy application, the process is slightly different, as you will need to perform analysis on the existing system to understand how it works, who uses it, what they use it for.

A good starting point for gathering this information is in the existing documentation for the system you want to migrate. This documentation could take the form of the original specifications for the application, as well as the systems design and documentation produced once the application was completed. Often this information will be missing or incomplete with legacy applications, as there may be some time between when the application was first developed and now.

You may also find crucial information in other forms of documentation, including guides, manuals, tutorials, training materials, etc. that end-users may have used. Most often this type of material will provide background information on the functionality exposed to end-users but may not provide details of how the underlying processes work.

For this part of the analysis, you will actually need to review and document the existing code. This may be difficult, depending on the legacy platform you are working with. For example, if you are migrating an AS/400 application written in RPG, you will definitely require some assistance from an experienced RPG programmer if you do not have those skills internally.

This can be an expensive part of the analysis process, as you may need to hire a resource to perform this analysis for you, but it is a vital part of the process, especially if the application has been running and maintained over a long period of time. There may be undocumented code or fixes that are critical to the application and that have not documented anywhere else.

Another key area to examine is how the data in the legacy system is stored. Is it stored in flat files, files or tables? What fields are included in those files/tables and what indexes are in use? Also, perform a detailed analysis of any server processes that are running that may be related to the data—for example, if there is a nightly process that runs across a file and updates it from other system

2. Requirements Analysis

The next step in the migration process is to perform a detailed requirements analysis to determine what features are required in the new application. At a very basic level, the features and functionality that are in the legacy system should be included and you should perform interviews with the users and system administrators to see what features are required.

This area of the migration is frequently where the cost and scope of the project can increase if you do not manage this process. Often, the move from a legacy system to another platform is driven by the request for new features that a legacy application can not provide or where the cost of providing these features would be prohibitive.

In this situation, users will often use this exercise to include features that they may have wanted in the past that have been too costly or cumbersome to implement and may blow the scope of the migration project. A key point to get across to users is that the first step is a migration of existing features and functionality to a new platform.

The most effective way of cutting over to a new platform is to ensure that the application supports the existing features and functionality first before adding anything new. Is it tempting to add features with the mentality of -while we are at it” but this can be a point of failure if those new features slow or halt development of core functionality that the business requires.

A good way to limit the scope of the migration project is through the development of Use Cases that detail how the legacy system is currently being used. You can then use these Use Cases to design your new application and ensure that the exact functionality offered in the legacy system is included in your application.

3. Platform Selection

With an understanding of how the application is being used and the code behind it, as well as the user requirements, you can then select a platform for the migrated application. With legacy applications, this decision was most likely made on a consolidated platform where the application logic and data both resided on the same platform. With modern applications, the application logic and data are usually separated into two distinct components, so you will need to decide on both an application and database platform.

The major decision to be made on the application platform is whether the migrated application will be a -fat” client application, installed locally on each user’s computer or whether it will be a Web application that the user can run from their browser. While current trends lean toward replacing desktop applications with web-based versions, there may be some functionality that can not be easily replicated in a Web application.

For example you could have a mainframe application that performs complex statistical analysis as you change program parameters and then returns a result set to the user, with calculations running 4-5 minutes each time. In a Web environment, this may not be possible as the Web browser may time out before the result set could be returned. So in this case you would have two choices—you could either provide this functionality using another method that suits Web applications (i.e. posting the parameters to a form and then have the user visit another page to retrieve the results) or consider deploying a Windows application, which would allow you to have similar functionality.

In addition to the -fat” vs. -thin” debate, there is also a development language to be selected. You may currently have a corporate standard development environment that you can use or you could use this as an opportunity to establish a new project. When considering a programming platform, make sure that you include the cost of servers in your evaluation. Will you need to buy additional servers or can the application be hosted on current hardware? Will the application be scalable and meet your needs in the future or will you need to add additional servers to support users? All of these issues should influence your decision.

From the data side, you will need to select a database platform that can support the application you plan to create, as well as hold any existing data you want to migrate over from the legacy system. The database platform should lend itself to the application platform you have selected – for example, if you are planning on creating a .NET web application, there are definitely advantages to using a database that has .NET integration, which include SQL Server, Oracle, DB2, etc.

You should also look the amount of behind-the-scenes processing that was contained within the legacy system and make sure that your selected database platform can support the required load.

4. Design, Development and Deployment

Finally, with the system requirements ironed out and the application and database platform you can start the detailed design and development phase of the migration, where you actually create the detailed design document for the system you are migrating to and start development.

Another key to a successful migration is ensuring that you do a thorough detailed design that encompasses the current functionality in the legacy system and user requirements. User should be able to take the screen designs from your detailed designs and walk through the tasks they would normally carry out in the legacy system you are replacing. When looking at the detailed design, do a check by walking through the use cases you originally created off of the legacy app and ensure that there the new application supports all relevant cases.

Also during the development phase keep the development team focused on the detailed design you have created and perform frequent test migrations of data to ensure that the new application is ready to go live when you are ready to cutover. Before the final cutover point you should run both systems in parallel to ensure that there are no critical gaps in support for the business. It may be tempting to go with a straight cut-over from the old to new system, but there is a risk that the new system may not provide the functionality required or may have critical errors that prevent users from using it.

It is best to run the systems in parallel through a normal processing cycle—for example, if you are replacing an order entry system that performs month-end processing, make sure that you run both systems through the entire process. Once you are satisfied that the new application is fully functional, you should leave the legacy application and platform up and running for the next few months. And before you finally pull the plug, make sure that you have a complete backup of all of the relevant data and applications and that you have a way to access this information when required.

So with a bit of careful planning you can migrate legacy applications to a platform with a lower cost of ownership, both from the support and development perspective.