A migration isn't a checklist of things to rebuild. It's four decisions — and if you take them well, everything you build afterwards gets cheaper.
We've said it before: an ESB migration isn't a moving job, it's a design job. But "design job" can sound abstract when you've got four hundred integrations and a renewal date bearing down. So here's the concrete version. A good migration comes down to four decisions, taken deliberately and up front — not four hundred tasks, taken by whoever picks up the ticket. 🧭
Get these four right and the migration pays you back. Skip them and you've paid the whole budget to arrive exactly where you started. Let's take them one at a time. 👇
🧹 Decision one — what should exist at all
Most old estates carry integrations that are dead, duplicated or redundant — roughly a fifth to a third of the typical estate — because nobody ever had the authority to switch anything off. So they just kept running, and kept getting migrated, decade after decade.
The first decision is the cheapest and the most ignored: decide what to retire before you rebuild anything. Every flow you retire is a flow you don't design, don't test, don't run and don't pay for. This is money released before a single new integration is built — and it shrinks the scope of everything that follows.
Rebuilding four hundred old processes as four hundred new recipes isn't modernisation. It's the same estate with a new logo.
🗺️ Decision two — what shape it should be
The old estate encodes years of compromises: things done as overnight batch because that's all the platform allowed, boundaries drawn where a team happened to sit rather than where the business actually splits.
A like-for-like rebuild copies those compromises faithfully — and with more confidence, because the platform is shiny and new. The second decision is to decide the shape deliberately: which flows are genuinely event-driven, which are batch, where the boundaries belong, what your single source of truth is for each core entity. Decide it once, while you're touching everything anyway, and you get an estate you can change quickly later instead of one you've inherited.
🔐 Decision three — who is allowed to do what
Here's the one that gets discovered under incident pressure if it isn't decided up front. Every integration is a non-human identity acting on someone's behalf, and the security model that worked on-premises doesn't survive the move to cloud.
The third decision is to design the security posture in advance: what each integration is allowed to reach, how identity and secrets are handled, what's logged and monitored. Do it ahead of the cut and it's a posture your security director can defend. Do it afterwards and you're doing architecture in the middle of an incident — the worst possible time.
🏗️ Decision four — how you build from now on
Modern platforms make building easy. That's the trap. An ungoverned estate on a modern platform sprawls faster than the mess it replaced, because there's nothing slowing the sprawl down.
The fourth decision is to put the patterns in the cupboard and the rules inside the patterns — before the team starts building at speed. Decide the reusable patterns, bake the standards into them, and the new platform accretes value instead of mess. This is the decision that makes every future build cheaper than the last, which is the entire point of migrating.
📋 The four decisions, at a glance
| The decision | Why it changes the outcome |
|---|---|
| 🧹 What should exist at all | Retire the dead and duplicated first — money released before anyone builds a thing. |
| 🗺️ What shape it should be | Decide event-driven vs batch and where boundaries sit, so you don't faithfully copy old mistakes. |
| 🔐 Who is allowed to do what | Design security in advance, or discover it afterwards under incident pressure. |
| 🏗️ How you build from now on | Patterns in the cupboard, rules in the patterns — so the new platform doesn't accrete the same mess. |
✅ Where to start
You don't have to take all four across the whole estate on day one. You take them once, on one thing, and prove the model:
🎯 Pick the single integration or renewal that hurts most right now.
🧾 Run the four decisions against just that one — what to retire, what shape, what security, what pattern.
🚀 Prove it works before you scale the model across everything else.
Figures cited draw on published industry research and integration-platform experience; they're directional rather than guarantees, and results vary by organisation.
🤝 The ask isn't a demo or a proposal. It's a short, bounded look at your estate and the four decisions in front of you — cheap, easy to say yes to, and the first real piece of the work whichever way you go next.
