Platform Migrations Fail on Governance, Not Technology

A program I worked on spent five years replacing seven financial systems with one platform. It went live with roughly 60% of the planned functionality, and the seven old systems were still running.

Nothing in that sentence is an engineering failure. Every phase shipped. The data moved. The vendor was paid.

What failed was the part nobody wrote a contract line for: who decides when two business units disagree, who owns the standard process, and who has the authority to say no to a customization.

Every consolidation business case I have read is written by the people who will not operate the result. That is the structural problem, and it shows up in the budget years before it shows up in the architecture.

The estimate covers the move, not the operating model

Migration estimates are built from a work breakdown. Replatform the applications, move the data, build the integrations, run the test cycles. Those are real costs, and they are usually estimated within a factor of two.

Here is what never appears in the estimate:

• Retraining people who have used the old system for a decade
• Resolving business rules that two units define differently and nobody documented
• The argument over whose process becomes the standard
• The security review, which runs on its own calendar
• The sustainment team, which the program office assumes someone else will fund

That last one is the quiet killer. A migration is a project with an end date. A platform is an obligation with no end date, and obligations need a budget line that survives the year the contract closes.

The technical move might take eighteen months. The operating model takes three years, and the clock starts after go-live.

Decision rights are the architecture

One question decides whether a consolidation works: when Division A's workflow breaks under the enterprise standard, who rules?

If the answer is a steering committee that has never said no to anyone, the platform will absorb every exception. Each exception becomes a customization. Each customization becomes a permanent branch that has to be tested, patched and carried forward. Five years later the "single platform" is seven configurations in one database, which is the worst available outcome. You paid for consolidation and bought the same sprawl with a new license.

Federal programs have a harder version of this. At Impact Level 4 or 5, every system, integration and data flow needs its own authorization before it can carry real data. An authorization that lapses stops a program as completely as a bad line of code, and it does not appear on the engineering schedule. I have been on calls where a multi-million dollar effort stopped while a cloud service's authorization was renewed.

No engineering team can plan around that. Only a governance board with a calendar can.

The bill arrives after go-live

What a failed consolidation costs is not the overrun. It is what the organization stops doing.

• Business units that will not join the next enterprise initiative
• Shadow systems built to route around the platform
• The engineers who leave rather than maintain the compromise
• Two years of the platform team's capacity spent on reconciliation

None of that appears in a variance report. All of it appears in the next program's risk register, where the estimate has already been padded to cover the last failure. Organizational memory is real, and it is priced in.

The most expensive migrations are not the ones that go over budget. They are the ones that ship on time, under budget, and never get used.

The cheaper bet

Consolidation assumes fewer platforms means less complexity. That is true only if the consolidation works. When it fails you get both systems, plus a translation layer, plus a team to run the translation layer.

The alternative is to integrate instead. Wrap each system in an API you control. Put one identity layer and one audit trail in front of all of them. Move only the data flows that matter onto an event stream. Let each unit keep the tool that fits its work.

There is survey evidence pointing the same way. CloudBees commissioned a survey of 300 enterprise technology leaders on platform migrations, published in November 2025 (opens in a new tab). Only 25% said consolidation delivered the expected value within a year. 92% said integrating tools produced better delivery efficiency than replacing them.

Treat a vendor-commissioned survey with the suspicion it deserves, including this one. I cite it because the direction matches what I have watched in federal programs, not because the number settles anything.

Integration has costs of its own, and they are not small. You now own the API layer, the event contracts and the identity mapping. The difference is that those costs are visible, they start small, and they can be stopped. A consolidation cannot be stopped at 60%.

What to decide before you migrate

The test is not the architecture review. It is whether you can name the person who will decide, in writing, that Division A's workflow changes, and whether that person has the standing to enforce it.

If nobody holds that authority, you are not ready. Spend the year on integration and governance instead, and keep the systems you can already operate.

A stable set of systems you can run beats a modern platform you cannot. Keeping what works is the cheaper option, and it leaves you able to try again.