Why Rewriting Legacy Applications Can Be a Costly Mistake and How to Avoid It

by Kelly McClure, Vice President of Global Marketing

The Toyota Production System: An Integrated Approach to Just-in-Time is three decades old, is still used around the world as a guide for everything from manufacturing to Agile software development methods and is now in its fourth edition. In these days of the eBook and e-readers, people might not realize what it was like to publish the second edition of an important book like this in the early 1990s. The author re-typed or marked up the original manuscript for an editor. The editor revised it with a red pen or pencil, someone typed up the final version, and then off it went to a typographer. The typographer created typescript in the right font, which the editor or proofreader reviewed for errors. Meanwhile, an illustrator created graphics for rendering. Someone in production took the typescript and illustrations and cut them up, gluing them to “art boards” to design the layout of the book. The art boards went to a printer, the printer created “bluelines,” which were proofread by the publisher, and if there were any corrections again, the process would require new bluelines. The price was high: changes to the bluelines were charged by the letter.

Nowadays, this whole process is digitalized. This has reduced costs significantly and made a big difference in the time it takes to get a book to market. In the case of the Toyota Production System, it’s helped it live on and inspire generations. The words are the same, but it’s in a different, more modern package. No one publishes books the old way anymore.

Why should modernizing the applications on your mainframe be any different? And yet, today, IT organizations are hearing that they should treat their legacy applications like a manuscript from the 1960s. This will most likely turn into a costly mistake. Let’s look at why and how to avoid it.

A Long, Dark and Twisted Road to Nowhere

Around the world, enterprises are realizing that competitive differentiation means modernizing applications and infrastructure. Also, with GDPR and other data privacy measures being put in place globally, they need to modernize to be compliant. Yet, 90 percent of the enterprises running their core business on a mainframe are struggling to deliver modern applications as fast as they’re needed.

As a result, there is a temptation to take a path that many say is wise and forward-thinking: rewriting the mainframe applications as part of a move to an open, cloud environment. As it turns out, that path can be a long, dark, and twisted road that uses up all your traveling expenses and is likely to be a dead end. In fact, according to both Standish Group and Gartner reports, more than 70 percent of legacy application rewrites are not successful. One of the most famous is IBM’s rewrite of the old payroll software used by Queensland Health in Australia. The project cost $6 million and failed when it was rolled out, so that employee pay was in chaos. It is estimated that this cost the Queensland government $1.2 billion.

Why don’t these projects pan out? There are several reasons.

Application Logic, Coding, Testing

Rewriting a business application is as arduous as the old process of republishing a manuscript, if not more so. To rewrite a business application, someone must interpret existing application logic based on business processes properly and then rewrite them in a new code base, often by hand. Databases and data also have to be translated. If IT teams make it past the coding and logic hurdle, the next challenge or obstacle is differences in hardware and operating systems. When this had to be done for multiple applications, the whole rewriting and recoding project can take years; after that comes extensive and lengthy user testing. The chances of extensive delays, data loss, cost overruns, or errors are high, and just one error in millions of lines of code can be disaster.

Age and Support

Then there’s the fact that some applications on the mainframe may be 20 years old or older. In many cases the original owners, programmers, vendors, or details of these apps may be long gone and unidentifiable. These outdated applications can be a drag on mainframe performance and supporting them can be costly. Trying to rewrite these in any semblance of modernity can be almost impossible because of their spaghetti architectures and customizations. Yet, they can’t be discarded because they are still needed. If a mainframe has been in operation for a quarter of a century or more (and most have), an overhaul of this magnitude can have a major negative impact on the business.

The Expense of Rewriting Legacy Apps

Legacy app rewriting is likely to require additional IT resources with skills in the modern languages, technology, and coding required to meet the demands of modern business. Dozens to hundreds of complex COBOL, Assembler, or PL/I applications must be replaced, each of which can be 20,000 lines of code long, along with applications written in languages like Java, Ruby, PHP, and a host of new technology for mobile. And that’s just the source code part; there will be rearchitecting, database work, and the overlay of unknown interdependencies to add to the complexity. The overhead for the project can quickly get out of control as the different groups work to make the rewrite happen—all with no guarantees of success.

A mainframe rewrite is expensive on so many levels (infrastructure, resources, time, effort, and spend) and is not guaranteed to lower costs over the long term. Maintaining a mainframe can run in the millions annually for large firms, and that’s before factoring in the costs of re-developing, rearchitecting, translating, testing, and so on. For example, 10 years ago, according to Capers Jones, the cost of rewriting just one mainframe program could be as high as $495,000. Translate that into 2018 dollars and you get $580,378. When you multiply that by IBM’s lowest estimate of applications on a mainframe, 12, the result is almost $7 million.

Who wants to take such a big financial risk on something that has less than a 30% chance of success?

How to Avoid the High Cost of Rewriting

Re-platforming legacy mainframe apps is a more cost-effective solution to rewriting with a much higher percentage of success. Because applications are not being rewritten, there is no change in business logic, interface or function.

How does it work? The apps move to a less expensive, open system environment, improving mainframe performance until these outdated applications can be replaced with newer, better options. Modernizing core IT systems to incrementally improve them comes with much fewer risks of project failure compared with starting fresh with a rewrite. Not only that, but those IT leaders who have re-platformed report that it is easier to optimize and re-architect legacy applications once they’re already running in an open system or in the cloud. For starters, one of the most complex aspects of modernizing the data and migrating the application to open systems has been done through rehosting, and in the future will make doing a rewrite less complex and risky.

The secret to an even higher success rate is choosing the right solution for re-platforming. Look for one that enables you to take the legacy source code, recompile the programs in a new environment without changes to the business logic, and then migrate the mainframe data into a new, more modern database environment. You can reuse existing security profiles, online and batch configurations and definitions, and data set system management profiles.

The Choice is Clear

Even if you had the budget, time, and resources for a full-on, massive re-write project, why would you invest all that in something if there is a better, faster option with a higher success rate? It would be like deciding to toss out all the word processing, design, imaging, and printing software and applications that make it easy to publish a new edition of a book so you can return to the old process. And, to be honest, at least the publisher has a chance to recoup some of that overhead through book sales. Even so, they are unlikely to take that risk. Shouldn’t you do the same for your business?

To Learn More

TmaxSoft OpenFrame is a rehosting platform that has a 100% project success rate. The software is proven with solid references. The migrations are low-risk, and they’re fast compared to other modernization alternatives. Most OpenFrame projects can be completed in 6 to 12 months. Check out our Mainframe Rehosting 101 to learn more.

About Kelly McClure

Kelly McClure is the Vice President of Global Marketing for TmaxSoft. Her 20-year marketing career spans both Fortune 1000 companies and fast growth technology startups. Kelly is responsible for leading TmaxSoft’s marketing strategy. She is experienced in aligning marketing and sales, building relevant content and messaging and developing integrated lead generation campaigns. Before joining TmaxSoft, Kelly served as the Vice President of Marketing for 10th Magnitude and held senior marketing roles with DataStax, BMC Software and Micro Focus. Kelly has a bachelor’s degree from Purdue University and an MBA from Loyola University Chicago.