The four modernisation paths
Refactor when the system architecture is workable but the code is messy. Replatform when the code is acceptable but the hosting, database, or deployment process is old. Replace when the business process is standard and a SaaS product can do it better. Rebuild when the system is strategically important, unique, and too constrained to evolve.
The wrong answer is usually a big-bang rewrite with no migration plan. Rewrites fail when teams underestimate hidden behaviour in the existing system.
Start with discovery, not code
Modernisation begins by mapping business workflows, users, data, integrations, reports, pain points, and operational risk. The codebase matters, but the system around the code matters more. Who depends on it? What breaks if it goes down? Which reports do leadership trust? Which manual workarounds have grown around it?
A technical audit should produce a decision document: keep, refactor, replace, rebuild, or wrap with APIs. That decision should be based on business risk and future value, not developer preference.
The strangler approach
For many legacy systems, the safest route is to build new capabilities around the old system and migrate piece by piece. This is often called the strangler pattern. You might start by building a new reporting layer, then a new customer portal, then move one workflow at a time to a modern backend.
This lowers risk because the old system continues operating while the new system proves itself. It also gives users visible improvements sooner than a long rewrite.
Security and compliance risks
Old systems often lack patching, modern authentication, audit trails, encryption, and access controls. These risks can become urgent after a customer security questionnaire, cyber insurance review, investor due diligence, or GDPR concern. A modernisation roadmap should identify quick security wins even if the full rebuild takes months.
The fastest risk reducers are usually backup verification, dependency patching, MFA, access review, logging, and removing public exposure from systems that should never face the internet.
Cost and timeline by modernisation path
| Approach | Typical cost | Timeline |
|---|---|---|
| Technical audit & decision document | £3,000 – £8,000 | 1–3 weeks |
| Targeted refactor (single module or workflow) | £20,000 – £50,000 | 2–4 months |
| Replatform (same logic, modern hosting/database) | £35,000 – £80,000 | 3–6 months |
| Replace with SaaS/off-the-shelf plus migration | £10,000 – £40,000 | 2–5 months |
| Phased rebuild (strangler pattern) | £80,000 – £250,000+ | 6–18 months |
The audit is worth commissioning even when the eventual path seems obvious. It’s the cheapest way to find out whether a system that looks like it needs a full rebuild can actually be replatformed for a fraction of the cost — or vice versa.
Signs it's time to modernise
Treat these as the trigger to start a technical audit:
What a strangler-pattern migration looks like in practice
A typical sequence: first, put an API gateway or reverse proxy in front of the legacy system so new services can sit alongside it without users noticing. Second, build the highest-value new capability — often a reporting layer or customer-facing portal — against a modern stack that reads from the legacy database or a synced copy. Third, once that's stable, migrate one workflow at a time, cutting traffic over module by module rather than in one release. The legacy system shrinks gradually until what's left can be retired or kept running for a narrow, well-understood purpose.
This approach costs more in total engineering time than a single rewrite would in theory, but it removes the single biggest risk in legacy replacement: a multi-month project with no working software to show until the very end, and no way to course-correct if the original scope turns out to be wrong.
AyTech note: The safest projects start with a narrow, measurable workflow, then expand after real users prove the value. This keeps budgets controlled and gives Google, buyers, and stakeholders clearer proof of expertise.
Need a practical technical plan?
AyTech can review your requirements, map the risks, and turn the idea into a scoped delivery plan.
web app modernisation