Architecture Files #31 · Part of Binary and Beyond. LinkedIn newsletter edition follows.
The slide deck says transformation.
The status report says "on track."
The floor says otherwise: parallel systems still open, reconciliations still manual, and a go-live that keeps sliding because "data readiness" is never quite ready. Nobody cancelled the programme. It just stopped moving while everyone kept attending the same meetings.
That pattern is common enough to be boring. It is also misdiagnosed often enough to stay expensive.
The programme that swapped platforms and froze
Picture a mid-market distributor that funded a two-year ERP and CRM replacement.
Year one bought licenses, stood up environments, and ran discovery workshops that produced process maps nobody disputed in the room. Year two began cutover planning. Then the stalls arrived in a familiar order.
Finance would not sign off on chart-of-accounts mapping because "open" in the old ledger did not mean the same thing as "open" in the new one. Sales kept a spreadsheet of deal stages that the CRM could not absorb without rewriting commission rules. Operations refused dual-running for more than a quarter, then refused to drop the old warehouse screens because the new ones omitted three exception paths that still generated margin.
The vendor blamed change management. The SI blamed incomplete requirements. The CIO blamed legacy complexity. All three were partly right and all three were looking at the wrong layer.
The technology was replaceable. The ownership, workflow, and meaning were not. The programme treated a migration of meaning as a migration of tables (The Myth of a Single Source of Truth, Data Contracts Matter More Than APIs).
What "stalled" actually looks like in production
A stalled transformation rarely looks like a blackout. It looks like a permanent half-state.
- Old and new systems both authoritative for overlapping domains
- Nightly sync jobs that "bridge" until someone owns the bridge forever
- Status codes that map one-to-many, then many-to-one, then "manual review"
- Dual entry that was temporary and became headcount
- Steering committees that substitute for decision rights
- A data workstream that is always 80% complete and never cutover-ready
Delivery teams keep shipping adapters. Product owners keep filing defects against the target system for behaviours that lived in tribal knowledge, not in the source of record. The burn rate continues. The outcome does not compound.
This is not a tooling failure. Dashboards and middleware cannot resolve who owns a definition of "customer credit hold" when three departments disagree and the old system encoded the compromise as a nullable flag.
Why the stall is political and semantic
Technology swaps assume that if fields land and APIs respond, the business will follow.
Ownership migrations ask: who may change this rule after go-live, and who absorbs the fallout when it is wrong?
Workflow migrations ask: which steps are still real work, which are artefacts of the old UI, and which are control points that must survive?
Meaning migrations ask: what does this status, code, or balance actually commit the company to across systems?
Politics enters because those answers redistribute power. A shared customer master sounds neutral until territorial teams realise that their local override dies with the old screen. Semantic conflict enters because the old estate was a museum of negotiated exceptions. Collapsing those exceptions into a clean model feels like progress in workshops and like loss in operations (The Economics of Technical Debt).
Programmes stall when they schedule technology milestones and leave ownership and meaning as "change management" footnotes. Change management cannot invent a decision that leadership refused to make. It can only document the refusal.
A mental model: three migrations, one programme
Treat every digital transformation as three concurrent migrations:
1. Technology migration. Platforms, interfaces, hosting, licenses. This is what vendors sell and what Gantt charts show.
2. Ownership migration. Decision rights, support queues, who can freeze a change, who pays for exceptions. This is what org charts pretend to show and usually do not.
3. Meaning migration. Shared definitions, status semantics, reconciliation rules, what "done" commits across parties. This is what data workstreams discover late and what cutovers die on.
Progress on (1) without (2) and (3) produces a shiny system that cannot be trusted. Progress on (2) without (3) produces clear owners of an ambiguous truth. Progress on (3) without (2) produces beautiful dictionaries that nobody is empowered to enforce.
The stall usually appears when technology is "green" and meaning is still contested. Teams then invent temporary bridges. Temporary bridges become the new estate. You have spent the budget and purchased a more expensive dual-run (Every Integration Is a Distributed System, Why Enterprise Software Feels Slow (and Why That's Often Correct)).
Implications for how you run the programme
Stop measuring transformation by modules live.
Measure it by contested meanings resolved, ownership signed, and temporary bridges retired on a date with a named owner. If a meaning cannot be resolved, shrink the blast radius: migrate a bounded slice with explicit dual-run rules instead of declaring enterprise-wide single truth on a calendar.
Sequence work so that semantic conflicts surface before cutover theatre. Put the ugly mappings on the critical path in month three, not month twenty. Force product and finance into the same room when status vocabularies collide. Record the decision as a contract, not as meeting notes.
Protect engineering from being used as a political solvent. Adapters can delay a fight. They cannot win it. Every bridge you ship without a retirement trigger is a loan against the next release cycle (The Economics of Technical Debt).
On legacy modernisation programmes, we treat transformation as ownership and meaning work with technology as the delivery vehicle, not the other way around. The goal is not a new stack. It is a smaller set of explicit contracts that the business can operate without dual truth.
A cutover readiness checklist (not a tooling checklist)
- For each domain in scope, who owns the definition of "correct" after go-live, by name and team?
- Which status codes, balances, and flags map one-to-one, and which require a written exception policy?
- What temporary bridges exist, who owns each, and what business trigger retires them?
- Which workflows are control points versus UI habits, and who signed that distinction?
- What dual-run period is funded in headcount, and what metric ends it?
- Which contested meanings are still open, and is cutover blocked until they close?
- If leadership will not decide, what slice can ship safely without pretending the decision happened?
If you cannot answer these without inventing optimism, the programme is not delayed. It is stalled on politics and data while the technology work pretends to be the bottleneck.
A useful anti-pattern to watch: the programme that keeps adding integration stories to "unblock" cutover while the same three contested definitions remain open in a parking lot. Throughput without semantic closure is motion, not progress. Shrink scope until the open definitions fit inside a decision that leadership will actually make.
Fingerprint of a programme that will move again
You will know the stall is breaking when meetings stop debating platforms and start closing definitions. When a finance lead and an operations lead co-sign a status map. When a bridge has a kill date that survives the next reorg. When engineering is asked to shrink scope instead of "just integrate harder."
Transformation is not a product install. It is a negotiated rewrite of who decides, how work flows, and what shared words mean. Tooling can accelerate that rewrite. It cannot substitute for it.
Most programmes do not fail dramatically. They freeze in a polite dual-run and call it transformation until the budget ends. The ones that finish treat meaning and ownership as first-class deliverables, and treat every temporary bridge as debt with a repayment date.
Related reading
- The Myth of a Single Source of Truth
- The Economics of Technical Debt
- Why Enterprise Software Feels Slow (and Why That's Often Correct)
- Every Integration Is a Distributed System
Architecture Files #31 · Part of Binary and Beyond. LinkedIn newsletter edition follows. Unstalling a transformation stuck on ownership and meaning, not tooling? Start a conversation.