Why ERP Projects Fail (It's Not the Software)
The statistics are grim and stable: half of ERP programmes overrun materially, and the write-offs make trade-press headlines every year. The root cause is rarely the software. It's the strategy: a big-bang replacement of every process at once, forcing an organisation to relearn how it operates on a go-live weekend, guided by consultants incentivised to maximise scope.
Mid-market firms — 50 to 5,000 people — get the worst of it. Too complex for out-of-the-box SME tools, too small to absorb a seven-figure implementation gracefully, and pressured by vendor end-of-life deadlines (the long shadow of SAP ECC's sunset taught everyone how that feels) into decisions on the vendor's timetable rather than their own.
The Composable Alternative
The strategy that consistently works is to stop treating "the ERP" as one decision. Decompose it:
- The boring core — buy it, keep it small. General ledger, AP/AR, statutory reporting. This is commodity capability; being different here is a liability. A solid mid-market finance system (or even keeping your existing one) is fine.
- The differentiating edges — build them. The processes that make you you — how you quote, plan production, manage stock quirks, price contracts, schedule engineers — are exactly where off-the-shelf ERP modules force damaging compromise. These are now 6-10 week custom builds, not multi-year programmes (our build-vs-buy framework applies directly).
- The connective tissue — invest here first. A clean integration layer (see our API strategy guide) is what makes composable possible: every system talks through defined contracts, so each piece can be replaced independently, forever.
The vendors sell ERP as a heart transplant. Treat it as joint replacements: one at a time, while the patient keeps walking.
Migration Without the Cliff Edge
Whatever you replace, replace it with the strangler-fig pattern we detail in our zero-downtime migration playbook: new capability runs alongside old, traffic shifts gradually, and the legacy module is decommissioned only after the new one has carried real load. We ran a multi-site manufacturing ERP modernisation this way over 14 months with zero production downtime — not because we were lucky, but because at no point did anything depend on a single cutover weekend going perfectly.
Data deserves the same respect: migrate and reconcile domain by domain (items, then customers, then open orders, then history), with automated comparison reports proving old and new agree before anything switches.
The Questions to Ask Before Signing Anything
- Which of our processes are genuinely standard, and which are competitive advantage in disguise? (Vendors will tell you everything is standard. Your margins disagree.)
- What does exit cost? Data export formats, licence terms on your own data, and integration lock-in decide your negotiating position for the next decade.
- Can we phase by module and by site — and will the vendor price it that way, or only as a programme?
- What's the five-year total including licences, implementation, customisation, upgrades and the internal time nobody budgets?
An Honest Word
Sometimes the right answer is to do less: stabilise the current system, build the two or three edge systems causing real pain, and defer the core decision until it's yours to make rather than a renewal deadline's. We tell clients that regularly — a smaller project that ships beats a transformation that doesn't.
ERP renewal looming?
Book 15 minutes before you sign anything — the cheapest ERP decision is often the one you don't make.
Book a 15-Minute Call →