Application modernization is the work of updating older business applications so they cost less to run, carry less risk and are easier to change. Depending on the application, that can mean moving it to new infrastructure, upgrading its platform or database, rewriting parts of its code, breaking it into smaller services, or replacing it with a commercial product. It often applies to long-lived custom systems, including mainframe applications, that still run important parts of the business.
At a glance
- Modernization changes the application itself, its platform or its hosting, depending on how much change the business case supports.
- The common options run from rehosting (move it as is) through replatforming (targeted upgrades) and refactoring (restructure the code without intentionally changing what it does) to rearchitecting (change the structure of the system), plus replacing or retiring it.
- Legacy and mainframe modernization is often driven by shrinking skills, rising support costs and end-of-support dates.
- Most organizations modernize in waves, application by application, and use different approaches for different systems.
- Data, integrations and undocumented business rules are usually the hardest parts, more than the code itself.
What problem it solves
Many organizations run important processes on software written ten, twenty or more years ago. Over time these systems accumulate technology debt: old languages and frameworks, hardware or operating systems near the end of support, custom changes nobody documented and a shrinking pool of people who can maintain them. Changes become slow and risky, security patches may no longer be available, and licensing or hardware costs climb.
Modernization tackles that by deciding, for each application, what level of change is worth paying for. The goal is not newness for its own sake. It is a system the business can change at the speed it needs, at a cost and risk level it can accept.
How it works
Assessment. A modernization program usually starts with an inventory: what each application does, who uses it, what it connects to, what it costs to run and how healthy its code is. Applications are then scored on business value and technical condition.
Choosing an approach per application. The options are often grouped as:
- Rehost. Move the application to new infrastructure with few or no changes, often called lift and shift. Fast, but it leaves the code and design as they were.
- Replatform. Make targeted changes so it runs on a better platform, such as a managed database, a newer runtime or containers, without redesigning it.
- Refactor. Restructure and clean up the code so it is easier to maintain, test and change, without intentionally changing how the application behaves for its users. Often done in steps, alongside other work.
- Rearchitect. Change the structure of the system itself, for example splitting it into microservices or redesigning it around cloud-native services, so parts can be changed and scaled separately. Usually the most expensive option, and the one that tends to pay off when an application must keep evolving.
- Replace or retire. Swap the application for a SaaS or packaged product, or switch it off if it is no longer needed.
Legacy and mainframe systems. Mainframe modernization has its own set of options. Some organizations keep the mainframe and modernize around it, adding APIs so newer applications can use its data and functions. Others rehost mainframe workloads on emulation or compatibility platforms, convert code from older languages such as COBOL to newer ones, or replace the system outright. Each has different risks, and conversions in particular need thorough testing to show the new system produces the same results.
Execution. Work typically proceeds in waves, starting with lower-risk applications to build skills and patterns. Data migration, integration with other systems and parallel running are planned alongside the code changes.
When it matters for buyers
- When support or skills are running out. End-of-support dates, a retiring developer or a hardware renewal often force the decision.
- When the business is waiting on IT. If simple changes take months, the application is a candidate for replatforming, refactoring or rearchitecting.
- When a cloud migration disappoints. Applications rehosted without change can cost more in the cloud than they did before, which may prompt modernization or a rethink of where they run.
- When choosing a partner. Modernization is often delivered by systems integrators and consultancies alongside cloud and platform providers. Our public cloud solutions page covers sourcing the platforms modernized applications often run on.
Questions to ask vendors
- How will you assess our applications, and will we receive the inventory and findings even if we choose another partner for delivery?
- Which applications do you recommend rehosting, replatforming, refactoring, rearchitecting, replacing or retiring, and why?
- How will you capture business rules that exist only in code or in people’s heads?
- For a mainframe or code conversion, how will you prove the new system produces the same results as the old one?
- What does the program cost, how is it priced (fixed price, time and materials, outcome based), and what is excluded?
- What happens to running costs after modernization, including cloud, licensing and support?
- Which tools, platforms or runtimes would we depend on afterward, and how hard would they be to leave?
How it differs from cloud migration
Cloud migration is moving applications and data into a cloud environment; its main question is where things run. Application modernization is changing the application itself: its code, design, platform or data. The two overlap, because a migration program often includes some replatforming, refactoring or rearchitecting, and a modernization program often ends with the application in the cloud. But a rehost-only migration is not much of a modernization, and an application can be modernized in your own data center or in a hybrid IT estate without moving to a public cloud at all.