Replacing a legacy ESB (enterprise service bus) without a big-bang rewrite means moving integrations to a new platform gradually, while the old bus keeps running. Instead of rebuilding hundreds of interfaces and switching over in one weekend, teams migrate in waves: a few integrations at a time, tested in parallel, with the ability to roll back. Business processes keep working throughout, and risk is spread across many small, reversible steps.
This guide covers why big-bang ESB replacements fail, the strangler pattern for integration, and a practical wave-by-wave plan. If you're on TIBCO, see our TIBCO BusinessWorks migration guide.
Why big-bang ESB replacements fail
- Hidden scope: old buses carry years of undocumented logic, mappings, and workarounds, discovered only during the rebuild.
- One cutover, many failure points: if anything goes wrong, everything goes wrong at once.
- Frozen change: while the rewrite runs, business requests for new integrations wait.
- Testing limits: it's hard to test hundreds of interfaces end to end before one cutover date.
- Long timelines: multi-year rewrites lose sponsors, budget, and the people who understood the old system.
The strangler pattern for integration
The strangler pattern, named after the strangler fig that slowly grows around a tree, replaces a legacy system piece by piece. For an ESB:
- Put a routing layer in front of the integrations consumers call, such as an API gateway or proxy, so traffic can be switched per interface.
- Rebuild one integration on the new platform.
- Run both in parallel and compare the results.
- Switch traffic for that integration to the new platform.
- Retire the old version, then repeat with the next.
Over time the new platform handles more and more traffic, until the ESB carries nothing and can be switched off.
A wave-by-wave migration plan
1. Inventory and classify
List every integration on the bus: endpoints, consumers, protocols, message formats, volumes, schedules, and owners. Classify each by business criticality and technical complexity. Expect to find interfaces nobody uses any more; retiring them is a free win.
2. Plan the waves
| Wave | What moves | Why |
|---|---|---|
| Pilot | 2-3 low-risk integrations with clear owners | Prove the platform, patterns, and process |
| Wave 1 | High-value, low-complexity integrations | Show business benefit early |
| Wave 2 | Integrations sharing the same systems or patterns | Reuse connections and mappings |
| Later waves | Complex, critical, or heavily customised flows | Move when the team and patterns are mature |
| Final | Remaining interfaces and decommissioning | Switch off the bus |
3. Build reusable foundations
Set up shared connections, canonical data models, error handling, and monitoring once, in the pilot. Every later wave reuses them, which is where incremental migration gets faster over time.
4. Run in parallel and reconcile
For each integration, run old and new side by side, compare outputs (record counts, totals, key fields), and fix differences before switching traffic.
5. Switch, watch, and retire
Move traffic through the routing layer, monitor closely, keep the old route available for rollback for an agreed period, then remove it.
Keeping business running during migration
- Freeze changes per integration, not globally: only integrations in the current wave pause for changes.
- Agree rollback rules with business owners before each switch.
- Communicate cutovers to the teams who depend on each interface.
- Track progress publicly: integrations moved, traffic on the new platform, and interfaces retired.
Choosing the target platform
The new platform should support the protocols your ESB carries today (REST, SOAP, files, messaging), run where your systems run (cloud, hybrid, or on-premise), and give operations teams better visibility than the bus did. See iPaaS vs ESB for how the two architectures compare.
Frequently asked questions
How do you replace an ESB without downtime?
Migrate incrementally: run the old ESB and the new platform side by side, move integrations in waves through a routing layer, test each in parallel, and keep a rollback path until it's stable.
What is the strangler pattern?
It's a way to replace a legacy system gradually by routing functionality to a new system piece by piece until the old one handles nothing and can be retired.
How long does an ESB migration take?
It depends on the number and complexity of integrations. Incremental migrations deliver value within weeks for the pilot and then progress wave by wave over months.
Should we rebuild ESB integrations exactly as they are?
No. Use migration to remove unused interfaces, consolidate duplicates, and replace custom code with standard patterns, while keeping the business behaviour the same.
What should replace an ESB?
Usually an iPaaS or hybrid integration platform that supports your protocols, runs where your systems do, and offers better governance and monitoring than the bus.
Move off the bus one wave at a time
Incremental replacement turns a risky rewrite into a series of small, reversible wins. To plan an ESB migration with Koodisi, book a demo.