Replace the old system without a bad weekend.
Functionality moves across one piece at a time, with both systems running and their outputs compared automatically, until switching the old one off is uneventful rather than frightening.
- In phases
- each one delivers something usable
- Per phase
- each one usable on its own
- Rehearsed
- every cutover, on a copy first
Who this is for
You probably need this if…
01
Nobody will touch it
It works, and every engineer who has opened it concluded it was somebody else's problem. The risk has been compounding quietly for years.
02
It runs on something unsupported
A framework past end of life, a database nobody patches, or a server under a desk. Eventually an insurer, an auditor or a customer asks about it.
03
The rewrite already failed once
A team tried a clean rebuild, ran out of runway around sixty per cent, and now you are maintaining two systems instead of one.
What we build
The work, in detail.
Legacy assessment
Reading the old system properly and reporting what it does, what it costs to keep, and what is genuinely risky about changing it.
Strangler routing
A layer in front that decides, per request, whether the old or new system answers. Every move across is independently reversible.
Monolith decomposition
Splitting along the seams that already exist in the code, rather than along an architecture diagram somebody drew in a workshop.
Re-platforming
Off on-premises or an ageing host onto managed infrastructure, with region and compliance constraints designed in rather than retrofitted.
Framework upgrades
Through several major versions in controlled steps, with the test suite proving each one before the next begins.
Parallel running
Both systems live, outputs compared automatically, until the numbers agree for long enough that the decision makes itself.
Rehearsed cutover
A runbook, a rollback path and a written decision about who calls it off and on what signal. All tested before the day.
Data migration
History moved in a rehearsed run with verified counts on both sides, and a down-migration written at the same time as the up.
Practice areas
The disciplines behind it.
You buy this as one engagement at one price. Underneath, it draws on 4 of our practice areas, and the same people cover all of them.
Modernisation & Migration
Replacing the system everyone is afraid of, without a weekend that goes wrong.
- Legacy assessment
- Strangler migration
- Monolith decomposition
- Re-platforming
Systems Integration
Making two systems agree that were never designed to talk to each other.
- POS & retail platforms
- Payment routing
- Identity federation
- Third-party orchestration
Cloud & Delivery
The infrastructure underneath, and the pipeline that keeps it moving.
- Deployment & hosting
- Infrastructure as code
- CI/CD pipelines
- Containers & orchestration
Quality & Testing
Knowing it works before a customer tells you that it does not.
- Automated test suites
- End-to-end testing
- Load & stress testing
- Accessibility testing
How it runs
Four weeks, in order.
Phase 0
Assess
Two to three weeks reading the system, tracing live traffic and documenting actual behaviour, including the bugs people have built processes around. You get the document whether or not you continue.
Phase 1
Route
The strangler layer goes in front with everything still served by the old system. Nothing changes for users, and the mechanism for moving pieces now exists.
Phase 2
Move
The first slice moves across, running in parallel with automated comparison. Once it agrees for long enough, traffic shifts. Then the next slice.
Phase n
Retire
The old system stops receiving traffic, runs cold for an agreed period, and is switched off. Data archived according to the retention rules agreed up front.
What you get, concretely
- A written assessment of the existing system and its real risks
- A routing layer that makes future moves reversible
- Each phase delivering working software, not a promise about the end
- Automated output comparison between old and new
- Rehearsed cutover runbooks with a tested rollback
- Documented behaviour of the legacy system, which you keep
- 30 days of post-phase fixes at no additional cost
Typical engagement
Fixed price per phase
Quoted per phase rather than for the whole programme, because an honest total before the assessment would be a guess. The assessment is priced separately and small, and you can stop after it with the document in hand.
Technology
What we build it with.
Defaults, not requirements. If you already run something else and have a team who knows it, we work in yours.
- Assessment
- Static analysis, dependency and licence audit, traffic mapping
- Routing
- Strangler proxies, feature flags, dual writes
- Targets
- Node.js, PostgreSQL, containers, managed cloud
- Verification
- Output comparison, reconciliation, staged rollout
Questions
What people ask before signing.
- How long does the whole thing take?
- Longer than a rewrite looks on paper and far more likely to finish. Phases across months, each delivering something usable. Anyone quoting a confident total before reading the system is guessing.
- Can we keep shipping features during it?
- Yes, and usually you must. That is the main argument for the incremental approach, because a six-month feature freeze is rarely survivable commercially.
- What if the old code has no documentation?
- That is the normal case. Phase 0 reads it, traces the traffic and documents behaviour. That document is valuable to you even if you stop there.
- Is a full rewrite ever right?
- Occasionally, for small systems or where the business domain genuinely changed underneath. We will say when that is the case rather than defaulting to the longer engagement.
- What happens to our data?
- Migrated in rehearsed runs with verified counts on both sides and a tested rollback. The real run is a repeat of something that already worked on a copy.
- Who decides when to switch off the old system?
- You do, on evidence. Parallel running with automated comparison means the decision is made against agreement rates rather than against anyone's confidence.
Related reading
Written on this, by us.
Data & Integration · 7 min read
The Data Migration Is the Project
Replacing a system is mostly moving its data, and that part is a business decision rather than a technical one. Why migrations overrun, and how to scope one honestly.
How We Work · 8 min read
How to Replace a Legacy System Without a Bad Weekend
Big-bang rewrites fail at a famous rate. The alternative is slower on paper, far more likely to finish, and keeps the business trading the whole way through.
Engineering · 8 min read
Why Your Agency's Tech Stack Shouldn't Be Yours by Default
Every firm has a preferred stack and most of the reasons are honest. How to tell when the preference is serving your project and when it is serving theirs.
Tell us about the system nobody wants to touch.
What it does, roughly how old it is, and what would happen if it stopped. The assessment comes first, and the document is yours either way.
Phone
+1 (407) 796-2376Reply time
One business day, from an engineer
Based in
Orlando, Florida · serving the United States
What happens next
- A reply within one business day, from an engineer
- A thirty-minute call, with no qualifying call before it
- A written scope and a fixed number, if it fits