After two decades of rescuing stalled replatforming programs, I’ve noticed a pattern. By the time a CTO calls me in, the project has already failed — it just hasn’t admitted it yet.
The budget is burned through. The timeline has slipped three times. Engineering is writing tickets faster than they’re closing them. And somewhere in a boardroom, an executive is asking why a two-year project still has no customer-facing output.
The answer is almost never the technology.
The Real Failure Mode
Most enterprise transformations fail because they conflate ambition with architecture. A board approves a migration to cloud-native microservices. A vendor promises a 6-month replatform. An engineering team inherits a 47-service monolith and a specification document that’s never been near a production environment.
Nobody lied. Everyone was just talking past each other.
The business is operating on a vision of what the finished system will do. Engineering is drowning in the constraints of what the existing system actually is. These two realities rarely meet in a requirements document.
The Three Structural Fixes
1. Audit Before Architecture
Before designing a target state, map the current state in ruthless detail. Every service, every integration point, every undocumented dependency. In my experience, this audit surfaces at least three critical blockers that no one budgeted time or money to address.
This is unglamorous work. It doesn’t produce a slide deck. But it’s the work that determines whether a migration succeeds or becomes a three-year scar.
2. Decouple the Roadmap from the Vision
The vision is a destination. The roadmap is a sequence of shippable increments. These are not the same document, and treating them as one is how you end up with a 24-month project that produces nothing customer-visible until month 22.
Every quarter of a transformation should produce something real. Something in production. Something customers interact with. If it doesn’t, the business is being asked to fund faith — and faith runs out before budgets do.
3. Embed Architecture in Delivery
The architect cannot be a waterfall. They cannot design a system in Q1 and hand it to engineers in Q2. Architecture is a continuous conversation with the complexity that only reveals itself during implementation.
When I took over Central Online’s replatforming, the theoretical architecture was clean. The actual migration path through 15 years of custom Adobe Commerce logic was not. The architecture had to evolve weekly. The teams that succeed are the ones where the principal architect is in the pull requests, not just the planning meetings.
What Recovery Looks Like
When I joined Central Retail as lead program architect, the program had been running for months and had missed its first milestone already. The CTO needed honesty more than optimism.
The first action was a two-week technical audit. Not planning — auditing. We mapped every integration, every data dependency, every custom extension in the existing platform.
From that audit, we restructured the roadmap around three parallel workstreams: infrastructure migration, frontend decoupling, and data layer modernisation. Each stream had an independent delivery cadence. Each produced production-ready output every six weeks.
We delivered the full MVP in nine months from that reset date — against a revised estimate of eighteen. 50% reduction in time-to-market. Not through heroics, but through structural clarity.
The hardest part of transformation is telling the truth about where you are. Most consultants are hired to validate a direction, not interrogate it. The organisations that move fastest are the ones willing to hear the audit before they commit to the architecture.
That’s where transformation actually begins.