Why traditional re-hosting your mainframe won’t free you from vendor lock-inJune 4, 2021
Many businesses are losing their taste for mainframes. A volatile world demands an agile IT model and the mainframe—with its heavy licensing and maintenance costs, rigid impenetrability, and reliance on niche programming skills—no longer offers the flexibility and openness that most businesses need.
But it’s no secret that mainframe modernization can be expensive and disruptive. For this reason, many businesses look to re-hosting—where mainframe applications are migrated as-is to a new piece of modernized hardware—as an easy fix solution. This allows them to switch off old hardware and redundant apps to save immediate cost, adopt a more modern distributed IT model as their core architecture and break free from IBM license fees and vendor lock-in.
However vendor lock-in isn’t so simple to avoid, and despite other gains, businesses undertaking mainframe rehosting projects can quickly find themselves breaking free from one lock-in, only to become entrapped in another.
The problem lies in the rehosting approach itself. Mainframe code is complex and unique to the business that developed it and applications often have intricate interdependencies, making the code difficult to unravel. Rehosters address this issue by preserving the mainframe environment on the new hardware using emulation software. This essentially means that the new environment behaves exactly as the old one did, with the code itself remaining largely unchanged. It also means you must keep emulating the environment indefinitely in order to keep using the mainframe apps—and you must do it at cost by buying specific emulation software from your rehosting provider.
There are other issues too: tie-ins to the re-hoster’s migration software usually take away the ability to shop around and the added middleware may cause a drop in performance that must be rectified at additional cost. There are likely to be at least some differences and interdependency issues in the new environment, which means you still need to undertake testing as you would for a more complex refactoring solution. Last but not least, if you later decide to develop or modernize your applications (for example, to run them in the Cloud), you will still need to rewrite the code: it’s essentially starting from square one again.
So, what then is the solution? Simply accepting the limitations and expense of the mainframe and keeping it? Accepting the lock-ins and pitfalls of a faster, cheaper rehosting project? Or giving into a high-risk, high-cost decade-long mainframe rewrite project?
You can, in fact, choose to do none of these. Mainframe modernization is not as rigid as it once was. The technology now exists to automatically convert mainframe code into modern, open-source languages without the need for emulation. This means it can be quickly rehosted in a new environment (such as on an x86 server or the cloud), without the need for additional emulation software, and it will be primed for development using modern coding practices right from day one.
Download our e-Book to find out more about we can help you solve the rehosting riddle, and how Asysco is using unique code conversion technology to provide all of the quick-fix benefits of rehosting, without the long-term lock-in.