The strangler-fig pattern, applied to ERPs
Notes from a 22-month SAP migration with no big-bang.
ERPs are not application monoliths
They are organisational monoliths. Replacing one is mostly a change-management programme with a software exoskeleton. This is the lens that makes the strangler-fig pattern work.
Step 1 — Identify the boundary
For ERPs the cleanest boundary is usually the master data layer. Once you can route master-data reads through a new service, every downstream module becomes a candidate for migration in turn.
Step 2 — Build the side-car
A side-car platform (in our case Mendix on the customer-facing side, microservices on the back) consumes the master data, owns the modern UX, and writes back via dual-write to the legacy ERP for the duration of parallel run.
Step 3 — Migrate by domain
Procurement, finance, manufacturing, HR — each domain takes its turn. Each migration is its own change-management exercise with its own go-live, its own training, and its own success metrics. None of them are big-bang.
The 22-month timeline
For the SAP backbone we replaced last year, the total elapsed was 22 months. The legacy ERP was retired in month 23. Zero customer-facing outage. The change-management bill was as large as the engineering bill — and worth every cent.
Related articles.
Why mainframe modernisation finally pays back
6 minWhy mainframe modernisation finally pays back
Read articleThree patterns that make AI agents production-safe
4 minThree patterns that make AI agents production-safe
Read articleFinOps after the GPU bill: what we learned
7 minFinOps after the GPU bill: what we learned
Read articleWant to discuss this?
A senior partner will respond within one business day.