Legacy modernization. Run by someone who has done it before.
An ageing system that talks to nothing, a migration that keeps slipping, a platform whose vendor has stopped patching it. We take the subject on a bounded scope, absorb it, and hand it back with your team stronger than when we arrived.
The cost of waiting hides in the margin
A system ages along three axes at once. Its technical foundation drifts toward obsolescence, with unmaintained versions and dependencies carrying known vulnerabilities. Its functional debt accumulates, as workarounds quietly become the rule. And its running cost climbs without anyone measuring it: the time spent going around the tool, the quality lost, the support hours that never get counted. The cost of acting is visible on a quote. The cost of waiting is not, which is precisely why companies wait too long.
It is not competence. It is having seen it fail.
Internal teams facing their first large migration are rarely short of skill. They are short of the specific knowledge that only comes from having run one: which edge cases surface at cutover, how long a data cleanup actually takes, why the third-party vendor disappears in the last fortnight, and what a rollback needs in order to be usable rather than theoretical. That knowledge is what shortens the project, and it is the whole reason to bring someone in for a bounded period rather than permanently.
Four stages, in this order, none skipped.
The order matters more than the tooling. Most failed migrations chose the target before mapping the workloads, which is the surest way to discover mid-project that the target does not fit.
- 01
Inventory the workloads, not the machines
What each system actually does for the business, how critical it is, and what depends on it. On half the engagements we see, the client has no current map, and producing one changes the conversation immediately. It also reveals how much of the supposedly essential is simply dead code nobody dared delete.
The map comes before the target
- 02
Sequence in waves, never in one move
Rebuilding everything in parallel is the method that produces the biggest failures. Each wave gets a closed scope that can ship and be used on its own, a measurable objective, and an explicit dependency on the previous one. The first wave is the one that pays back fastest, not the one that looks most interesting.
Big-bang migrations are how this fails
- 03
Write the rollback before writing the code
Before construction starts, the rollback plan is on paper and signed off: how we return to the previous state, how long that takes, and what data is lost in the process. It is not a luxury. It is what makes a go-live a decision rather than a gamble.
Signed off before build
- 04
Requalify the backups, then hand over
A migration is not finished when the systems run. It is finished when a restore has been tested on the new platform, the monitoring sees the new machines, and your team's operating procedures have been rewritten. A successful migration whose backups no longer work is an incident that has not happened yet.
A tested restore is the real finish line
Three things we will not agree to
Saying this before signing saves everyone a difficult conversation later.
- Starting without an internal owner. A migration cannot be driven by an outside party alone. Someone on your side has to be named, and freed from other duties for the duration. If nobody can be, the project is not ready.
- Rebuilding everything at once. It occasionally works in a large organization with deep resources. In a mid-sized company it is the method that produces the biggest, most expensive failures. Waves, or nothing.
- Leaving knowledge in our heads. Documentation written as we go, a decision log explaining the reasoning, credentials transferred, one person trained. A vendor whose knowledge lives only with them has created a dependency, not delivered a modernization.
On roughly thirty engagements delivered since 2019, measured in July 2026, no client has had to call us back on an emergency after handover. The only follow-on contracts signed were to extend a warranty or widen the knowledge transfer, never to repair something left behind. That record is the direct consequence of the three refusals above.
Four questions worth settling first.
-
How do we know when modernization is genuinely overdue?
Look for a trigger rather than a feeling. Three are legitimate: the platform has reached end of life, so security patches have stopped, a business need cannot be met because the system has no way to integrate, or a platform change elsewhere forces your hand. If the only driver is a diffuse frustration in the leadership team, the project has no compass yet and it is better to wait.
-
Why do these projects fail so often?
Usually for one of three reasons, and none of them is technical difficulty. Everything is attempted at once, which works occasionally in a large organization with deep resources and is close to suicidal in a smaller one. Nobody internal owns the project, so no one can settle a contradiction between two departments. Or the rollback plan was never written, which turns the first bad hour of the cutover into a crisis instead of a decision.
-
Can this run alongside our normal operations?
Only if someone is genuinely freed up for it. Handed to a team already holding the daily load, a migration stretches, and a stretched infrastructure project accumulates the worst possible state: half the estate migrated, two platforms to monitor, two sets of procedures. If the internal bandwidth is not there, the work should be handed to someone whose only job is this, on a bounded scope.
-
What guarantees do we get on the data?
A written commitment on no data loss, and it sits in the contract rather than in the pitch. If a migration causes a loss attributable to our work, restoring it is on us. Alongside that, the acceptance criteria are written before the build, the rollback is signed off before construction, and a restore is tested on the new platform before anyone calls the project finished.
Describe the system and the deadline.
Twenty minutes to tell whether this is a modernization, a migration, or a project that should wait. If waiting is the right answer, we will say so.