Legacy modernization without stopping the business
Staged migration of ageing systems — API layers, incremental rewrites, and data migration that runs alongside the existing system instead of replacing it overnight.
replaced piece by piece · the old system keeps running
- System assessment
- Migration strategy
- API layer
- Best when
- The system works, nobody can change it safely, and a rewrite is too risky.
- Not a fit when
- The old system is small enough to replace outright in a few weeks.
- First thing you get
- An honest assessment of what the system does and a sequenced migration plan.
What is legacy modernization?
Legacy modernization is moving an ageing system onto current technology without stopping the business that depends on it. Instead of a big-bang rewrite, we put an API layer in front of the old system, replace one capability at a time, run old and new in parallel, and retire each legacy piece only once its replacement has proven itself.
The big-bang rewrite is the most reliably disastrous pattern in enterprise software. It takes longer than planned, the old system keeps changing while you rebuild it, and the switchover concentrates every risk into a single weekend.
We modernise incrementally instead. Put an API layer in front of the old system, move one capability at a time behind it, run both in parallel while confidence builds, and retire the legacy piece only once its replacement has proven itself in production.
It is slower on paper and considerably faster in practice, because it never requires the business to stop.
What this includes
- 01
System assessment
An honest read of what the current system does, what it costs you, and what is genuinely worth keeping.
- 02
Migration strategy
A sequenced plan with the riskiest assumptions tested first, not last.
- 03
API layer
A stable interface in front of the legacy system so new work is not blocked by old internals.
- 04
Incremental replacement
One capability at a time, running alongside the original until it has earned the traffic.
- 05
Data migration
Moving and reconciling data with verification, because silent data loss is the failure that does not announce itself.
- 06
Cutover and decommission
Retiring old components safely, with a rollback path at every step.
Situations we see most often
The system works but nobody can change it
Every modification is risky, the original developers are long gone, and there are no tests to tell you what broke.
The technology is out of support
A framework, runtime, or database version that no longer receives security updates.
It cannot integrate with anything modern
No API, no clean data access, and every integration becomes a bespoke project.
Running it is getting expensive
Specialist hosting, scarce skills, and maintenance costs rising faster than the value delivered.
What to know before you start
Why is a big-bang rewrite so risky?
A rewrite has to reproduce years of business rules, many of them undocumented, while the old system keeps changing underneath it. It usually takes longer than planned, nothing is usable until everything is finished, and the switchover concentrates every risk into one cutover.
Incremental modernisation spreads that risk out. Each step is small enough to test, reverse and learn from, and the business gets value from the first step rather than waiting for the last.
What is the strangler pattern?
It is the approach we use for most modernisations. An API layer is placed in front of the old system, so everything talks to the layer rather than the legacy code directly. Then capabilities move one at a time from the old system to new services behind that layer.
Old and new run in parallel while each new piece proves itself in production, and the legacy part is retired only when nothing depends on it. Over time the new system grows around the old one until the old one can be switched off.
How do you modernise a system nobody understands any more?
Missing documentation is the normal case. We reconstruct behaviour from the code, the database and the people who use the system daily, and capture it as tests that describe what the system does today, including the quirks people depend on.
AI-assisted code analysis makes reading large, old codebases meaningfully faster than it used to be. The tests then become the safety net: a replacement is correct when it passes the same checks the old system does.
What drives the cost of legacy modernization?
Modernisation cost follows how much the old system does and how tangled it is. These are the factors that move it most.
| Factor | Effect | Why it matters |
|---|---|---|
| Size of the business logic | High | The more rules the system encodes, the more must be understood, preserved and tested in the replacement. |
| Documentation and test coverage | High | With neither, behaviour has to be reconstructed before anything can move; that discovery is real work. |
| Data migration | High | Moving and reconciling years of records, with a way to prove nothing was lost, is often the riskiest part. |
| Integrations | Medium | Every system that talks to the old one must be redirected through the new API layer without breaking. |
| Parallel running | Medium | Running old and new side by side for safety costs infrastructure and comparison effort, and is worth it. |
| How much to modernise | Medium | Modernising interfaces and integrations while keeping a sound core costs far less than replacing everything. |
What a typical engagement looks like
- 011–3 weeks
Discover
Process map
- 022–4 weeks
Design
Interactive prototype
- 03two-week cycles
Build
Working software each cycle
- 04ongoing
Ship & support
Automated pipeline
What we build it with
- Strategy
- Strangler patternAPI facadeParallel run
- Data
- Migration scriptsReconciliation checksRollback snapshots
- Targets
- TypeScript servicesPostgreSQLManaged cloud
Questions we get asked
01Do we have to rewrite everything?
Usually not, and we would push back on that framing. Plenty of legacy systems contain years of hard-won business logic worth preserving. Often the right move is modernising the interface and integration layers while leaving a working core intact.
02Can the business keep running during migration?
Yes — that is the entire reason for working incrementally. The old and new systems run in parallel, traffic shifts gradually, and there is a rollback path at each step.
03What if the system has no documentation?
That is the normal case rather than the exception. We reconstruct behaviour from the code, the database, and the people who use it daily. AI-assisted code analysis makes this meaningfully faster than it used to be.
04Which technologies can you modernise from?
The approach does not depend on the language, because the risk sits in the business logic rather than the syntax: older web frameworks, desktop applications and the databases behind them all follow the same staged path. The assessment confirms the specifics of your stack before any plan is agreed.
05How long does modernisation take?
It runs in stages rather than one long project. The first capability usually moves within a few months, and each later stage is sized and scheduled on what the previous one taught us.
06Will users have to learn a new system all at once?
No. Because capabilities move one at a time, users meet changes gradually, and familiar workflows are kept where they work. Training happens per stage, not in one large switchover.
Adjacent capabilities
Tell us what you are building.
Share the problem and we will come back with an approach, a rough shape of the work, and what it would take to deliver it.