Many IT professionals believe if it isn’t broken don't fix it. A recent survey found that 50% to 60% of core processes in some verticals still run on mainframe systems using legacy, often poorly maintained software. After all, it still works.
Resistance to modernization does not come only from an “if it isn’t broken” attitude. Change brings risk, so it might appear prudent to delay major infrastructure changes. Also, many large organizations have sizeable investments in mainframes loaded with years of accumulated data and that data may have been incorporated into monolithic mainframe software applications.
So: Risk. Disruption. Cost of new hardware. Cost of software replacement. Difficulty of restructuring data. Disrupted procedures and core processes. Sometimes it seems the balance tips towards “kick the can down the road” and so you put off taking real action.
But sooner or later, “old stuff” in a technology age becomes a liability. Conversion costs rise as competitors with newer tech eat away at your markets. Qualified support personnel may retire or move on and your old vendors may no longer be available. You’re left without needed support for your big iron and COBOL or PS1 applications. You’re flooded with complaints from unhappy users of the mainframe, while upgrade costs grow out of line with available budget.
Further, on the business side, growth may outstrip processing capacity so your business users suffer long delays and cannot always placate customers unhappy with ever slower product deliveries. Mergers, acquisitions, or deferred past IT investments may also add legacy systems you never anticipated, slowing responses to business requests.
It’s simply time to modernize.
Take a Step at a Time
To minimize cost and difficulty, take modernization in a series of small steps and don’t be rushed. You can replicate a nonessential application as a pilot. You don’t have to actually cutover data operations until you gain full control. A stepwise approach lets you plan ahead for strategic hardware and software investments and keep to a practical schedule.
Look at the technical stability or risk of components — what is a program’s actual value to your organization? When you understand how your software contributes to your success, you can prioritize your replacement decisions.
For example, while it would be wonderful to snap your fingers and suddenly find your mainframe app fully modernized, you know that won’t happen. You can completely rewrite your applications, but there are large, measurable risks in that approach. One way to mitigate the risk of modernizing is to move forward in steps.
In our experience, the biggest goal for most organizations is to update the infrastructure and host system. Rewriting the application is only a secondary goal. In other words, getting the mainframe infrastructure transformed to a SQL database and application tiers which can be hosted on an x86 system is a giant step and, by itself, offers huge advantages.
A typical stepwise process conducted by TmaxSoft looks like Figure 1.
A Stepwise Approach to Modernizing
Breaking your processes into logical pieces can be challenging but is well worthwhile. Look at the technical stability or risk of components — what is a program’s actual value to your organization? When you understand how your software contributes to your success, you can prioritize your replacement decisions. Do the same with your hardware components and systems. You’ll then have a good idea of which components you need to modernize first.
Rehosting in the Cloud
The Cloud has greatly eased how companies modernize legacy systems. The Cloud’s considerable cost benefits have also made modernization essential now to staying competitive, as analysts have pointed out for some years now.
To leverage new technologies, there are two deployment models to consider. The first is an on-premises deployment utilizing industry standard x86 systems. A second approach is to host the same environment within a cloud provider. This leapfrogs the on-premises modernization directly to the cloud.
In either situation, the original mainframe applications are themselves not changed, making testing, deployment, and user acceptance much easier and less risky.
When you save on new application costs, you directly reduce the cost of modernization.
Conclusion
Organizations benefit when they resist seeing modernization as a “one-off” project where progress and innovation stop at the end. It’s better to embrace modernization as a cycle, not a project. When you take a portfolio approach, you need only a strategic few of your applications to make a solid beginning.