Legacy System Modernization: Refactor, Replatform or Rebuild?

The hard part is rarely the technology. It is choosing how much to change. A full rebuild promises a clean start but carries the most risk, while small upgrades are safer but can leave the real problems in place. Most successful modernizations sit in between and change the system in stages while it keeps running.

The right legacy modernization approach is the least disruptive option that removes the specific constraint holding the business back, whether that constraint is hosting cost, security, speed of change or the ability to add new features.

This article compares the main modernization options, gives a decision path for choosing between them and shows five real modernizations side by side, each with the option chosen and the measured result. It does not cover mainframe migration, and it is not a cloud migration checklist.

Key takeaways

• Modernization options range from moving the system as it is (rehost) to replacing it with a new product or a bought solution. Each step up adds cost, risk and benefit.
• Start by naming the constraint: cost, security, performance, speed of change or missing capabilities. The constraint decides the option.
• Incremental approaches, such as the strangler fig pattern, let the business keep running while parts of the system move to new technology.
• Real projects show the range: a hosting move made a busy media site much faster, while a staged move to microservices made API calls about five times faster and ended monthly outages.
• Stabilizing first with automated tests and useful monitoring makes every later step safer and cheaper.
• AI coding tools now make large, repetitive migrations faster, but only when automated tests can verify each change.

Why legacy systems become a problem

Old systems keep running, but they become expensive to keep alive. The US Government Accountability Office reported that federal agencies typically spend about 80% of their IT budgets on operating and maintaining existing systems, including legacy systems, some of them decades old. Private companies face the same pattern on a smaller scale.

The usual warning signs are:

• Security exposure. The framework or language version no longer receives security updates.
• Slow change. Small features take weeks because nobody is sure what a change will break.
• Rising cost. Hosting, licenses and specialist support cost more each year.
• Performance limits. The system cannot handle peak traffic or growing data.
• Hiring problems. Few engineers want to work with the old stack, and those who know it are leaving.
• Compliance gaps. Auditors or customers require controls the old system cannot provide.

The modernization options

These options are often combined. A team can rehost first to cut cost quickly, refactor the riskiest parts next and rearchitect one area at a time after that.

A decision path

Work through these questions in order. The first answer that points to an option is usually the right starting point.

1. Is the system still needed in two years? If not, retain it with minimal patching and plan its retirement.
2. Is the function standard? If a mature product does the same job well, consider replacing the system.
3. Is the main problem hosting cost, uptime or speed? Rehost or replatform first, and measure the result before touching the code.
4. Is the main problem an outdated or insecure framework, while the design still fits? Refactor and upgrade in place.
5. Does the design itself block new features, scale or compliance? Rearchitect incrementally, moving one area at a time.
6. Is the system small, poorly understood and without tests? Stabilize it first, then decide between refactoring and rebuilding with real information.
7. Only rebuild from scratch when the system is small enough to rewrite in a few months, or when nothing in it is worth keeping.

Five real modernizations side by side

Rehost and replatform: The Daily Meal

The Daily Meal, one of the largest food websites in the US, serves 30–50 million pageviews a month, 1.7 million recipes and about 250 GB of images. Its customized AWS setup struggled with speed and uptime. .wrk moved the site to Pantheon, a managed hosting platform for Drupal, rebuilt caching at the application and CDN levels, set up a disaster recovery environment on AWS and moved images to a dedicated server with automatic resizing.

The code stayed largely the same, but the platform around it changed. The share of HTML responses delivered in 0.5 seconds or less rose from 50% to 80%, full-page loads within 7 seconds rose from 20% to 60%, monthly hosting costs fell sharply, and day-to-day development needed only two to three developers. Read the performance optimization case study.

Refactor in place: Connell Guides

Connell Guides, a UK publisher of study guides, ran its student subscription site on Drupal 7. Spam registrations and cross-site scripting vulnerabilities threatened the business, mobile pages performed poorly, and the budget was fixed. Instead of rebuilding, .wrk updated the Drupal core and modules, fixed the vulnerabilities, added protection against spam sign-ups and rebuilt the page layouts to be responsive.

The project came in 18% under budget, bounce rate fell to about 4% and on-page engagement rose 14%. For a site whose design still fit the business, refactoring removed the risk without the cost of a rebuild. Read the Connell Guides case study.

Rearchitect step by step: a healthcare platform

A Canadian platform that helps patients track chronic pain and share data with clinicians and insurers ran on Drupal 6. Insurers required SOC 2 Type 2 certification and strict data governance before contracts could grow, and the old system could not meet those requirements.

.wrk rebuilt the core services in Symfony one area at a time, while the old Drupal system was reduced to admin-only functions that auditors could isolate. This is the strangler fig approach, described by Martin Fowler, in which new components grow around the old system until it can be retired. API calls became about five times faster, monthly outages stopped, releases moved from months to two to three weeks and the platform passed the scrutiny needed for insurer deals. Read the healthcare platform case study.

Stabilize first: a supply chain platform

A B2B platform that tracks factory and supplier relationships had no automated tests, outdated dependencies and dozens of monitoring alerts a day that nobody trusted. Estimating a safe modernization was impossible without knowing what each change would break.

.wrk added automated test suites to every merge request, cleaned up the alert rules so only a handful of actionable alerts remained, added an audit trail for record changes and then upgraded the frontend framework. The result was a modernization roadmap backed by tests, instead of a guess. Read the platform modernization case study.

Replace: a conference analytics service

HIMSS, a US healthcare technology nonprofit, runs more than 20 conference and media websites. Its third-party analytics service failed when a record 45,000 attendees arrived within seven days. .wrk replaced it with a central data platform and a collection service in one month, ran the two in parallel until the numbers matched and then switched over. At the next conference, the new platform handled the same peak without disruption. Read the HIMSS case study.

How AI changes legacy modernization in 2026

AI coding agents now handle large, repetitive parts of modernization well: framework upgrades, test migrations, dependency updates and code translation between similar languages. Published projects show what is possible. Airbnb migrated about 3,500 test files to a new framework in six weeks instead of an estimated year and a half, and Amazon moved tens of thousands of applications to a newer Java version with an AI agent. Our article on AI agent use cases describes both projects.

Both projects relied on automated checks. Every change had to pass tests, a linter and a compiler before it was accepted. Without tests, AI-generated changes are hard to verify, which is one more reason to stabilize a legacy system before modernizing it. AI also helps teams understand old code faster, by summarizing modules, tracing dependencies and drafting documentation that was never written.

Costs and timelines

These ranges reflect typical mid-size business applications and assume an experienced team at Central European rates.

A rearchitecture spread across many months often costs more in total than a rebuild, but it delivers value along the way and keeps the business running on a working system throughout. A rebuild delivers nothing until it is finished.

How to reduce modernization risk

• Measure the starting point. Record performance, error rates, release frequency and hosting cost before any change, so the result can be proven.
• Add tests around critical paths first. They make every later change safer, whether people or AI tools make it.
• Move in slices. Migrate one feature, module or user group at a time, and keep the old path available until the new one is proven.
• Run old and new in parallel. Compare outputs on real traffic or data before switching over.
• Rehearse data migration. Run it several times on copies of production data, and time it.
• Plan the rollback. For every step, know how to go back within minutes.
• Keep the business informed. Agree on what users will see and when, especially during the switch.