Modernisation
Legacy System Modernisation
The big-bang rewrite is the most reliable way to lose two years.
Legacy systems are replaced successfully by strangling them route by route, not by building a replacement in a branch nobody dares merge.
Quick Answer
Updated July 30, 2026
How do you modernise a legacy system without a rewrite?
By migrating incrementally: put the new system in front of the old one, move one route, feature, or bounded context at a time, and keep both running until the old one has nothing left to serve. This is usually called the strangler pattern, and it works because the product stays shippable throughout and every step is reversible. A full rewrite, by contrast, requires you to rediscover every undocumented behaviour in the old system before you can switch — which is why rewrites so often take two years and arrive missing things nobody remembered to specify.
Approach
Incremental, route by route
Shippable
Throughout the migration
Typical duration
3 – 12 months
Best for
- Systems that still work but are slow and expensive to change
- Stacks where hiring has become difficult or costly
- Applications blocking a product roadmap rather than failing outright
- Teams that cannot afford a feature freeze
Not best for
- Small applications where a rewrite genuinely is a few weeks of work
- Systems being decommissioned within a year anyway
- Organisations unwilling to run two systems in parallel temporarily
Legacy usually does not mean broken. It means the system works, and every change to it costs more than it should. Estimates keep growing for similar-sized work, onboarding a new engineer takes months, and increasingly the answer to a product question is "we could, but not in that codebase".
The instinct is to rewrite. The problem is that a rewrite has to reproduce every behaviour the old system acquired over years, most of which is not written down anywhere except in the code and in the habits of the people using it. That discovery happens late, and it is what turns a six-month rewrite into a two-year one.
We migrate incrementally instead. New code sits in front of the old system, traffic moves across one route or bounded context at a time, and both run in parallel until the old one is serving nothing. It is less satisfying than a clean start and considerably more likely to finish.
Quick Brief
Start the conversation here
Tell us what the system is, what it runs on, and what it is blocking. We reply with a migration shape and a first area to move.
Your Name
Work Email
What do you need help with?
Delivery Proof
Signals that matter before you hand over a serious build
Senior delivery
Compact team with direct access to the people who scope and build.
Commercial clarity
Written next-step proposal for qualified project briefs.
Launch focus
Kick-off readiness once scope, access, and commercials are aligned.
What we help with
- A migration sequence that starts with the highest-pain, lowest-risk area rather than the hardest one
- Routing layer in front of the old system so traffic can move gradually
- Zero-downtime database migration using expand-and-contract, rehearsed on production-shaped data
- Business logic recovered from the existing code before anything is discarded
- Test coverage added to the old system first, so the migration has a safety net
- Observability across both systems during the parallel-run period
- Documentation written as we go, because the absence of it is what made the system legacy
Comparison
Incremental migration versus a rewrite
Both end in a modern system. Only one of them keeps shipping while it gets there.
SoftwareCrafting
- Product stays releasable at every point in the migration
- Undocumented behaviour surfaces one area at a time, not all at once at the end
- Each step is reversible, so a bad week does not become a bad quarter
- Value lands early — the first migrated area is faster before the rest is touched
Typical Alternative
- A parallel build that is not shippable for months
- Every missing requirement discovered during cutover week
- A single, terrifying, irreversible switch
- No benefit at all until the whole thing is finished
Delivery Process
How we usually deliver this kind of build
Buyers searching for legacy system modernisation usually want clarity around how the work moves from brief to launch. This is the shape we default to unless the project needs a different engagement model.
Step 1
Scope and commercial fit
We start with the product brief, technical constraints, target users, and the fastest sensible delivery shape for this project.
Step 2
Architecture and execution plan
Before heavy build work starts, we lock the stack, delivery sequence, ownership model, and the parts that need extra operational care.
Step 3
Build, QA, and feedback loops
The same senior engineers stay close to the work through implementation, review, QA, and weekly decision-making.
Step 4
Launch and maintainable handover
We ship with documentation, deployment clarity, and a codebase your next engineer can realistically inherit.
Commercial Fit
Pricing and timeline expectations before you reach out
We do not force a fake fixed price onto every legacy system modernisation request. What we can do early is make the commercial shape and next steps clear enough for a real buying decision.
- Written proposal in 24 hours for qualified briefs
- Kick-off readiness in 48 hours once scope is aligned
- Fixed-scope or dedicated-pod engagement depending on clarity
- NDA and IP ownership handled before technical depth is shared
Most serious conversations start with a short project brief, inherited codebase context, or delivery bottleneck. From there we recommend the lightest viable commercial shape instead of trying to upsell a bigger team than the work needs.
Who This Is For
Teams and sectors we work with most on this offer
Mid-Project CTA
Want us to sanity-check the scope before you spend more time on it?
Send the brief, inherited codebase, or delivery bottleneck. We will reply with the fastest sensible path and whether this should be fixed-scope, phased, or handled as a dedicated delivery pod.
Related Case Studies
Proof that is close to this buying decision
FAQ
Questions buyers ask before they reach out
How long does legacy modernisation take?
+
Three to twelve months for most mid-sized systems, depending on how much of the data layer moves with it. The important difference from a rewrite is that value arrives continuously rather than at the end, so a twelve-month migration is not twelve months of nothing.
What is the strangler pattern?
+
Placing the new system in front of the old one and moving functionality across piece by piece, so the old system is gradually starved of traffic until it can be switched off. It is the standard approach for replacing a system you cannot afford to stop using.
Can you migrate the database without downtime?
+
Yes, using expand-and-contract sequencing: add the new structure, backfill, dual-write, switch reads, then remove the old. Each step is reversible and rehearsed against a production-shaped copy first. We have run these under rolling deployments where old and new schema had to coexist.
Should we modernise or rewrite?
+
Rewrite only when the system is genuinely small, or when the domain has changed so much that the existing behaviour is not worth preserving. For anything a business depends on daily, incremental migration is almost always the lower-risk path, and we will make that case honestly rather than sell the bigger project.
What if nobody understands the old system any more?
+
Common, and workable. We characterise behaviour from the outside first — recording what the system actually does at its boundaries — and use that as the specification. It is slower than asking someone, and far more reliable than assuming.
Which stacks do you migrate to?
+
TypeScript across the stack: Next.js and React on the web, Node.js or Python on the backend, PostgreSQL or MongoDB for data, AWS for infrastructure. If the sensible destination for your system is a stack we do not staff, we will tell you that instead of taking the project.
Relevant Reads
The technical details, if you want them
Business
Rescuing a Failing MVP: A CTO’s Blueprint for Auditing and Overhauling Legacy React Codebases
A tactical guide for CTOs inheriting failing React MVPs: learn how to audit dependency hell, eliminate render thrashing, and incrementally modernize legacy code without stalling feature delivery.
Frontend
TypeScript Strict Mode Migration: A Safe Plan for Large JavaScript Codebases
A detailed, incremental plan for moving a production JavaScript codebase to TypeScript strict mode without freezing feature delivery or hiding errors behind any.
AI Engineering
How to Build an AI SaaS Product: Architecture, Tech Stack, Cost, and Launch Plan
A practical guide to building an AI SaaS product with multi-tenant architecture, model integrations, retrieval, billing, evaluation, security, and a realistic launch plan.
Next steps
Useful commercial pages after this one
These pages help serious buyers compare fit, pricing, proof, and next-step logistics.