How to Modernize a Legacy Application: Rewrite, Refactor or Replatform?

Almost every business runs at least one application that everyone is afraid to touch. It might be a 15-year-old order system, an Access database that runs payroll, or a custom portal built by a developer who left years ago. It works, mostly. But every change is slow, security patches are getting harder to find, and the people who understand it are retiring.

You are not alone. In July 2025, the US Government Accountability Office reviewed 69 federal legacy systems and flagged 11 as most in need of modernization. Several of them relied on outdated languages, unsupported hardware or software, or had known cybersecurity weaknesses.

The question is not whether to modernize, but how. This guide compares the main paths, gives you a risk-based way to choose, and lays out a plan that avoids the most common failure: the big-bang rewrite.

What counts as a legacy application

“Legacy” does not just mean old. An application is legacy when it is still valuable to the business but expensive or risky to change. Common warning signs:

• It runs on an operating system, database or framework that is out of vendor support.
• Only 1 or 2 people know how it works, and documentation is thin.
• Small changes take weeks and often break something unrelated.
• It cannot connect to modern tools without manual exports or brittle scripts.
• Security scans keep flagging issues you cannot easily patch.
• Hosting or licensing costs keep rising for hardware nobody wants to maintain.

Much of this is accumulated technical debt: shortcuts and outdated choices that make every new change more expensive.

The modernization paths compared

Cloud providers and analysts use slightly different names, but the options come down to a spectrum from “change little” to “start over”. AWS Prescriptive Guidance, for example, describes 7 strategies for moving applications: retire, retain, rehost, relocate, replatform, repurchase and refactor. For modernization decisions, these are the paths that matter most.

A quick note on terms: if you are moving a whole portfolio to the cloud, our cloud migration checklist covers the full 7 Rs in depth. This article focuses on what to do with one stubborn application.

Why big-bang rewrites so often fail

Rewriting from scratch is tempting. The old code is ugly, the new stack is exciting, and a clean slate sounds faster than untangling a mess. In practice, full rewrites carry specific risks:

• Hidden business rules. Legacy code often contains years of edge cases, such as a special tax rule for one state or a workaround for a big customer. Nobody documented them, so the rewrite misses them.
• A moving target. The business keeps asking for changes to the old system while the new one is being built, so the rewrite has to chase it.
• No value until the end. Users see nothing new for months or years, which tests budgets and patience.
• One risky cutover. Switching everything at once concentrates all the risk into a single weekend.

This doesn’t mean rewrites are never right. Small applications, systems built on truly dead technology, or apps whose logic is simple and well understood can be good candidates. But for most business-critical systems, an incremental approach is safer.

Key takeaway: The safest modernization is usually the smallest change that solves the real problem, done in steps you can reverse. Replatform or refactor first, and save a full rewrite for when the code truly cannot be saved.

The Strangler Fig pattern: modernize piece by piece

The most widely used incremental approach is the Strangler Fig pattern. Microsoft’s Azure Architecture Center describes it as gradually replacing specific pieces of functionality with new applications and services, until the old system can be retired.

How it works:

1. Put a facade in front. Add a proxy or API gateway that all requests pass through. At first, it sends everything to the legacy system.
2. Carve out one capability. Pick a well-bounded feature, such as customer notifications or invoice generation, and build it as a new service.
3. Route traffic to the new piece. The facade sends requests for that feature to the new service. Users don’t notice the switch.
4. Repeat. Move capability after capability until the legacy system handles nothing and can be shut down.

Supporting techniques make this safer: feature flags let you switch traffic back instantly if something breaks, and running old and new side by side lets you compare outputs before you cut over.

A risk-based framework for choosing your path

Score your application on 2 dimensions: business value (how important and differentiating it is) and technical condition (how healthy the code and platform are).

Then adjust for risk with these questions:

• How much does an outage cost? The higher the cost, the more you should favor small, reversible steps.
• How well do you understand the business rules? If the honest answer is “not well”, avoid a rewrite until you have captured them in tests.
• Is there a hard deadline? A data center lease ending or an OS going out of support, such as the end of Windows 10 support in October 2025, often justifies a quick rehost or replatform first, with deeper work later. See our guide on what to do after Windows 10 end of support.
• Is the function generic? Payroll, CRM and accounting rarely need custom code. Replacing them with SaaS frees your team for work that sets you apart.
• Do you have the skills? A modern stack your team cannot support just creates a new legacy problem.

Where to start: a step-by-step modernization plan

1. Inventory and assess. Document what the app does, who uses it, what it connects to, and what it runs on. Note out-of-support components and known security issues.
2. Define the business goal. “Cut hosting costs by moving off our own servers”, “ship changes weekly instead of quarterly” or “pass a security audit” are goals. “Use microservices” is not.
3. Build a safety net of tests. Before changing anything, write characterization tests that record what the system does today, including the odd edge cases. Our guide to unit, integration and end-to-end testing explains which layers to cover.
4. Pick the path per component, not per app. The database might be replatformed, the reporting module replaced with a BI tool, and the pricing engine refactored.
5. Start with a low-risk, high-learning slice. Choose a piece that is useful but not mission critical, so the team can learn the new platform safely.
6. Automate delivery. Add version control, automated builds and a CI/CD pipeline early. Modernization means many small releases, and manual deploys will slow you down.
7. Containerize where it helps. Packaging components in containers can make replatforming easier and environments consistent. See how to containerize an application.
8. Measure and communicate. Track lead time for changes, incidents and costs, and show stakeholders progress every few weeks.
9. Retire the old parts. Actually switch off what you’ve replaced, including servers, licenses and data copies. Many projects stall at 90% and end up running 2 systems.

Budgeting and team considerations

Costs vary widely with the size of the system and the path you choose, so be wary of any fixed price before an assessment. In general, rehosting is the cheapest up front, refactoring spreads cost over time, and rewrites concentrate the most cost and risk. For a sense of what drives custom development budgets, see how much custom software development costs.

Plan for:

• Running 2 systems at once during the transition, including double hosting and support.
• Knowledge transfer from the people who know the legacy system. Record sessions and turn their explanations into tests and docs.
• Data migration and cleanup, which is often the slowest and most underestimated part.
• Training for the team that will own the modern system.

AI coding assistants can help explain unfamiliar code, draft tests and suggest refactors, but they still need careful human review, especially for undocumented business rules. Our look at how AI coding assistants are changing software teams covers where they help most.

Conclusion

Legacy application modernization works best as a series of small, reversible steps tied to a clear business goal. Assess the app’s value and condition, protect current behavior with tests, and pick the lightest path that solves the real problem: rehost or replatform for aging infrastructure, refactor for valuable but tangled code, replace generic functions with SaaS, and rewrite only when the old system truly cannot be saved. Then finish the job by retiring what you’ve replaced.

Sources

• US GAO: Agencies Need to Plan for Modernizing Critical Decades-Old Legacy Systems (GAO-25-107795) — 2025 review of federal legacy systems and their risks
• AWS Prescriptive Guidance: Migration strategies — definitions of rehost, replatform, refactor, repurchase, retain, retire and relocate
• Microsoft Learn: Strangler Fig pattern — incremental replacement of legacy functionality behind a facade
• Microsoft Lifecycle: Windows 10 Home and Pro — end of support date, October 14, 2025