“We need to replace our ERP” is a sentence we hear several times a year. It is almost always the wrong sentence. ERP replacements are the most expensive, longest-running, highest-failure-rate IT projects in the enterprise software canon, and the companies that attempt them rarely appreciate what they are signing up for until they are two years in. There is usually a less dramatic path that gets most of the benefit.
Why ERP replacements fail
The same reasons every time: scope expansion, data-migration surprises, vendor change-orders, organizational resistance, and the years-long parallel run during which both versions of the truth coexist. By the time the new system is live, the original team has turned over, the requirements have shifted, and the project is a museum exhibit of decisions made by people who are no longer there.
Notice that none of those failure modes are technical. The database migration is rarely what kills the project. What kills it is that a full replacement forces the entire organization to change everything at once — every workflow, every report, every muscle memory — while the business keeps running. That is an organizational bet, and it is the kind that fails on a coin flip regardless of how good the new software is.
Meanwhile, here is the part that should change the conversation: most legacy ERP pain is concentrated in three or four specific places. Reporting. Integrations. A clunky interface for one high-frequency workflow. A capability the business has outgrown. The other 70 percent of the ERP — general ledger, inventory postings, payroll runs — works fine and has worked fine for fifteen years. A full replacement throws out the working 70 percent to fix the painful 30.
The strangler-fig alternative
The strangler fig grows around an existing tree, gradually taking over its structure until the original is optional. The software version replaces the painful surfaces of the ERP one at a time, leaving the ERP as the system of record for everything else.
What we typically build
A thin API layer over the legacy ERP that exposes the data modern surfaces need, plus one or two modern web applications that use that API to deliver the specific workflows the business has outgrown. Operationally, the ERP keeps running: it still posts the transactions, still closes the books, still holds the master data. Functionally, the people who spent their days fighting it now work in fast, purpose-built screens that happen to read and write through the ERP underneath. This is the core of our integrated business systems practice, and the same layering works whether the legacy anchor is an ERP, an old CRM, or a homegrown system nobody dares touch — we walked through the CRM-and-billing version of it in Connecting Your CRM, Billing, and Fulfillment Without Replacing Everything.
Picking the first module
Start where pain is high and coupling is low. Reporting is usually first: it is read-only, so a bug produces a wrong chart instead of a corrupted ledger, and it delivers visible value to executives in weeks. A customer- or vendor-facing portal is a common second, because the ERP’s own screens were never meant for outsiders anyway. Save deeply coupled, write-heavy workflows — order allocation, costing — for later, when the API layer has earned trust in production.
Each replacement is a normal-sized software project. Our first production releases typically land in 8 to 16 weeks with weekly demos, which means the business sees working screens every Friday instead of waiting two years for a big-bang cutover.
After two or three targeted replacements, the original ERP is doing 30 percent of what it used to. At that point the team has earned the right to make an informed decision about whether to retire it — and crucially, the modern surfaces already work, so even a full retirement is no longer a single high-stakes event.
Where AI fits
Modern AI features almost always live in the new surface layer, not the legacy ERP. That is fine. An AI-assisted reporting layer that reads through the new API — plain-language questions over live operational data, drafted variance explanations, anomaly flags on unusual transactions — gives users a step-change improvement without touching the ERP itself. The vendors of twenty-year-old systems are not going to ship this; the surface layer you control can. It is the same principle behind all of our AI development work: put the intelligence where the modern, well-instrumented code is, and let the system of record keep doing the one job it is good at.
The trade-offs, honestly
Strangler-fig is not free. The API layer becomes real infrastructure someone must own and monitor. You keep paying the legacy vendor’s maintenance while the fig grows. And the approach demands discipline: every new customization bolted into the ERP after the strategy starts is a step backward, so someone has to be empowered to say “that goes in the new layer.”
There are also cases where full replacement genuinely is right — the vendor has announced end-of-life, the platform no longer runs on supportable infrastructure, or the license economics have become punitive. Even then, the strangler-fig work is not wasted: cutting over a business that already runs its daily workflows in modern surfaces is a far smaller event than cutting over one that lives entirely inside the old system.
How to start
Inventory the pain before anyone proposes a platform. List the workflows people complain about weekly, who touches them, and what each one costs in hours or errors. If the list has three items on it instead of thirty, you do not have an ERP replacement problem — you have three well-scoped software projects.
If your organization is staring down a replacement that smells like a multi-year, multi-million-dollar bet, it is worth a serious analysis of whether two or three targeted strangler-fig projects could deliver 80 percent of the benefit for 20 percent of the cost. The answer is yes often enough to be worth asking, and a free 30-minute discovery call is a cheap way to find out which case yours is.