After leading major re-platforming efforts, I’ve come to believe that the biggest risks in a re-platform aren’t technical. They’re organisational.
The Myth of the Big Bang
Every re-platforming conversation starts with the same temptation: “Let’s just rebuild it properly this time.” It’s seductive because it feels clean. But it ignores the most important constraint: your teams still need to ship features while the platform shifts beneath them.
The real skill is in sequencing. Which parts of the system can you migrate incrementally? Where do you need to maintain dual-running? How do you keep momentum when the visible progress is slow?
Stakeholder Alignment Is the Real Architecture
At Moonpig, the re-platforming was inseparable from the IPO journey. That gave us a forcing function, but it also meant that every technical decision had commercial scrutiny. The architecture of the system was important, but the architecture of stakeholder alignment was what made it succeed.
This means:
- Regular, honest communication about what’s working and what isn’t
- Making the invisible work visible: migration metrics, dual-running costs, risk reduction
- Protecting the team from context-switching between “keep the lights on” and “build the future”
Legacy Code Isn’t the Enemy
The code you’re replacing was written by smart people solving real problems under real constraints. Respecting that context, and learning from it, is what separates a successful migration from one that repeats the same mistakes in a shinier framework.
What I’d Tell Myself Before Starting
If I could go back to day one of my first re-platform, I’d say: spend twice as long as you think you need on the migration strategy, half as long on the technology selection, and all of your energy on keeping people aligned and motivated through what will inevitably be a longer journey than anyone expects.