Case note: replacing the commerce layer, SAP FI untouched

Yes. We replaced a brewer's order-capture and commerce layer while its SAP financial core kept every posting it had before. The trick is boring: a strangler, one capability at a time. SAP stays a subscriber, receiving postings as IDocs - the shape it already speaks. Order capture moved first, then stock projection, then the invoicing feed. Old and new ran side by side per flow; rollback was a routing switch, not a restore. Finance never noticed the plumbing change.

Why not just rip the old commerce layer out?

Because the one component you must not gamble with is the ledger, and a big-bang swap gambles with all of them at once. The commerce layer - order capture, pricing, promotions, the rep app - can be rebuilt, and if it misbehaves for an hour you lose orders you can replay. The financial core cannot be treated that way: a double-posted invoice or a missing revenue line is a number an auditor asks about next year. So the design has to keep SAP FI exactly as it is while everything in front of it changes.

That is what the strangler fig pattern is for. Martin Fowler named it after the vines that grow around a host tree until they can stand without it: you build the new system around the edges of the old one, move behaviour across piece by piece, and the legacy system keeps running until nothing calls it. No cutover weekend, no all-or-nothing switch. The unit of risk is a single capability, not the whole estate - which is the only version of this a CFO will actually sign.

What does “SAP stays the financial core” mean in practice?

It means SAP does not change at all; it keeps receiving the postings it always received, now from us instead of the old commerce layer. Our platform emits billing and movement documents as IDocs - SAP's intermediate-document format, the inbound interface it has spoken for decades. From SAP's side there is no migration, no new connector, no clean-core exception to negotiate: a document arrives on the same port and posts the same way. We are a new producer of an old message, not a new system SAP has to learn.

This is not a contrarian bet; it is where the industry's most-cited B2B platform already went. AB InBev's BEES was built as a purpose-designed microservices platform explicitly to reduce its dependency on legacy ERP, and it scaled to 2.7 million monthly active users across 17 markets and 6.5 billion dollars of GMV in a single quarter without turning the ERP into the system of engagement. Heineken's public “Digital Backbone” makes the same split structural: a lean SAP S/4HANA core replacing ERPs across 80 operating companies, flanked by cloud business platforms that do the customer-facing work. Lean core, rich edge, a stable contract between them. We just apply it one flow at a time.

How do you strangle a commerce layer without touching SAP FI?

In an order that puts financial risk last. We sequenced by how close a capability sits to the ledger, moved one at a time, and never removed the old path until the new one reconciled clean. The shape of that split - lean financial core, everything customer-facing on a shared event bus in front of it - is our platform architecture. The sequence:

The steps we would run again, in order:

1. Put a routing seam in front of everything. A thin layer decides, per flow, whether a request goes to the old commerce path or the new one. Every cutover and every rollback is a change to this seam and nothing else. If rollback means a restore, you have not built a strangler.
2. Move order capture first, read-only against the ERP. It consumes pricing, credit and master data but posts no financials, so it is the cheapest capability to get wrong. It is also where the latency win lands - the same move that took order capture from 13 seconds to sub-second.
3. Build stock as a projection, not a query. Rebuild an available-to-promise view from movement events and reconcile it to ERP stock daily. It informs orders but still posts nothing, so it can run in shadow for as long as you need before anyone relies on it.
4. Move the invoicing feed last, and dual-run it. Emit billing IDocs beside the legacy feed and diff both against what SAP actually posts, every night, until the difference is zero for several consecutive cycles. Only then does the routing seam make your feed the active producer.
5. Reconcile to SAP daily, and make the diff the gate. No capability cuts over on a calendar date; it cuts over when its reconciliation against the financial core has been clean long enough that finance is bored. The ledger stays the arbiter - the discipline that lets a price-ladder change reach every channel the same day without arguing with the books.
6. Enforce one active producer per flow. At any instant exactly one path may post to a given flow. The seam guarantees it. This is the rule we learned the hard way.

What did we observe, and what broke?

Framed as our own monitoring rather than any client's claim: each capability ran beside its predecessor for roughly four to six weeks before we trusted the routing seam to it, and no cutover happened until the nightly reconciliation had shown zero drift for several consecutive cycles. Rollback, when we rehearsed it, was a single change to the seam that took effect in seconds. The property that made the whole thing approvable was exactly that - any capability could go back the way it came without a restore.

Now the honest part. The invoicing feed is where we got humble. During the dual-run window both the legacy feed and our new feed were emitting billing IDocs into SAP, and SAP - doing precisely what it was told - posted both. Our idempotency key did not line up with the legacy path's document numbering, so a batch of invoices posted twice before the nightly reconciliation caught the divergence and we reversed it. Nobody's month closed wrong, because the diff against the ledger is a gate and not a report, but it was an uncomfortable morning. The lesson was mundane and is now a rule: exactly one active producer may post to a flow at any instant, enforced at the seam, never assumed. “SAP speaks IDoc” is true; “SAP will de-duplicate two producers for you” is not.

That reconciliation habit paid off past invoicing. Once stock and movements are a trustworthy projection, the same numbers settle arguments they used to start - like ending the monthly empties-balance argument between depot and brewery, where both sides had been quoting different figures from different systems.

The commerce layer is now several capabilities lighter on the legacy stack, and each flow that moved made the next one cheaper, because the routing seam and the reconciliation gate were already built. What we are watching for now is the quiet endpoint of the pattern: the moment the last flow leaves the old path and the legacy commerce layer has nothing calling it at all - when the host can be switched off, and SAP, still posting exactly as it did on day one, never knows it happened.