Legacy application modernization: refactor, replatform or rebuild?

Signs an application needs modernizing

• Small changes take weeks and often break something else
• Only one or two people understand how it works
• It runs on unsupported frameworks, languages or operating systems
• Integrating with new systems or partners is slow and expensive
• It can't scale to current demand without costly hardware
• Security patches are hard or impossible to apply

Age alone is not a reason. A stable old system that rarely changes may be best left alone. Modernization is worth it when the system is blocking the business.

The modernization options

• Encapsulate: expose existing functionality through APIs so new systems can use it, without changing the core. This is quick and low risk.
• Rehost: move the application to new infrastructure, such as the cloud, as-is. It reduces infrastructure risk but not code complexity.
• Replatform: make targeted changes, such as a newer runtime or a managed database, to gain benefits with limited effort.
• Refactor: restructure the code to improve maintainability and testability without changing behavior.
• Re-architect: change the architecture, for example splitting out services that need to scale or change independently.
• Rebuild: rewrite the application, ideally incrementally.
• Replace: adopt a SaaS or off-the-shelf product when the capability is no longer a differentiator.

Why big-bang rewrites so often fail

Rewriting a large system in one go is tempting but risky. The old system keeps changing while the new one is built, so the target moves. Years of business rules are hidden in the code and only surface late. And the business sees no value until the very end, which tests everyone's patience and budget.

The incremental approach: the strangler fig pattern

The strangler fig pattern, a term popularized by Martin Fowler, replaces a legacy system gradually. You place a routing layer in front of the old application, then build new functionality piece by piece. Each piece takes over a slice of traffic or functionality until the old system can be retired.

1. Put an API gateway or routing layer in front of the legacy system.
2. Pick a high-value, well-bounded capability to modernize first.
3. Build it as a new service with tests, CI/CD and monitoring.
4. Route traffic to the new service, keeping the old path as a fallback.
5. Repeat, retiring legacy code as you go.

Each step delivers value and can be paused or redirected, which keeps risk under control.

A simple decision framework

Plot each application, or each major module, on two axes: business value and technical health. A useful reading, similar to the well-known TIME model, is:

• High value, poor health: invest and modernize. This is your priority.
• High value, good health: maintain and evolve.
• Low value, good health: tolerate and keep running cheaply.
• Low value, poor health: eliminate or replace with SaaS.

A practical modernization roadmap

1. Assess: review the architecture and code, map dependencies, and document business rules and pain points.
2. Stabilize: add monitoring, automated tests around critical paths and a deployment pipeline.
3. Prioritize: choose the first slice by value and risk.
4. Modernize incrementally: deliver slice by slice, measuring as you go.
5. Retire: decommission legacy components and their costs.

Measuring success

Track the four widely used DORA delivery metrics: lead time for changes, deployment frequency, change failure rate and time to restore service. Track infrastructure and support costs alongside them. Improvements in these numbers show that modernization is paying off.

Getting help

We modernize business applications incrementally as part of our custom software development services, often starting with an architecture and code review. See an example in our fintech platform case study, or book a consultation.

Frequently asked questions