Modernising a Legacy Web App Without Stopping the Business

Before planning anything, understand what the app actually does — including features nobody documented. Talk to the people who use it daily, list every screen and report, and note every integration with other systems.

Rewriting everything and switching over on one day sounds clean, but it concentrates all the risk at the end. The old system keeps changing while the new one is built, features are forgotten, and launch day becomes a gamble. Many big-bang rewrites run late or are abandoned.

The strangler fig pattern — named after a plant that grows around a tree until it replaces it — builds the new system around the old one. Requests are routed so that modernised features are served by the new code while everything else still goes to the legacy app. Over time, more routes move across, until the old system can be retired.

Each step is small enough to test and roll back. Users see steady improvement instead of one risky switch, and the business keeps running throughout.

Start with something valuable but self-contained: a slow report, a public-facing page, or a form that causes most complaints. An early visible win builds confidence, and it tests the routing and data-sharing approach before harder parts are tackled.

Data is the hardest part of any modernisation. Often the new and old parts share the same database for a while; sometimes data is synchronised between them. Either way, migration scripts should be repeatable, and totals should be reconciled against the old system before each cut-over.

Legacy apps often store passwords in outdated ways, build SQL queries from raw input, or check permissions only in the interface. These are serious risks, and some can be fixed in the old app before full modernisation — for example, moving to properly hashed passwords and parameterised queries as described in the OWASP cheat sheets.

A typical modernisation, broken into phases that each deliver something useful:

Imagine a booking system built years ago in PHP. Staff complain about the slow daily report; customers struggle with the booking form on phones; passwords are stored with an outdated hash.

A sensible order: first, fix password storage in the old app, because it's a live risk. Second, put a new front door in place that routes requests. Third, rebuild the customer booking form in the new stack — the most visible improvement — while it still writes to the existing database. Fourth, rebuild the daily report on the new side. Then continue with the admin screens until nothing is left in the old code.

Before moving any feature, capture how the old version behaves: what it shows for real inputs, what totals it produces. Automated tests that compare the new feature's results with the old one's catch differences before users do. For reports and billing, reconcile totals between old and new systems for a period before switching fully.

Users who've relied on an old system for years have habits — keyboard shortcuts, report layouts, field orders. Involve a few of them early, keep familiar terms and layouts where they make sense, and explain what's changing and why before each release. Adoption is part of modernisation, not an afterthought.

The new system should be boring in the best sense: a mainstream web framework, a relational database, configuration in environment variables, automated tests and deployments. Avoid rebuilding a monolith as dozens of microservices unless you genuinely have the scale and team to operate them — for most business applications, a well-structured single application is easier to run and change. The Twelve-Factor principles are a good checklist for keeping it portable between hosts.

The practical heart of the strangler approach is a layer in front of both systems that decides, request by request, which one handles it. It can be a reverse proxy, the new application itself forwarding unmigrated routes, or rewrites at the hosting level. Users see one address; behind it, the share of routes served by the new system grows release by release. Login sessions need special care so users aren't asked to sign in twice when they move between old and new pages.

Because modernisation is phased, estimate it phase by phase rather than as one number. The audit and foundations phases can be estimated fairly precisely; later phases are estimated as they approach, with better knowledge of the old system. This also lets the business pause, reprioritise or stop at any point with working software in place — something a big-bang rewrite can't offer.

Sometimes the right answer is to replace the app with an off-the-shelf product — when its features are generic, like standard invoicing or basic HR. Sometimes it's to leave it alone — when it's stable, secure enough, rarely changed and near the end of its useful life. Modernisation earns its cost when the application supports processes that are specific to your business and that you expect to keep evolving.

Legacy systems are usually poorly documented — that's part of why they're hard to change. Don't repeat the problem. As each feature moves, document what it does, the business rules it encodes, where its data lives and how it's tested. Short, current documentation in the repository is worth more than a long document written once and never updated. It also means the organisation is never again dependent on one person's memory of how the system works.

Legacy apps often got slow because of unindexed database queries, reports calculated on every page load, or everything running in one request. The new system can fix these systematically: add indexes for the queries users actually run, move heavy reports and exports to background jobs, cache results that don't change often, and paginate large lists. Measure before and after — users notice a report that drops from a minute to a few seconds more than any design change.

Integrations — payment gateways, SMS providers, accounting software, partner APIs — are where modernisations most often stumble, because they depend on systems you don't control. List each one during the audit with its credentials, callbacks and failure behaviour. Move them deliberately, test against the provider's sandbox where available, and keep the old integration running until the new one is proven with real traffic.

Modernisation projects lose support when stakeholders can't see progress. A simple, regular update — which features have moved, what improved for users, what's next, and any risks — keeps owners, managers and users aligned. Show before-and-after comparisons where possible: a report that took a minute and now takes seconds, a form that now works on phones, a security issue that's closed.

Modernisation isn't only a one-time cost. Plan for the new system's ongoing maintenance — dependency updates, hosting, monitoring and small improvements — from the start. The goal is a system that stays modern, so the organisation doesn't face another painful rewrite in ten years.

A modest, steady maintenance budget is far cheaper than letting software decay until it has to be replaced again.

When the last feature has moved, keep the old system available read-only for a period, archive its data, and then switch it off. Document what was retired and where each function now lives.