Systems were bought one at a time, by different functions, in different decades. Each works. Between them sit people re-keying data, reconciling versions of the same record, and explaining to auditors why the numbers differ. Replacing everything is rarely affordable and never fast, so the work is to make the existing estate behave as one, and to move what must move without stopping the business.
Why a layer, in integers
Connect every system to every other and the number of interfaces grows with the square of the estate. Route them through one layer and it grows in a straight line. This is arithmetic, not a claim about us.
Drag the slider. On the left, every system talks to every other; on the right, everything goes through one layer.
12Systems
66Point to point
12Through a layer
54interfaces that you never have to build
A migration that never switches the old system off has not finished
The second half of a migration is the half that gets cut when the budget runs out: archiving what has to be kept, proving it is retrievable, and then decommissioning the source. Skip it and you pay for two systems and trust neither. We sequence the shutdown as part of the work rather than as a follow-on project, because a follow-on project is what never happens.
How the risk actually behaves
Cost overruns in IT follow a power law, not a bell curve (Flyvbjerg et al., 2022; 2026): most projects land near their estimate, a minority overrun enormously, and the pattern is specific to IT.
5,392
IT projects in the published sample
280x
the largest cost-overrun ratio observed in it
15%
the usual buffer, calculated from the wrong distribution
The decisions you face
Point-to-point or through a layer
Faster for the first three interfaces, worse for the next thirty. The crossover is real and worth locating before choosing.
Migrate then improve, or improve then migrate
Migrating a bad process faithfully at least gives you a known baseline. Improving first is right when the process is the reason for the migration.
How much history moves
Full history is expensive and often unnecessary; "we might need it" is not a retention rationale.
What reversibility is worth
Parallel running costs real money. We think it is the cheapest insurance against the tail above, but it is your budget and the trade should be explicit.
In detail
Four parts of this capability have pages of their own:
- Tools, connectors and point-to-point links, and where the second one starts costing you
- Platforms, the layered architecture that keeps applications replaceable
- Business processes, five dimensions and five levels of maturity, assessed before anything is bought
- Decommissioning, retiring a system you still have to keep the records from, which is where cost take-out usually lands first
What you walk away with
Four pieces of work, and a shape of programme in which no single event can take the business down. Each one is the conclusion of something argued above it rather than a separate offer.
A count of the interfaces, before anyone commits to building them
What actually connects to what today, which of those connections carry the business and which survive only because nobody switched them off, and what each one costs to keep alive. Counted against the estate rather than against the architecture diagram, which is usually a description of an intention.
The count is what turns the choice between point to point and a layer from a preference into a calculation. It has a crossover, it is specific to your estate, and it can be located in weeks.
It costs a fraction of the programme it sizes, and if the answer is that you have eleven real interfaces and no case for a layer, that is cheaper to learn here than after the platform is bought.
A layer that absorbs the next connection instead of multiplying it
One governed route between systems, with the mapping, the error handling and the accountability defined once rather than re-argued per connection. Every system added afterwards adds one route rather than one per system already present, which is the entire difference the two pictures above are drawing.
It is deliberately not a replacement programme. The applications stay where they are and keep doing what they do; what changes is that they stop being connected to each other by hand.
And it is the same structure the automation and governance work sits on, so a client who buys both is buying one layer with two business cases rather than two layers that will later have to be reconciled.
Migration in slices you can stop after
Each slice runs in parallel with what it replaces, is reconciled while both are live, and can be abandoned without unwinding the ones before it. No weekend carries the whole estate, because the published evidence says the expected cost of a single irreversible switch is dominated by its worst case rather than by its average.
That is also why we decline big-bang mandates rather than price them. A programme in which one failure is unrecoverable cannot be made safe by contingency, only by not having that shape.
The first slice is chosen to be the one that proves the approach fastest, not the one that is easiest. A slice that could not have failed has demonstrated nothing about the ones that could.
Systems actually switched off, and the invoices that stop with them
Decommissioning planned as part of the work rather than as an intention afterwards: what still reads from the old system, what has to be kept and for how long, where it goes to be kept, and the evidence that the move was complete before anything was retired.
Skipped, the estate ends up carrying both. The licence, the support contract, the backup and the audit obligation all continue for a system nobody uses, and the saving that justified the migration never appears on any statement.
It is also the only point at which retention has to be decided rather than deferred, which is why this work and information governance keep turning out to be the same programme approached from two directions.
We move estates in slices you can stop after, so the first one proves the approach and no single weekend carries the whole risk.
Integration and migration, asked plainly
What is the difference between integration and migration?
Integration makes systems bought separately work together and leaves both in place. Migration moves an estate off one of them. Most programmes need some of each, and confusing the two is how a connection project turns into a replacement project halfway through.
Why avoid a big-bang cutover?
Because the risk is not evenly distributed. Most large programmes land near plan and a minority land catastrophically far from it, so the expected cost of a single irreversible switch is dominated by the tail rather than by the average. Moving in stages keeps a way back.
Do we have to replace the systems we already have?
Usually not, and the approach is deliberately neutral about it. Keeping the governance and the process logic above the applications is what turns replacing a platform into an ordinary commercial decision instead of a project you cannot start.
How long does a migration take?
It depends on how much of the estate has been classified, which is measurable in weeks before anything is committed. Anyone quoting a duration before that measurement is quoting a duration for somebody else’s estate.