It’s not magic

Don Estes

Don Estes

Don Estes is an IT management and technical consultant with special expertise in large scale legacy modernization projects.

An automated modernization project, also referred to as a “conversion”,  “migration”, “legacy revitalization” or “legacy renewal” project, is inherently different from most projects in which  IT professionals will participate during their careers, and in several different ways.  When this specialized type of project goes awry, it is almost always from a failure to appreciate these differences and to allow for them in the project plan.

Properly controlled, an automated modernization project should be the least risky of any major project, but a failure to implement the proper controls can make it a very risky project indeed.  Automated modernization projects obtain their substantial cost savings and short delivery schedules by extracting highly leveraged results from the automation.  However, it is easy to forget that a lever has two arms, and – improperly implemented – you can find leverage working against you rather than for you in your project.

When there is residual value in a legacy application, an automated modernization project can extract and use that value in a highly cost/effective manner. Of course, in some cases this is futile, but in many if not most projects it has significant technical and financial merit. There are 3 important technical strategies:

  1. When the business rules expressed in a legacy system still fit the business process, but have a problem with software infrastructure (e.g., database, “green screen” interface, language, hardware platform, etc.), there is usually a fast, cheap and low risk way to deal with the problem, applying technology to renovate the code base into supporting the target configuration.
  2. When legacy systems partially fit the current business process but need significant functional expansion or modification, a re-engineering approach may make more sense. This way the original system is reproduced identically in totally new technology, then re-factored according to agile principles to meet the new requirements. Though counterintuitive to some, this approach is faster, cheaper and lower risk than taking a blank sheet of paper and starting over – because at every point in the project you have a fully functional system.
  3. When maintenance costs are high in a legacy application, it is possible to logically restructure the application to reduce the effort of maintenance programming. This is usually very cost/effective. Depending on how bad the code is, maintenance cost reductions of as much as 40% are possible, though this approach has the best results for the worst systems.

Anyone considering a modernization in isolation, and particularly anyone considering a modernization versus a replacement, should carefully weigh the risks. In the projects we have seen, the success rate is very high even for large projects, far more than the replacement approach. It is our firm conviction that if the issues discussed in this essay are adequately taken into account in modernization projects, the success rate will be 100%.

For more information, see Don’s essay on automated modernization: It’s Not Magic

Comments are closed.