Features

The purpose of this article is to introduce the concept of a software migration project and compare two migration methodologies.

• Manual Rewrite Migration: Leverages hand coding to rebuild the legacy codebase from scratch. Optionally this approach may also leverage a low-yield translation tool to convert the legacy application to a new code base that still requires significant manual work to take it to the desired state.
• High-Yield-Tool-Assisted Migration: Balances customization of translation tools with manual work to convert the legacy application to a new code base.

Why Migrate?
CHANGE HAPPENS
The details of every software system are defined in terms of two foundation technologies:

• The programming languages used to describe the system
• The various runtime libraries used to access external services

The programming language dictates how developers can describe data structures, interfaces, and algorithms. The libraries provide an extensive array of advanced services to the program such as data access, communications, and graphical user interface. The language and libraries are called the platform. The platform sets the rules and makes the system possible.

However, over the course of a system's lifespan, the platform can and will change: languages and libraries inevitably evolve and are replaced by next-generation technologies. Usually, the changes are gradual with an appropriate measure of backward compatibility, so we can adapt through standard maintenance activities. Sometimes, however, the changes are more radical and disruptive, so a more focused effort, called a migration project, is called for.

The Business Case for a Migration I will briefly mention that the business case for a migration is predicated on two things:

1. The migration will allow you to take advantage of the capabilities of the new platform.
2. The migration will give you access to the community and vendor support for the new platform. We will assume the new platform measurably outperforms the legacy platform in terms of capability and support, but your mileage will vary according to your specific business needs and the value you place on community support, including the supply of skilled developers. Most often, the reality of platform change is that you just have to migrate. The only question is how to do it in a timely and cost-effective fashion.

What Is a Migration Project?
An example of a migration project would be to begin with an application written in Visual Basic and (using various COM libraries) and replace it with a similar application written in C# (using the .NET Framework). The distinguishing assumptions of a typical migration project are:

1. You have a reason and ideally a clear business case to migrate your legacy system to the new platform.
2. You have to make architectural improvements as you migrate to the new platform.
3. You are actively maintaining your legacy code base.
4. You want to migrate without breaking the legacy functionality.
5. You want the new system to be more maintainable than the legacy system.
6. You want to migrate efficiently, with minimal disruption to the users of the system and other ongoing work.

It may be useful to think of a migration project as a refactoring effort.

KeyPoint
The Wikipedia defines Refactoring as the process of rewriting a computer program or other material to improve its structure or readability, while explicitly preserving its meaning or behavior. A migration is more than refactoring; it is modifying a codebase to take advantage of a new platform and to ensure that it can be efficiently maintained with the new tools.

Migration Methodologies
MANUAL REWRITE MIGRATION
A manual rewrite migration is essentially a new system build with some important effects caused by the presence of the legacy system that is being replaced. The biggest effect of the legacy system is that its code can provide some functional and technical requirements for the new system. However, migration planners must be careful not to overestimate the power of this effect. The legacy code may be very large and very complex, having emerged over a period of years. There will also be many subtle, and not so subtle, differences between the legacy and new platforms and these make manual translation very difficult. A developer can quickly get led astray by the many subtle differences and become unproductive due to the overhead of constantly switching back and forth between old and new tools and platforms. A translation tool is not typically employed on a manual rewrite, but one may be used to help developers figure out how to rewrite the code or give them a starting point. Beware that most off-the-shelf translators are low yield and they leave a tremendous amount of difficult work to be done by hand. (Sidebar 1)

The manual rewrite can be executed via a waterfall or a more iterative methodology.

WATERFALL MIGRATION
The waterfall methodology is usually not palatable because it implies a long time between the start of the project and the eventual delivery of the new system. During this time, business requirements will change - a known problem with a waterfall methodology. The changing requirements are even more troubling for a rewrite migration because the changes may have to be made in both the legacy and new systems. If you are using a changing legacy code as the specification for the rewrite, it will soon be out of date.

INCREMENTAL MIGRATION
Instead of a waterfall, you will probably want a more iterative approach or, more precisely, an incremental approach that delivers the new system through a series of migration phases (see Figure 1). In an incremental rewrite methodology, the legacy system continues to run as the new system is built, tested, and deployed. You will want to try to build the new system in a way that seamlessly integrates with the old system to avoid running redundant applications in production. The side-by-side environment will also create overhead for users trying to cope with changing rules for which application to use as functionality moves from the old to the new system. Even if you can hide the complexity from the users, the runtime environment as well as deployment and operations activities needed to support both the old and new platforms and applications may be painfully complex. (Sidebar 2)