Legacy Application Modernization: Six Approaches and How to Choose Between Them

Six approaches, six different problems

"Modernization" covers very different kinds of work. Cloud providers use a shared vocabulary for it; AWS, for example, lists seven migration strategies, from retire and retain through rehost and replatform to refactor. For a single business application, these are the six approaches that change something:

Two decisions sit alongside them. Retain keeps a part as it is, for now, because it works and changes rarely. Retire switches off what is no longer needed. Both are underused: every part you retire is a part you never have to modernize.

Each approach, in practice

Rehost

Move the application to new infrastructure without changing it, often called lift and shift. It is fast and low risk, and it solves exactly one problem: where the software runs. If the pain is slow releases or poor integration, rehosting moves the pain to a new server.

Replatform

Move it and make targeted changes to benefit from the new platform, such as a managed database, managed file storage or automated deployments. This often cuts operating effort noticeably for modest work. The risk is enthusiasm: each "small improvement" leads to another until the replatform is an unplanned rewrite.

Refactor

Improve the internal structure of the code without changing what it does. Refactoring makes future changes faster and safer, but only if tests exist to prove behaviour has not changed. For a system with no tests, writing them around the most-used behaviour comes first.

Rearchitect

Change how the system is divided and connected: put an API in front of it, split out a component that changes often, or move to events between parts. This is where most valuable modernization happens, because it removes the bottlenecks that slow the whole business, such as being unable to connect a new tool.

Rebuild

Write the application, or part of it, again. Justified when the software models a process the business no longer follows, or the technology cannot be kept secure at a sensible cost. The main risks are a long period without new value and losing business rules nobody wrote down. Rebuild one area at a time wherever possible.

Replace

Move to a packaged product. The right answer for standard processes such as accounting, HR or ticketing, where a product built for many customers will be better maintained than anything bespoke. The cost is adapting your process to the product, plus migration and integration.

Choose per part, not per system

An application is several layers: interface, business rules, data, integrations and infrastructure. Each can need a different approach.

A typical result for a ten-year-old operations platform might be:

No single label describes that plan, and that is the point.

Staged techniques that keep the business running

The strangler fig

Martin Fowler's strangler fig approach replaces a system gradually: put a stable interface or facade in front of it, build replacements for one capability at a time behind that interface, and switch traffic as each is proven. Microsoft's guidance adds two important details: use an anti-corruption layer so the new design is not shaped by the old one, and do not let the facade become a single point of failure. It also notes the pattern is a poor fit when requests cannot be intercepted, or when the system is small enough to replace in one go.

Branch by abstraction

Inside a codebase, Fowler's branch by abstraction does something similar at a smaller scale: introduce an abstraction around the part being replaced, switch callers to it, build the new implementation behind it and remove the old one. It allows the system to be released regularly while the change is still in progress, instead of living on a long-running branch.

How to assess each part

Before choosing an approach for a part of the system, rate it on a few plain questions. A short assessment like this, done with the people who maintain and use the system, is usually enough to make the choice obvious:

Record the answers and the chosen approach for each part, along with the reason. The written reasons matter later, when the plan is challenged or a new person joins the team.

Signs you are choosing for the wrong reasons

• The approach was chosen before the problem was named. "We need microservices" is a solution looking for a problem.
• Everything gets the same approach. One label for a whole system usually means nobody looked at the parts.
• The plan has no first release. If the first visible benefit is a year away, the plan is a rebuild in disguise.
• Nobody can say what the old system does. Any approach is risky until behaviour is documented and tested.
• The cloud provider chose for you. Hosting is one layer. Moving it rarely fixes the others.

Keeping the business informed

Modernization is easier to fund when progress is visible to people who never see the code. Report each stage in business terms: what users can now do, what was retired, what risk was removed and what it costs to run. A plan that only reports technical milestones tends to lose its sponsor long before it finishes, however well the engineering is going.

Where to start

1. Name the business problem in one sentence: slow releases, no integration, rising costs, unsupported technology.
2. Break the system into its parts and give each a condition and an approach from the table above.
3. Pick the first stage: small, valuable, visible to users and able to teach the team how the system really behaves.
4. Put tests around the behaviour that stage touches before changing it.
5. Release, measure and choose the next stage with what you have learned.

For a deeper look at the biggest decision in this list, read modernize or rebuild. If you want help assessing a system part by part, our application modernization team runs it as a fixed-scope first step.