Monolith to Microservices: The Strangler Pattern in Banking

A full core banking replacement fails close to four out of five times. And yet, it's still the default plan at too many institutions. There's a better way, and we owe it to a fig tree.

Let's start with the uncomfortable figure. An executive at a European banking-software vendor, Karl im Brahm of Objectway, estimated in 2025 that the success rate of core migrations is barely around 20%—meaning roughly 80% of projects fail—almost always because of incomplete data or the sheer magnitude of changing everything at once, as he stated in The Wealth Mosaic. Switch off the old, switch on the new: the all-or-nothing bet we've already described as a nightmare in another article. The good news is it isn't the only option.

A fig tree, a pattern

In 2001, software engineer Martin Fowler traveled to the rainforests of Queensland, Australia, and watched the strangler figs. These plants germinate at the top of a host tree, grow downward around it, and gradually envelop it until they become self-sufficient. Over time, the original tree dies and only the fig remains, in the exact shape of what it replaced. Fowler saw a metaphor there for how to modernize software, and named the pattern: the Strangler Fig, as he tells it himself.

The idea is elegant for its simplicity. Instead of replacing the core in one blow, you build the new around the old, piece by piece. Each new capability is stood up separately, and little by little you migrate behavior from the legacy system to the new one, until the old one does nothing and can be switched off without drama. The system never stops operating. Risk gets spread over time instead of concentrated into one terrifying weekend.

How it works, concretely

The mechanism, as documented in Microsoft's reference architecture, revolves around a façade—a proxy—placed between the client applications and the systems (old and new). That façade intercepts each request and routes it: to the legacy what still lives there, to the new services what's already migrated. As the migration advances, the façade sends more and more traffic to the new system. When nothing is left in the old one, it's decommissioned; in the end, even the façade disappears.

It goes in four phases, repeated for each capability: build the new service, redirect traffic to it, retire the function from the legacy, and, at the close, clean up.

The part that really costs: the data

Here it's worth being honest, because it's where almost every article tiptoes. Decomposing the application logic is the manageable part. The database is where migrations get stuck. A core banking system isn't just any app: it's the ledger, and it has to balance to the cent while you modernize it live.

The practice Microsoft documents for this combines an initial domain-by-domain data load with real-time change data capture (CDC) to keep the old and new systems synchronized during coexistence, validating consistency before any definitive switch and always leaving the door open to a rollback. No migrating blind.

And there's a technical challenge specific to decomposing a core into microservices that deserves naming: transactional consistency. When a transaction crosses several services, the strong guarantees you're used to become hard to maintain. The standard pattern for coordinating distributed transactions—the Saga—solves the coordination but sacrifices isolation: other processes can see intermediate data before the transaction finishes, as Microsoft's own documentation warns. In most systems that's tolerable; in the movement of money and the consistency of a banking ledger, it isn't. That's why decomposing a core isn't done with generic microservices recipes: it's done knowing which parts demand iron-clad guarantees and which don't.

Where to start (and where not to)

The practical rule that works: start with the low-risk, low-coupling seams—usually the customer-facing things, what changes often and hurts to have trapped in the monolith—and leave the transactional flows at the heart of the core for last. So the old and new can coexist without contaminating each other, you place an anti-corruption layer between them that translates between both worlds and keeps the legacy's semantics from leaking into the new design. That's what lets you decouple gradually without inheriting twenty years of bad habits.

This isn't a niche bet. The consultancy IDC projects that 40% of the world's banks will run a modern core alongside the legacy by 2026, as cited by Galileo Financial Technologies, a figure expected to keep rising in the years that follow. Progressive modernization stopped being the cautious option and became the majority one.

How we see it at WAU

At WAU we apply the Strangler pattern to the reality of a core banking system: we identify the first seam that unlocks value fast, stand up the new service, synchronize the data with change capture and rollback always available, and protect each domain with an anti-corruption layer. And we treat transactional consistency with the care money demands, not with textbook recipes. You modernize without switching anything off.

If your core already drags but a full replacement seems—rightly—like too much risk, let's talk. We'll map your first seam together. 👉 Book a conversation with our team.

Sources

• The Wealth Mosaic / Objectway — Karl im Brahm: why 80% of core migrations fail (Oct 2025)

• Martin Fowler — Strangler Fig Application (2024; original 2001 observation)

• Microsoft Learn — Strangler Fig pattern: façade, phases, CDC and rollback

• Microsoft Learn — Saga pattern: distributed transactions and loss of isolation

• Microsoft Learn — Anti-Corruption Layer pattern

• Galileo Financial Technologies — 40% of banks to run a sidecar core by 2026 (citing IDC)