Legacy Migration

Semantic Designs provides tools and services to help migrate legacy systems to new languages such as Java, C# and technologies such as web, mobile apps and SQL.

Legacy means "successful". Legacy software runs companies, and cannot simply be waved away with a magic wand. Whatever the legacy software does must be preserved. Legacy systems are successful and therefore mature, and likely have been in existence for a long period of time.

A consequence is that legacy software is built using technologies available at the time it was constructed, as opposed to the most modern software technologies. Older technologies are more difficult to maintain, and this is a key point of pain for many legacy system owners.

Often, an application may need restructuring to meet other business goals. That topic is explored in more detail under Software Modernization. Here our attention is focused on migrating legacy technology to new langauage.

Manual Versus Automated Migration

Legacy systems were built by manual methods, and it is what the IT organizations know how to do. So it is natural that a migration by manual methods is almost always proposed. These usually don't turn out well, for several reasons.

Cost of doing a manual migration: The Gartner Group notes that the cost for manual code conversion can range from $6 - $26 per LOC and is accomplished at a rate of 160 LOC per day (Gartner Group study "Forecasting the Worldwide IT Services Industry: 1999,1"). An assumption is that the migration is going between two relatively similar languages (e.g., not trying to go from COBOL to full object-oriented Java). Using Gartner's numbers, a million lines of code costs $6-$26 million to migrate.
Time to do a manual migration: Again, using Gartner's numbers, a legacy system with a million lines of code requires some 28+ man-years of labor to convert. With a team of 10, this takes 3 elapsed years if done well. With larger systems, one has larger teams. Larger teams require more interactions, slowing them down further. A 10 million line application simply doesn't have any practical manual migration due to time frames.
Scope creep: Because manual migrations are long and expensive, it is very difficult to resist adding new functionality and requirements during the project. The migration task gets longer and riskier, and it is much more difficult to test the result for completeness, because it no longer does what the existing legacy system does.
Conflicting goals: While the migration team is attempting to build a replacement, the legacy system must still continue to support the company. It must evolve to meet corporate needs, and so changes are continually made to it. Such changes are trouble for the migration team, which now has to go back and rework code already converted. This creates pressure from the migration team to stop legacy system evolution, which is not good for the company.
Inability to change course meaningfully: No plan survives intact. During the migration, the company goals will change, the migration team will learn how to handle parts of the conversion better, and migration mistakes will be made and uncovered. The problem is that hand-converted code contains the assumptions that were valid, and the mistakes made, at the time of the hand-conversion, and it is painful to go back and change these modules. So, the migrated system either does not take in account new directions or better understanding of the task, or it takes longer to do at higher risk.
Uneven conversion quality: A migration accomplished manually depends on the individual skills of the team members. Some are naturally better or worse than others. The resulting code quality will consequently vary, raising maintenance costs for the converted system.

A better approach is automated conversion. One needs strong automation to meet economic and time frame objectives. An automated conversion address the above issues in the following way:

Lower cost: SD can do conversions for between $1 and $4 per line, depending on complexity and number of languages involved.
Shorter time: Such migrations typically take between 9 and 18 months, with very large systems practical in 2 years.
Scope creep:An automated migration does not add functionality. Functionality scope creep in the migration does not occur. (We note that the migration tool can make it easier for new functionality to get added after migration is completed by biasing the migration to support structures needed by the new functionality).
No conflicting goals:The legacy software maintenance team can add new functionality during the migration, and the migration tool will convert that, as it is applied at the end of the process. Or, the functionality can be added after the migration.
Course changes are easier: An automated migration is based on a set of constructed migration rules, which are applied to the entire legacy system during the final migration step. As the migration team learns of new techniques or new directions, these rules can be adjusted, and thus applied at the end point.
Clean, good code quality: The migration rules in effect enforce a consistent "style" across the entire system. They can be adjusted to change the style. Some migration rules focus on converting the language concepts accurately; this ensures a reliable translation. Some migration rules focus on "cleaning up" awkward resulting constructs, ensuring clean, readable code.

The bottom line is that automated migrations lower costs, time, and risks, and raise the quality of the result.

Custom Translation Tools

It is the case the every organization's migration task is unique. It has a unique set of legacy technologies (languages, databases, screens, job control, security, OS) and a unique set of target technologies (same list). While it generally easy to find some COTS tool that processes the language you have (Google "migrate "), it won't handle the rest of your unique requirements. You should not expect to find "COTS" migration tools that handle your unique configuration.

Semantic Designs can design and implement custom translators to meet the requirements of the customer's migration task, including language/dialect translation and API changes.

Assessment and Planning

Any large migration requires careful planning and support. Semantic Designs can

Define an effective, economical porting plan which minimizes risk
Find/remove redundant code before conversion to minimize total conversion costs
Carry out automated assessments of a source code base for troublesome constructs
Design reliable translations for each source construct or API call
Provide tools to help determine how well the converted application has been tested.

To discuss migrations in more detail, contact us. Details about time frame, the set of legacy programming languages, SLOC for each type, other legacy technologies, and desired modern target system are extremely helpful.