Replace the old system without a bad weekend.
Legacy replacement done in pieces, with both systems running until you are satisfied. Big-bang cutovers are how ordinary projects become the story a company tells for years afterwards.
- In pieces
- never one big cutover
- Both running
- until you are satisfied
- 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 decided it was somebody else's problem. The risk compounds quietly in the background.
02
It runs on something unsupported
A framework past end of life, a database nobody patches, a server under a desk. At some point an insurer or a customer asks about it.
03
The rewrite already failed once
A team attempted a clean rebuild, ran out of runway at sixty per cent, and now you are maintaining two systems instead of one.
What this covers
The work, in detail.
7 capabilities
01
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.
02
Strangler migration
A routing layer in front, so functionality moves across one piece at a time and every individual move can be reversed.
03
Monolith decomposition
Splitting along the seams that already exist in the code, rather than along an architecture diagram drawn in a workshop.
04
Re-platforming
Moving from on-premises or an ageing host onto managed infrastructure, with region and compliance constraints designed in from the start.
05
Framework upgrades
Moving through several major versions in controlled steps, with the test suite proving each one before the next begins.
06
Cutover planning
A rehearsed runbook, a rollback path, and a written decision about who calls it off and on what specific signal.
07
Parallel running
Both systems live with outputs compared automatically, until the numbers agree for long enough that switching the old one off is uneventful.
How we approach it
Positions we actually hold.
Opinions cost something to have. These are the ones we would argue for on your project, including where they make the work slower.
01
Never rewrite everything at once
Big-bang rewrites fail at a famous rate. Moving in pieces keeps the business trading and keeps every individual step reversible.
02
The old system is the specification
Its behaviour, including the bugs people have quietly built processes around, is the requirement. We document it before replacing any of it.
03
Run both, compare automatically
Parallel running with automated output comparison is what turns a leap of faith into a measurement somebody can point at.
04
Every cutover has an off switch
Written down before the day, rehearsed, and owned by a named person. Deciding under pressure is how a rollback gets skipped.
Technology
What we work 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
Where this shows up in delivery
- We have put routing layers in front of live systems so functionality could move across gradually rather than all in one night.
- Migration runs are rehearsed on a copy, verified by row count, and reversible.
- Where a rewrite is the wrong answer we say so. Sometimes a system needs three fixes and a maintenance plan, not a replacement.
Bought as part of
This practice is never sold on its own. It is quoted inside one of the engagements above, as part of a single number.
Questions
What people ask about modernisation & migration.
- How long does a modernisation take?
- Longer than a rewrite looks on paper, and far more likely to actually finish. Expect phases across months, each delivering something usable rather than a promise about the end.
- Can we keep adding 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. We read it, trace the live traffic and document the behaviour as the first phase, which is valuable to you even if you then decide to stop there.
- Is a full rewrite ever the right call?
- Occasionally, for small systems or where the business domain has genuinely changed underneath. We will say when that is the case rather than defaulting to the longer engagement.
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.
Tell us what you’re trying to build.
Describe the problem in your own words. We’ll come back within one business day with a scope, a number and a date.
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