How to succeed in legacy IT modernization and avoid the pitfalls that make so many fail

What do you need to consider before engaging in a modernization project? Should the approach be business-run or IT-led? What makes modernization attempts fail? What strategies are there, and which are best for you? These are just some of the questions you should be asking if you haven’t already modernized your legacy IT infrastructure and the applications that come along with it.

Our accompanying paper guides you further in answering these questions, provides a list of checkpoints to ensure a successful transformation and details a case study where we helped a Fortune 500 company succeed in modernization after 20 years of failure.

Is modernization of legacy IT worth it?

In a word, yes. It may come with a daunting timeline and a price tag that leaves some people requiring convincing, but without modernization, your IT costs will soar while performance declines. In fact, IT operations and maintenance account for around 75% of the entire IT spend worldwide. The most expensive systems to support are the oldest ones — legacy systems and old mainframe monoliths. With constantly growing operations cost and risk, many IT managers must conduct modernization initiatives.

The challenging and complex nature of modernization projects leaves many of them pending, incomplete or perpetually postponed. While they account for nearly a third of the entire development and enhancement spending worldwide, 29% of this spending is wasted on failed efforts.

The 2021 Mainframe Modernization Business Barometer Report found that 77% of organizations have started a legacy system modernization project but failed to complete it — but why? The most common reasons are:

• Unclear understanding of modernization scope
• Underestimation of effort 
• High expectations of chosen approach and reliance on a ‘magic solution’ 
• C-suite and IT leadership disconnect

The common approaches to modernization and some of their pitfalls

Commonly known as the R-treatments, each of these approaches suits a particular subset of cases, but they don’t necessarily integrate easily with one another and of course, they each have their own risk and price.

• Retire — an approach that simply lets you shut your application down. Don’t forget to retain the data you might need, and think about how you access it
• Retain — your mainframe still does the job, so keep the application and instead focus on modernizing the peripherals. Usually comes with extra vendor lock-in that adds to your current spend. Often not an option for non-IBM legacy platforms 
• Replace — getting a COTS product from a trusted vendor with support and tailoring services. Worth considering, but IT leadership should remember this will be business-driven with an unpredictable timeline and outcome 
• Rewrite — same as Replace, but with your own solution. Rebuild your application following modern architectural guidelines and see it become cloud native. Best option for smaller applications, but complexity and costs grow exponentially with size 
• Rehost — also known as lift and shift. Take all your legacy technology and port it to a new platform using some COTS environment emulation solution. Allows you to decommission your legacy hardware and keep something running until you Replace or Rewrite it, unless you decide to keep it rehosted. If you need to combine solutions your risk grows exponentially. The emulation layer could affect performance considerations 
• Rearchitect — leverage automated conversion tools to reuse all legacy components of your application by transforming them to a modern technology stack. Transformation of your business logic from a legacy language to Java, green screens to webpages, batch scripts to modern scripting. Can be invaluable when converting metadata to the target technology format but takes a long time, and still results in COBOL written in Java. Resultant product might be difficult for both Java and COBOL developers to work with 
• Reengineer — a combination of all. If no other treatment worked for you on its own — this will. But it can be more expensive than lift and shift approaches. An early decision to Reengineer however, usually means future savings. Finding a tool-agnostic partner that can identify all the ingredients of your success with this approach is a challenge

What to consider if you’re modernizing

So those are your options, but how do you choose which R-treatment is the best fit for you? Here are some questions to help you decide. Not all of them are going to be relevant to your case, but they should be considered when you embark on your modernization journey.

• Do you clearly see your application development/sunset strategy for the next decade?
• Do you have a clear definition of done for your modernization?
• Are you investing enough time and budget into upfront solutioning and a solid PoC before committing to one option?
• How expensive and time-consuming will it be to maintain your target solution in 5 – 10 years? 
• Does your application have performance considerations? Will the chosen approach meet your requirements? 
• How fast will you need to be able to deliver post-migration? 
• Do you have a fallback plan in case things go wrong once live? 
• If you’re introducing a vendor solution, how much will their proprietary licensing cost in a decade? 
• Do you have an integrator partner?
• Do you have a change management strategy for your application to be adjusted in parallel with migration activities? 
• How are you planning to assure quality of the migrated product? 
• Is the business community backing your modernization plans? Are there any compromises that need to be agreed to with the business community?

In our white paper you’ll find a more detailed explanation of the R-treatments, plus a comprehensive list of questions that are crucial and often overlooked during the early stages of migration. The chances of modernization projects being a complete success the first time are small, but we hope to increase your chances with this mini guide and the accompanying, detailed white paper.