When businesses discuss mainframe modernization, the conversation quickly becomes chaotic in terms of costs.
The dilemma of modernization can be summarized in a single statement: lift and shift and complete rewrite (which are synonymous with terms such as rehost, rebuild, and reimagine) do not represent conflicting alternatives. Instead, they serve different purposes with different levels of risk and quite different price points.
Rehosting (also called lift-and-shift) refers to moving an application to a new environment with almost no modifications made to its source code.
AWS states that 'rehosting' means moving an on-premise application to the cloud in its current form, and the transition will require minimum time and effort as no code or architectural changes are required. In addition, Microsoft considers the 'rehost' approach to modernization as being the least complex and least expensive of all modernization options.
On the other hand, a complete rewrite (usually referred to as 'rebuild' or 'reimagine') is significantly more complex. Microsoft states that 'rebuild' projects are high-application complexity projects requiring considerable redesign and coding changes, and the time and cost will be high as well. AWS defines 'reimagine' as both rewriting and re-architecting a mainframe application when new functionality is required by the business.
The short answer is lift-and-shift model will generally yield an upfront cost savings over a total rewrite which might take longer and cost more but ultimately may fulfill the needs of the organization’s strategy with real transformational benefits.
What lift-and-shift usually costs
The current guidelines for how much it will cost to modernize a mainframe system can vary, and are not perfect.
ISG says that the typical prices for a modernization project are between $0.25 to $2.30 per line of code; the scope of these projects varies greatly, lasting from 2 to 36 months and costing between $100,000 and $25 million.
ISG's definition of modernization is the updating of legacy code and the introduction of modern engineering practices without changing the original programming language. Therefore, they consider this to be "lighter-change" modernization as opposed to a complete rebuild.
The Microsoft Application Modernization Framework provides additional support for this value perception, with their 6 Rs reference framework. This framework suggests that rehost projects will typically remain quick, inexpensive, and provide minimal disruption to your business, while rebuild projects will be longer, more expensive, and create significant disruption to your business.
What a complete rewrite usually costs
According to Microsoft, rebuilding an application makes sense when there is a need to dramatically improve performance, scale, integrate, secure, or develop a cloud-native architecture - therefore, the choice to build a new application instead of keeping the old application should not be based on the lower cost, rather it should be based on the inability of the existing application to meet the company's needs.
ISG states that transformation / conversion projects will cost between $.50 - $8.00 per line of code; take 6 - 60 months; and range from $100,000 - $50,000,000.
ISG uses the definition of transformation as taking an existing legacy system and converting the related coding to a modern programming language so that it can run on a modern computing platform.
Comparing lighter modernization with deeper transformation reveals an obvious trend:
- Lighter Modernization: Costs range from $0.25 to $2.30 for each line of code
- Deeper Transformation: Costs range from $0.50 to $8.00 for each line of code
Take the cost per line of code range and multiply it by an application estate of five million lines, and the rough math for each option looks like this:
- Lighter modernization: Around $1.25M to $11.5M
- Deeper transformation: Around $2.5M to $40M
This is a simple extrapolation based on the ISG line-of-code ranges; therefore it is not a guarantee of pricing. Regardless, this method demonstrates how quickly cost increases when moving from the option of simply taking logic of an application and moving it, to the option of making substantial changes to the application.
Why rewrites cost so much more
Because the code is not the whole job.
AWS estimates that in the case of mainframe modernization, testing represents more than 50% of project time duration.
ISG has a similar conclusion when it expresses that automated re-engineering can process very large volumes of code quickly. However, the majority of the actual project duration is spent on quality assurance and testing, even though faster conversion tooling does not cause program costs to drop the way people had anticipated. The bottleneck shifts locations; it doesn’t go away.
McKinsey has shared research from over 5,400 IT projects showing that large-scale IT programs averaged 45% over budget, 7% behind schedule, and delivered 56% less value than expected. While this study isn’t limited to mainframe rewrites, a rewrite will typically act like a large transformation program and thus should heed the caveats outlined in this study.
According to Kyndryl’s State of Mainframe Modernization report for 2025, 70% of all organizations face challenges finding qualified resources. Furthermore, 74% of these organizations must depend on third-party service companies for those resources.
When lift-and-shift makes more financial sense
The lift-and-shift path is appropriate when:
- The application is still capable of supporting the business effectively;
- Users do not have a need for major functional changes;
- The initial goal of the project is an exit from the physical datacenter, cost control, or risk mitigation;
- There is not sufficient time for a full application rebuild
According to AWS, in the cases of large mainframe estates, it is expected that approximately 80% of applications will require no functional changes, with only 20% of the applications requiring re-imagining or "functional changes".
When a complete rewrite makes more financial sense
Microsoft indicates that rebuilding will provide significant improvements in performance, integration, and future scalability of very complex applications, while AWS indicates that reimagining will be the best path for transforming a business that needs to add more functionality (improving its competitive positioning/advantage).
In those situations, rewriting may be a valid choice - however, you also must appropriately budget for this work – it is NOT an engineering project that has a clearly defined and predictable outcome at completion; rather, your project is an entire transformation initiative that includes high levels of discovery time, testing time, change management time, and has a high potential for increased costs associated with scope creep or overruns.
The smarter path is often neither extreme
This is where many teams finally calm down and start making better decisions.
The Strangler Fig pattern from Microsoft suggests that replacing parts of a legacy system should take place in steps, rather than all at once.
AWS echoes this sentiment, stating that a "big bang" rewrite would be too much of an effort and present significant risks to the organization and would result in disruptions to the business.
From a financial perspective, this approach to modernization will be the best option because it will:
- Allow your organization to spread costs over time;
- Minimize risk during the "cut over" of services.
- Enable early delivery of value to your organization and customers.
- Keep your organization from rewriting components of the legacy system that are working just fine.
To put it most clearly: the best approach to modernization is typically going to be rehosting or refactoring the boring stuff, and rebuilding only those parts of the legacy system that truly need to be reinvented.
Conclusion
On average, the cost difference between complete rewrite and lift-and-shift will be quite large.
Lift and Shift will, in most instances, provide companies with a quick (or at least quicker than other options) way to migrate off a mainframe, reduce the constraints placed on their infrastructure, and avoid entering into a long transformation project.
On the other hand, a full rewrite usually has a significantly higher cost and risk of delivery. It can still represent the right choice but this will only be the case if your organisation has significant changes in their architecture, scalability, integration and/or customer facing functions.
For the majority of enterprises, the answer will be somewhere in the middle, with re-hosting or re-factoring the pieces that continue to work and re-building only those elements that have limitations on how the company operates.
If you want to help those who are familiar with the middle-ground coding approach, you can suggest they check out this guide on refactoring and rearchitecting mainframe applications to learn about the middle-ground approach.
Top comments (0)