Cloudorizon - Insights

It's Not a Moving Job. It's a Design Job.

Written by Amber | Aug 4, 2026, 8:10:59 AM

Your ESB migration is the one chance you'll get this decade to build something better — here's how not to spend the whole budget standing still.

Almost every large enterprise runs on the same invisible thing: integration middleware — the plumbing that moves data between finance, CRM, the warehouse, the bank and your partners. For the last fifteen to twenty years, a great deal of it has run on a generation of platforms called enterprise service buses. MuleSoft and TIBCO are the names you'll hear most; IBM, Oracle, BizTalk and webMethods fill in the rest. 🔌

They were the right choice when they were bought. Holding them in place is what's become the problem: bills that keep climbing, a shrinking pool of specialists who cost roughly double a modern integration engineer, and a central team through whose queue every change has to pass — so a business unit waits eight to twelve weeks, or gives up and builds a workaround.

So you're moving off. And here's the part almost nobody tells you: how you move matters far more than that you move. Get it right and this becomes the best money you'll spend all decade. Get it wrong and you'll pay the whole budget to arrive exactly where you started. Let's unpack it. 👇

🚚 Everyone is selling you a moving job

The whole market is pitching the same thing: take the integrations you have, rebuild each one on the new platform, switch the old one off. Priced per integration and scheduled like a house move. Tidy, familiar, easy to say yes to.

The trouble is that a move doesn't change anything. Every integration you carry across is really a decision — about how that thing should work now, on this platform, in this business, rather than how someone built it in 2011 against a platform that no longer exists. Skip the decision and nothing has been modernised. The old estate has simply been carried over on your back, at enormous cost, and it will need doing all over again.

If that stings a little, good — it's the exact outcome you're paying to avoid.

🗄️ You get one chance to touch everything

Here's the reframe worth holding onto. A migration is the only time an organisation touches every integration it owns. That happens perhaps once a decade. It is the single biggest opportunity you'll ever get to build something reusable — and almost everyone wastes it.

Do it as a translation and you spend the whole budget arriving where you began: on a cheaper runtime, with hundreds of one-off builds and nothing anyone can reuse. Do it as a design job and you come out with a stocked cupboard — the patterns decided, the connections built once, the standards already in place. Everything you build afterwards is cheaper, and you get faster every year instead of slower.

"Re-implementing four hundred old processes as four hundred new recipes isn't modernisation. It's the same estate with a new logo."

🧭 Four decisions that decide it — not four tasks

A good migration isn't a checklist of things to rebuild. It's four decisions, taken deliberately and up front:

The decision Why it changes the outcome
🧹 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. Deciding what to retire releases money before anyone builds a thing.
🗺️ What shape it should be Which flows are genuinely event-driven, which are batch, where the boundaries sit. A like-for-like rebuild copies the old estate's mistakes faithfully — and with more confidence, because the platform is new.
🔐 Who is allowed to do what Every integration is a non-human identity acting on someone's behalf, and the old security model doesn't survive the move to cloud. Design it in advance, or discover it afterwards under incident pressure.
🏗️ How you build from now on Put the patterns in the cupboard and the rules inside the patterns, so the new platform doesn't accrete the same mess. Modern platforms make building easy — which means an ungoverned estate sprawls faster than the one it replaced.

📈 What changes when you do it right

Strategy is easy to nod along to and easy to forget. So here's what actually changes when the migration is run as a design job:

💰 The estate shrinks before it moves. Retire what's dead or duplicated first, and the migration is scoped against what the business actually uses — money released before anyone builds anything.

🗄️ A cupboard, not a copy. Design the patterns once while you're touching everything anyway, and every build afterwards is cheaper and faster instead of costing what the last one cost.

🧱 An estate that's shaped, not inherited. Decide what's event-driven and where the boundaries sit before anything is rebuilt — so you can change it quickly later.

🔒 Security designed in, not discovered. Decide what every integration is allowed to reach ahead of the cut — a posture your security director can defend, with no architecture done under incident pressure.

🤖 One migration instead of two. Build something your AI agents can actually reach the business through, with every non-human identity governed from the start — ready for the question your board is about to ask.

"You get one chance to touch everything. Spend it building a cupboard, not a copy."

📡 Sound familiar?

You don't need to understand the plumbing to know it's time. If you're saying any of these, the decision is already being taken — the only question is whether it's taken well:

What you're saying What it's really telling you
"Our renewal's up, and the number has climbed again." The clearest signal there is. Get the date — almost everything else follows from it.
"Integration is eating our IT budget." The run cost has reached the board. Rationalisation is the answer that pays back before anything new gets built.
"The people who understood it have left." An estate nobody can fully explain. Mapping what's actually running is where the work — and the value — starts.
"It takes months to get anything built." The central queue. A new platform on its own won't fix this, and that's an expensive lesson to learn the hard way.
"We've been quoted — and it's priced per integration." Someone is selling you a moving job. Ask them what happens to the integrations that should simply be switched off.
"We tried this before and it went badly." Usually it didn't fail because the technology was bad. It failed because of how it was run — which is fixable.

🤔 "But what about…" — three honest answers

"We already have an integration team." Good — this makes them the owners, not the bottleneck. If their week is a queue of requests, the problem is the shape they're working in, not the people. Set the direction and stock the patterns, and they build safely and fast. The goal is to grow your capability, not a dependency on anyone.

"Isn't there a tool that just converts the flows across?" There is, and some firms sell exactly that. It produces the old estate on new technology — the very thing you're paying to escape. If a converter is genuinely what you want, better to know that early; it's a different job.

"We're already halfway through." Then this is a better time to talk, not a worse one. Ask one question: when this finishes, will the next integration be cheaper to build than the last one was? If the answer isn't a confident yes, you're building a copy — and there's usually a lot of estate still to go.

🧩 "Aren't you just going to sell us Workato?"

Straight answer: we're a Workato partner, and for enterprise integration coming off an old ESB, the target is usually Workato. What we won't do is arrive with the platform already chosen and bend your estate to fit it. The target follows from the estate and from what you decide to keep. Where the work is genuinely SAP-to-SAP it goes to SAP BTP Integration Suite instead, and where you already run something worth keeping, we'll say so. The platform swap is the easy part to sell — the design is the part that pays you back.

✅ Where to start

You don't need to boil the ocean. You need one honest conversation and one first win. If any of this sounds like your organisation, the next step is small:

🎯 Pick the single integration or renewal that hurts most right now.
🧾 Get a clear read on what your estate really costs — what's running, and how much of it could simply be switched off.
🚀 Prove the model on that one thing before you scale it across everything.

Figures cited are drawn from published industry research and integration-platform experience; they are directional rather than guarantees, and actual results vary by organisation.

🤝 The ask isn't a demo or a proposal. It's a short, bounded look at your estate: what's actually running, what can be retired, and what the migration really involves. It's cheap, it's easy to say yes to, and it's the first genuine piece of the work whichever way you go next.