Why do ERP implementations fail?

Most failures share a few causes: a single big-bang switchover with no way back, heavy customization of a standard product to match every existing habit, underestimated data migration, too little testing with real orders and real volumes, and a schedule set by a calendar rather than by readiness. The cost shows up after go-live, in shipments, invoices and inventory.

What happened in the Vital Farms ERP lawsuit?

Shareholders filed a securities class action on 27 March 2026 in federal court in Austin, Texas, alleging Vital Farms described ERP rollout risks as hypothetical while knowing they were imminent. The ERP went live on 29 September 2025. On 26 February 2026 the company reported 2025 revenue of about $759.4 million against $775 million guidance and acknowledged temporary disruptions in orders and fulfillment after the launch; the stock fell about 10.8% that day. These are allegations, not findings.

What is the Zimmer Biomet lawsuit against Deloitte?

Zimmer Biomet sued Deloitte Consulting on 4 September 2025 in New York Supreme Court, seeking at least $172 million over an SAP S/4HANA implementation. It alleges Deloitte misrepresented its capabilities and delivered an overly customized, defective system after paying $94 million in fees; the system went live in North America on 4 July 2024. Deloitte calls the claim meritless and has moved to dismiss.

How do you avoid an ERP implementation failure?

Change in slices you can stop: keep the parts of your current system that work, move one process at a time, migrate and test with real data before each switch, keep customization out of the core product, and build what the ERP can't do as a separate module next to it. Each slice should end with something in production and a decision point.

Should I replace my ERP or build around it?

Replace it when the core accounting, inventory or production logic no longer fits and the vendor is ending support. Build around it when the core works and what's missing is one process: quoting, a customer portal, a field workflow, a planning tool. Building the missing module is usually faster, cheaper and far less risky than a full replacement.

ERP Implementation Failure: Real Cases and How to Avoid One

A huge tangled machine leaking cubes next to a stalled delivery truck, beside a steady core block with one clean glowing module attached and others waiting in line

ERP implementation failures rarely fail in the software. They fail at go-live, in shipments, invoices and inventory, and they keep failing in public. Vital Farms switched ERP on 29 September 2025. Three months later it missed its revenue guidance, acknowledged order and fulfillment disruptions after the launch, and drew a shareholder lawsuit alleging it had played down the risks. Zimmer Biomet is suing Deloitte for at least $172 million over an SAP S/4HANA implementation it calls overly customized and defective. Different companies, same shape: one big switchover, heavy customization, and no way to stop halfway. Below: what happened in both cases, why ERP projects fail, and how to change your systems in slices you can stop, including when you shouldn't replace the ERP at all.

Vital Farms: a go-live and a guidance miss

From the securities complaint as reported by TipRanks. These are allegations, not findings:

May 2025: the CFO said the ERP launch had moved from summer to early fall "to ensure a flawless switchover".
29 September 2025: go-live. In November the company said a brief production slowdown early in the fourth quarter had been planned and shipments were back to pre-launch levels, and raised guidance to $775 million.
26 February 2026: 2025 revenue came in at about $759.4 million, below guidance. The annual report acknowledged temporary disruptions in orders and fulfillment after the ERP launch, and management talked about recapturing shelf space. The stock fell about 10.8% that day.
27 March 2026: shareholders filed suit in federal court in Austin, alleging the risks were described as hypothetical when they were already happening.

Zimmer Biomet v. Deloitte: $172 million

From the complaint as reported by Loeb & Loeb and others. Again, allegations:

Filed on 4 September 2025 in New York Supreme Court, seeking at least $172 million.
Zimmer Biomet says Deloitte assured it could deliver SAP S/4HANA on time and on budget with minimal customization, then delivered an overly customized system with defects after $94 million in fees.
The system went live in North America on 4 July 2024, after repeated delays, and Zimmer Biomet claims tens of millions in remediation and disruption to operations and the supply chain.
Deloitte calls the claim meritless and has moved to dismiss.

Why ERP projects fail

The same causes show up in almost every case:

The big bang. Every process switches on one date. If anything is wrong, everything is wrong, and there is no road back.
Customizing the core. A standard product is bent to match every existing habit, and each customization becomes something to test, maintain and break on the next upgrade.
Data migration underestimated. Years of inconsistent customer, item and price data meet a system that expects it clean.
Testing with demo data. The system works on fifty clean orders and fails on a real Monday morning.
A date set by the calendar, not by readiness. "Early fall" becomes a commitment to investors before anyone knows whether it is achievable.

The alternative: change in slices you can stop

Keep what works. Most companies don't need to replace their whole ERP. The ledger works, inventory mostly works, and what hurts is one process: quoting, a customer portal, shipping, planning, a field workflow. That process can be built as a separate module next to the ERP, connected through its API, without touching its core.

One process at a time. Each slice moves one process, with its own data migration and its own testing on real records, and goes to production before the next one starts.

A stop point after each slice. Every slice ends with something in production and a decision: continue, change course, or stop, with what you built still working.

Keep customization out of the core. If the ERP can't do it as standard, build it next to it, where it can be tested and changed without risking every upgrade.

We have done this kind of work for clients:

A California equipment company's shipping process, from a shared Excel workbook to a web platform in production the day after we received the file.
A quotation platform for Casa Europa where multi-million-peso quotes are correct by construction, next to their existing systems.
A wine distributor's 90-tab Excel price book turned into an application.

A first slice covering one process costs $5,000 to $18,000, and a complete module with several processes $18,000 to $45,000. You own the code, and you can stop after any slice.

Also: SAP ECC and Dynamics GP end of life.

ERP Implementation Failure: What Vital Farms and Zimmer Biomet Show, and How to Avoid Being Next

One company missed its guidance and drew a shareholder lawsuit after its ERP go-live. Another is suing its integrator for $172 million. The failures share a shape: one big switchover, heavy customization, and no way to stop halfway. Here is the alternative.