Can we really replace commerce without touching SAP?

Yes. The strangler fig replaces the layers around the financial core — order capture, stock, loyalty, returnables, delivery, analytics — while SAP keeps the general ledger, pricing and tax. That boundary is what makes the migration bounded and safe to run in production.

How long does a strangler fig commerce migration take?

For an enterprise estate, plan on 12 to 24 months. Public digital-backbone programmes reached their top markets within a couple of years by piloting then scaling capability by capability, which is the same order-of-magnitude we see in our own delivery. It is a sequence, not a cutover weekend.

What is the biggest risk during coexistence?

Dual-write drift. If two code paths both write the same order or customer, they diverge slowly and silently. Name one system of record per entity, use change-data-capture so the legacy side emits and the new side subscribes, and reconcile continuously rather than trusting that both writers agree.

The strangler fig: replacing a commerce stack while it runs

Use the strangler fig pattern. Put a routing layer in front of your existing commerce stack, then move one capability at a time — order capture, stock, loyalty, returnables — onto new services while the old system keeps serving everything else. The SAP financial core stays put. Old and new run side by side until each new slice is proven, then the legacy path is retired. Budget 12 to 24 months, not a launch weekend.

What is the strangler fig pattern, actually?

Named by Martin Fowler after the Queensland fig that grows around a host tree until the original rots away, the strangler fig pattern replaces a system incrementally rather than in one cutover. The idea is roughly two decades old and has aged well. A facade — a routing layer or API gateway — sits in front of the legacy stack and decides, per request, whether a given capability is served by the old system or a new one. You move behaviour a thin slice at a time.

The headline is the easy part. The catalog Fowler and James Lewis published on patterns of legacy displacement is the useful part, because its central admission is uncomfortable: the old and new systems have to coexist and interoperate for a long time, and the division of labour between them shifts continuously as the legacy withers. Coexistence is the hard problem. The routing is trivial by comparison.

Why not just re-platform in one go?

Because the failure mode of a big-bang commerce cutover is total, and the thing you are cutting over is where the orders come in. A large brewer's commerce estate is never one system; it is a decade of accretion. One top-3 global brewer publicly reports consolidating roughly 40 separate sales platforms into a single B2B commerce layer. You do not swing 40 platforms and their reconciliations over a weekend, and you certainly do not do it while SAP is posting revenue against them.

The strangler fig also keeps the financial core where it belongs. The SAP general ledger, pricing and tax stay in place; you replace the customer-facing and operational layers — order capture, stock, loyalty, returnables, delivery, analytics — around it. That constraint is a gift, not a limit: it draws a clean line between where new services end and the system of record begins. It also means the migration is bounded. You are not touching the thing the CFO watches.

How do you sequence it without corrupting data?

The order matters more than the tooling. This is the sequence we run.

Draw the capability map and pick one thin slice. Small enough to replace inside a quarter, valuable enough that finishing it proves something. A single loyalty accrual or one order-capture channel is a good first cut. Billing is not.
Stand up the routing facade and the bus before any new service exists. Put the indirection layer in front of the legacy stack first, so every request is interceptable and every state change is observable. We route on one event bus rather than a chain of point-to-point adapters, for reasons we set out in the case for one bus over a middleware translation chain.
Name one system of record per entity, and never dual-write. The moment two code paths both write the same customer or order, you have signed up for reconciliation forever. Instead, let the legacy system emit changes and have the new service subscribe — change-data-capture and event interception, not a second writer.
Run coexistence with reconciliation, not faith. Shadow the new slice against live traffic, compare outputs continuously, and alert on divergence before you route a single real customer to it.
Prove the slice the way a board can judge it, then retire the legacy path. Canary a slice of traffic, watch the reconciliation stay flat, cut over, and — this is the step everyone skips — delete the transitional plumbing. Proving it to a sceptical steering committee is its own discipline, covered in designing a pilot your board can actually judge.

An honest note from our own runs: the first coexistence window is where it bit us. A returnables balance matched at midnight and had drifted by noon, because two paths were quietly both writing it. We stopped, made the legacy path emit events and the new service read-only until cutover, and the drift stopped. It cost us a sprint we had not budgeted. Assume you will pay that tax once, and design so you only pay it once.

What order should the slices go in?

Sequence by blast radius and coupling to the ledger, not by which team shouts loudest. Read-heavy and capture capabilities go early; anything that moves money or books a liability goes late, because it touches SAP.

Slice	When	System of record during coexistence	Why
Order capture	Early	New service; SAP for pricing/tax	High volume, low ledger risk
Stock and availability	Early	New service	Read-heavy, easy to shadow
Loyalty accrual	Mid	New service	Reversible, small blast radius
Delivery and proof-of-delivery	Mid	New service	Operational, off the ledger
Returnables deposits	Late	SAP-backed	Touches deposits and liabilities
Analytics	Continuous	The bus	Downstream of every other slice

That cadence matches the public record. Per one top-3 global brewer's documented digital backbone programme, an initial toolkit reached its top 20 countries and a standardised source-to-contract process reached 70 countries within a couple of years — a plan, design, pilot, then scale sequence, not a launch weekend. Our own delivery lands in the same 12-to-24-month band, and the country-by-country shape is the strangler fig applied to geography as well as capability.

Where does it go wrong?

Three failure modes recur, and none of them are the routing layer.

Dual-write drift. Two writers on one entity guarantee slow, silent divergence. Pick a single system of record per entity and enforce it; treat any dual-write as a defect, not a phase.
The facade becomes forever. The routing layer and transitional adapters are scaffolding. Fowler's own guidance on transitional architecture is that you must plan its demolition; skip that and you have permanently added a network hop and a team to maintain it.
CDC lag surfaces as customer-visible inconsistency. A five-second replication delay is invisible in a demo and very visible when a rep re-reads an order they just placed. Set and monitor a freshness budget, and route reads that need it to the authoritative side.

The forward-looking part is that the routing facade is getting cheaper to build. As services become genuinely API-first and their contracts become machine-readable, the indirection layer stops being bespoke integration code and starts being configuration — which is the shift we trace in the end of the integration project. The strangler fig will still take a year or two on a real commerce estate. It just stops being the part you dread.