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 "),
it won't handle the rest of your unique requirements. You should not expect to find
"COTS" migration tools that handle your unique configuration.

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.

Topics

Semantic Designs- Our Goal

To enable our customers to produce and maintain timely, robust and economical software by providing world-class Software Engineering tools using deep language and problem knowledge with high degrees of automation.