The technical team's instinct is tempting: turn off the legacy ESB over a weekend, switch on MuleSoft on Monday, and celebrate the clean cutover. That plan always fails — and it fails for three reasons that keep repeating across every big-bang migration attempt we've seen with clients.
Why "big bang" migrations always get stuck
- The inventory is never complete. After years of scripts, emergency integrations, and connectors built by people who've since left the company, processes nobody documented always turn up. In a big bang, they turn up on Monday morning, once the business is already at work.
- The business can't stop for as long as the cutover needs. If sales, billing, fulfillment, or customer service depend on an integration, there's no maintenance window reasonable enough to migrate twenty of them at once. Any gap is either too short or too expensive.
- Rollback doesn't exist. Once the legacy system is switched off, going back means reactivating middleware infrastructure that hasn't been updated in three months, with lost configuration and teams that have already moved on to other things. That's not a rollback — it's a different disaster.
When a migration plan depends on none of the above happening, it isn't a plan: it's a bet. And architecture bets get paid for by the business.
The strangler pattern applied to integrations
The strangler fig pattern — described by Martin Fowler for application migrations — translates well to integrations. The idea is simple: the new system grows around the old one, surrounds it, and only once it has fully absorbed the old system does that system get switched off.
For integrations, that means four concrete things:
- MuleSoft — the new middleware layer — gets installed in parallel, without breaking anything. The legacy system keeps working exactly the same on install day.
- Every new integration gets built directly in MuleSoft, not in the legacy system. From day one, the legacy system stops growing.
- Existing integrations migrate one at a time, not in a block, prioritized by criticality and by the cost of keeping them on the legacy system.
- Once the last integration has migrated, the legacy system gets switched off without ceremony — because nobody's using it anymore and the business doesn't notice.
This pattern doesn't speed up the migration: it makes migration possible without switching off the business. The difference between the two is usually worth several hundred thousand euros a year in avoided operational cost.
A migration done right ends with the old system's shutdown as an administrative event, not an operational one.
Inventory what you have: a practical guide
Before you can prioritize, you need to know what you're migrating. The list is usually longer than the team thinks. Four sources rarely fail:
- The ESB or middleware console itself. Every connector currently active. It's the cleanest source, but it only covers what's formal.
- Server cron jobs. Scripts that move files, scheduled exports, overnight loads. These are usually "informal" integrations nobody ever renamed as such.
- Shared mailboxes and network folders. If a process depends on someone moving a CSV every Monday, or an XML arriving by email, that's a manual integration — and someone has to decide whether it migrates into MuleSoft or disappears.
- Recurring support tickets. "X sync went down" over the last six months. Every recurring theme hides a fragile integration that exists but nobody has mapped.
Those four sources get you to 90% of the real inventory. The other 10% shows up during the migration; having it show up during, rather than after, the shutdown is exactly the point of going strangler.
Prioritize by criticality and cost, not by what's annoying
With the inventory in hand, the temptation is to migrate whatever makes the most noise first. That's a mistake. The prioritization that actually works combines two axes:
- Business criticality: what breaks if this integration stops working? Whatever breaks billing outweighs whatever breaks an internal report.
- Cost of maintaining the status quo: how much does it hurt to keep it on the legacy middleware? A stable integration nobody touches can stay put for two more years; an integration that breaks every month costs more than it looks like, in hours and in the business's trust.
The winning quadrant to start with is "high status-quo cost, low criticality": a failure doesn't break the business, but the technical payoff is immediate and the team learns MuleSoft on cases that don't burn. The next quadrant is "high cost, high criticality" — slower, more disciplined, more planned.
What's "low cost, high criticality" migrates last: the integration that "works fine and we touch it once a year" can wait without drama. And what's "low cost, low criticality" often doesn't migrate at all: it gets switched off, because the project is a rare opportunity to eliminate load nobody was ever going to remove otherwise.
The transitional middleware layer: MuleSoft coexists with the legacy system
During the migration, MuleSoft and the legacy middleware coexist for months. That coexistence isn't a problem: it's exactly the point of the pattern. Three rules keep it sustainable:
- No integration lives in both places at once. Once one migrates, its legacy counterpart is switched off or turned into a liability — it stops receiving changes and only gets touched if it breaks.
- MuleSoft is the destination, not a bridge. You don't build a temporary integration in MuleSoft "until." If it's going to MuleSoft, it goes with the final architecture; if not, it doesn't go yet.
- The team works exclusively in MuleSoft for anything new. From day one, any new business integration is built in MuleSoft, even while the legacy system is still alive. Otherwise the legacy system keeps growing — and it never gets switched off.
When you can turn off the old system (and how to know)
The signal to switch off isn't "we've migrated every integration on the list." The list will always be incomplete. The signal is this:
- No production integration touches the legacy system for 30 consecutive days.
- No business team requests a new integration on the legacy system during that period.
- Legacy logs show no traffic besides health checks.
When those three conditions hold at the same time, the legacy system gets switched off and its configuration archived in case something nobody remembers turns up. In a migration done right, that day arrives without drama — because in practice, the system wasn't doing anything anymore. The shutdown announcement goes out over internal email, not a press release.
Got a migration ahead of you and don't know where to start? At Eme Integrations we design and run migrations to MuleSoft with this approach. Let's talk.