Modernizing a Legacy ERP Without Replacing It

This article's thesis, and it is refutable: encapsulating a legacy ERP — API, integration layer, modern front end — delivers most of the value of a modernization at a fraction of the risk of a full replacement. Not because replacements always fail: because their risk distribution is untenable.

The reference study is dated; its lesson is statistical, not seasonal. In 2011, Flyvbjerg and Budzier (Oxford) analyzed 1,471 IT projects: the average cost overrun was 27%. That average is falsely reassuring. One project in six blows up by 200% in cost and close to 70% in schedule.

Audited cases put a face on that tail:

The decisive detail in the Birmingham case: the replaced system had been in service since 1999 and cost £5.1M a year. It worked. The audit blames the project's governance and change management — never the product or its vendor. The legacy system was not the problem: it was an asset.

The pattern has a primary source: Martin Fowler, who named it after observing strangler figs in Queensland in 2001. His reference post, rewritten on August 22, 2024, sums up the fate of wholesale rewrites in eight words:

"Go down in flames most of the time" — Martin Fowler, on cut-over rewrites, Strangler Fig Application (August 2024 version).

The idea rests on three claims. Replacing in small components spreads the risk. Return on investment arrives earlier, while the legacy system keeps doing its job. Above all, the pattern caps the maximum loss of each step: a risk-management argument, not an architecture fashion.

This is no longer a blog opinion. Microsoft describes it in its Azure Architecture Center: a facade intercepts requests and routes them to the legacy system or to new services; "the incremental approach mitigates risks compared to large systemic changes." AWS turned it into prescriptive guidance for modernizing legacy web services, explicitly crediting Fowler. This logic of bounded steps, each delivering its own value, also shapes how we build.

Many ERPs in production expose their functions over SOAP. That is not a flaw: SOAP 1.2 is a 2007 W3C Recommendation, "a lightweight protocol intended for exchanging structured information" — an open, documented standard that does not expire. In 2023, 26% of Postman's 40,000+ survey respondents still used it. Wrapping a legacy SOAP API is the daily work of thousands of teams.

The approach AWS documents comes in three moves:

1. Facade    : proxies acting as simple pass-throughs in front of existing SOAP services
2. Contract  : each function described in an OpenAPI specification (v3.2.0, Sept. 2025)
3. Migration : progressive rerouting, service by service, to modern REST APIs

AWS recommends starting with components that are well tested, carry little technical debt, and need to evolve the most. Between the new front end and the ERP, a translation layer — the anti-corruption layer, a pattern from Eric Evans's Domain-Driven Design, documented by Microsoft — shields new services from the legacy system's semantics. Its costs are acknowledged: added latency, and one more service to operate. Encapsulation is not free; it is bounded. This step-by-step framing is detailed in our method.

The end of mainstream maintenance for SAP Business Suite 7, announced by the vendor in February 2020 for the end of 2027, feeds an urgency-to-replace narrative. Yet the same announcement provides optional extended maintenance through the end of 2030, for two additional points on the maintenance base. The vendor itself thus leaves time on the table. Encapsulation lets you use it: the facade absorbs the deadline instead of suffering it.

The opposite risk exists: an encapsulation that never "strangles" anything. The GAO (the US government's audit office) measured it in July 2025: of 10 critical legacy systems identified in 2019, only 3 had completed their modernization by February 2025. The remedy is in the pattern itself: every step must deliver standalone value — a usable front end, an integration in production — not merely prepare the next one.

What doing nothing costs — US federal agencies spend more than $100 billion a year on IT, about 80% of it operating and maintaining existing systems (GAO, July 2025). Of the 11 critical legacy systems surveyed, aged 23 to 60 years, 8 run on obsolete languages and 7 carry known security vulnerabilities. Waiting does not freeze the cost: it concentrates the risk into a future project that only grows bigger.

Modernizing an ERP without replacing it is a decision made on comparable criteria; every figure maps to the sources at the end of this article.

In committee, demand for every scenario the answer to a single question: what is the maximum loss if this step fails? To run this comparison on your own system, our services cover everything from auditing the existing estate to the integration layer.

Encapsulation does not apply everywhere, and Microsoft's documentation itself lists the contraindications: requests that cannot be intercepted by a facade; a system small and simple enough that direct replacement costs less than the scaffolding; an urgent need to decommission. Add the anti-corruption layer's own costs: extra latency and one more service to operate and monitor. Finally, the pattern demands delivery discipline: without standalone value at every step, you get the eternal strangler — one more layer on top of the legacy system, precisely what you set out to avoid. If your system ticks one of these boxes, direct replacement may be the right answer.