A practical guide to moving off a platform honestly, without the theatrics, without losing users, and without burning the partnership.
Migrations get marketed dramatically. “Escape the legacy.” “Liberate your stack.” It plays well in conference talks. It plays badly when you're actually doing the work, and worse, when the platform you're leaving is one you'll still need to talk about in the years to come.
Here's how we approach migrations. None of it is novel. The opinion is that you should treat all of it as table stakes.
1. Start with the question, not the answer
Before scoping a migration, scope the question that produced it. Why is the team thinking about moving? Is it a real cost-benefit signal, licence economics, architecture mandate, roadmap fit, or is it a frustration that would still be there on a new stack?
If you can't articulate the trigger crisply, the migration will feel arbitrary to everyone except the people who picked it. That's how programmes lose momentum.
2. Be specific about what you're moving
“Migrating the platform” is usually a euphemism. Most estates are a mix of components, some earning their keep, some drifted. The honest answer is usually to migrate part of the estate and modernise the rest in place. The dishonest answer is to commit to a full re-platform without examining whether you need one.
3. Keep users on a working application throughout
A migration that requires a freeze on user-facing change is a migration that's allowed to take too long. Plan for incremental delivery. Plan for traffic routing that lets you flip flows one at a time. Plan for the failure modes. The slow migrations we've seen weren't slow because the work was hard. They were slow because someone agreed to stop shipping.
4. Modernise sparingly, on purpose
It's tempting to use a migration to rebuild everything you'd quietly wanted to rebuild for a year. Resist most of the temptation. Identify the small set of changes that are cheap in this context and that genuinely matter. Defer the rest. Scope creep is the single biggest reason migrations overrun.
“A migration is a re-platform, not a rewrite. Conflate them and the timeline doubles, the risk triples, and the business loses patience.”
5. Don't rubbish the platform you're leaving
This sounds like a tone point. It isn't. Rubbishing the platform you're leaving is operationally bad — it disrespects the team that built on it, it makes it harder to get knowledge transfer, and it locks you into having to justify the migration post-hoc when it gets challenged. It's also usually unfair. Most platforms are competent inside their fit.
The honest framing is “the fit has changed.” That framing keeps the conversation about your specific situation, rather than the abstract merits of platforms.
6. Plan for handover from day one
The platform you migrate to is a platform someone has to operate. If the migration team is the only group who understands the new build, you've created a different version of the problem you set out to solve. Documentation, runbooks, and knowledge transfer aren't the last week of the project, they're a continuous output.
What this looks like at Doddle
- Free 30-minute scoping conversation up front.
- Paid discovery week to map the surface area and confirm scope.
- Fixed-window, relatively fixed-cost migration (typically 6–12 weeks).
- Users on a working application throughout.
- Documentation and handover as ongoing outputs, not deliverables at the end.
- Available to stay, available to step back.
If any of this resonates and you've got a platform question in front of you, our migrations page has the engagement detail.
