Legacy Software Migration
Semantic Designs provides highly automated tools and services to help migrate legacy systems to new languages such as Java and C# and modern technologies such as web 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 atttention is focused on migrating legacy technology to new langauages.
Motivation for Migration
There are a variety of reason that a migration of a legacy system may be needed:
- Legacy languages are hard to support.The legacy languages and development tools needed to support the legacy system are increasingly difficult or expensive to obtain. This is a very common occurence with 4GLs popular in the 1970s.
- People are scarce. People that know the legacy languages and technologies are becoming difficult to find and retain. Younger staff are reluctant to learn legacy systems because it does not appear to advance their long-term career.
- The underlying platform is hard to support. Many legacy systems run on legacy hardware systems. Such hardware systems are becoming more expensive to maintain, and personnel that know these systems are also more difficult to find.
- Legacy software does not integrate well with other IT systems. The architecture of legacy languages often does not lend itself to building bridges to other IT systems that have grown up around it.
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"). 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 timeframe 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
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. Our JOVIAL2C translator is a typical example of such a migration tool, customized for the Northrop Grumman B-2.
SD's generalized compiler technology, The DMS™ Software Reengineering Toolkit provides a proven foundation for implementing such custom translators. DMS can handle multiple source and target languages, and scales to handle systems with millions of lines of code. SD's existing library of standard language front-ends for DMS significantly minimizes the cost of building a translator.
Migrating from Natural/ADABAS?
Migrating from Visual Basic 6?
Choosing A Migration Vendor and Technology
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 timeframe, the set of legacy programming languages, SLOC for each type, other legacy technologies, and desired modern target system are extremely helpful.
Industry Ranking by InfoTech Research
Here we provide InfoTech Research Group's independent vendor assessment:
Vendor Landscape Report for Legacy Modernization services
(published with permission).
We are naturally pleased to be top-ranked in terms of Overall Product, Usability, Viability, and Reach (slide 7), as well as Features (slide 20).
