In business, just like life, there are always choices. When they are presented to us, it can be challenging to make the correct decision. When you are faced with an opportunity for legacy modernization, most sources will tell you about your three options. We at Three Wire want to make sure you know about the fourth option.

Your first option is replacement with a commercial off-the-shelf (COTS) product. Buy something or leverage shared services that is ready-made for commodity functionality processes and invest in customizations to make it work for you. A good example is accounting software. Numerous offerings exist, and since accounting and payroll functions are generally the same between organizations, the off-the-shelf software or shared services can be an economical way to push out the old and bring in the new. COTS is not going to be the right approach for you if you’re looking at replacing functionality which is unique or not available as a shared service.

That brings us to our next modernization option: a rewrite. Rewrites are usually higher cost and involve more risk, but if what you have no longer meets your mission goals and has many architectural challenges, a rewrite is an option. This option includes building the application in a modern language and architecture from the ground up, and gives you the time to consider integrations and opportunities for additional functionality along the way to re-align to your current mission goals. These applications can also be designed to be deployed in the cloud to take full advantage of elasticity and scalability. These types of projects are often costly, and it can take months and even years to complete the overhaul. Considering the scale of the project, your available resources, your budget…you need to consider the cost/benefit carefully.

The third option is a lighter take on a rewrite: refactoring. Cheaper and faster, refactoring can range from using a tool to convert legacy code to a new programming language to encapsulating the core functionality of the existing legacy application into easily consumable services. This option is best for situations where the functionality is not an issue but the technology is a problem. While this option is generally less expensive, it is not without risk.

The fourth option, an option you may not be aware of and often is not well understood, is rehosting. Think of an old car. The vehicle drives well from one side of town to the other. You love that old car and it does the job it needs to do, but the cassette deck needs to be upgraded and you’d love to have a new GPS feature. You can spend 70% less by updating the old car rather than replacing it, and in the end, you can get what you need. Rehosting allows you to keep applications which are doing what you need, but happen to operate on an outdated or costly platform such as a mainframe. Rehosting is keeping the application code in-tact and making as little change as possible to “lift and shift” the code to a new lower cost operating environment. This has the benefit of lower risk to implement and significant savings in operating expenses. Savings you can re-invest in other modernization initiatives.

It’s expensive to maintain a legacy mainframe system. You pay for high cost licensing and the constant upgrading to meet your organization’s growing needs. By moving the legacy system to the cloud, you get the benefits of modern computer architecture without the huge costs that are required to program a customized system in a modern language.

The fourth option is often the best for legacy mainframe systems, especially government agencies. A key benefit for these types of organizations is that functionality is virtually the same and end users will see little to no change. So, you can achieve significant savings without the headache of an entire rewrite, something that many government organizations cannot afford to do anyway.

Finally, the fourth option can be achieved in a fraction of the time and cost of the other options. You don’t have to hire a massive team to custom code the application or worry about the bugs that await you after the code conversion is complete. You get what you need, with the updates you wanted.

As an added benefit, more programmers can now work within a legacy system. Most COBOL and other legacy language programmers are retiring. Young programmers find a mainframe to be a foreign environment. When the system is hosted in modern architecture, young programmers are more likely to take on a legacy code project using the integrated development environments they are familiar with such as Visual Studio or Eclipse. Challenge your talented, young programmers to understand and work within the logic of a legacy system built around a modern architecture and can participate in a standard Dev Ops framework.

Share This Post