The system everyone complains about and nobody replaces.
Spreadsheets that quietly became infrastructure. Software from a vendor who stopped answering. We replace them without stopping the business that depends on them.
Replacement is not the hard part. Cutover is.
Every organization we meet already knows their system is the problem. They can list what is wrong with it in detail. What stops them is not diagnosis. It is that the thing is load-bearing, and nobody can afford for it to fall over on a Tuesday.
So the workbook stays. It gains another column, another macro, another person who is the only one who really understands it. The cost compounds quietly, and it is never quite the quarter to deal with it.
We plan the migration before we plan the software: which records move, what happens to ten years of history, how both systems run side by side for a while, and who is on the phone the morning it goes live.
Switch between what most operations run on today and what replaces it.
Spreadsheets
93 columns, 1 owner
Email threads
the real system of record
Word templates
12 near-identical versions
Shared drives
organised by convention
Four tools, none of which knows what the others hold. The connections are people remembering to copy things across.
What replacement actually involves.
The visible application is perhaps a third of the work. These are the other two thirds.
Replacing spreadsheet infrastructure
The workbook that runs a department, rebuilt as software with real permissions, real history, and no more accidental overwrites at 11pm.
Legacy application replacement
Systems whose vendor has gone, whose platform is end-of-life, or that nobody will touch because the person who understood it left in 2019.
Multi-entity architecture
Organizations that are legally several companies but operationally one. Entity scoping designed into the first table rather than bolted on later, when it is no longer possible.
Data migration
A decade of history: inconsistent, half-duplicated, across four formats. Reconciled, mapped and moved, with a written record of every judgement call.
Document and template engines
The letters and reports your team assembles by hand, generated from governed templates with the correct letterhead and legal language per entity.
Role-based access
Who can see what, who can approve what, across roles and locations, enforced by the system rather than by convention and good manners.
Nothing is switched off until the thing replacing it has already run beside it.
Designed backwards from the cutover.
The go-live date is not the end of the project. It is the part of the project most likely to go wrong.
- 01
Map the real workflow
How work actually moves, including the workarounds. The undocumented exception is usually the thing that breaks a replacement.
- 02
Design for the migration
What moves, what gets archived, what gets cleaned, and what runs in parallel. Decided before anyone writes application code.
- 03
Build in the open
Your team uses the system while it is still being built, so the gaps surface while they are still cheap to close.
- Go-live04
Cut over and stay
We are there for go-live and the weeks after it, because that is when a migration is actually won or lost.