After five years of working with ERP systems across manufacturing and e-commerce, I have implemented or migrated organizations onto Epicor, Oracle Cloud, CMS, and SAP. Each project taught me something the previous one did not. Some of those lessons came from success. Most came from things that went sideways.

Here is what I wish someone had told me before my first go-live.

Why ERP Projects Fail

The most common reason ERP projects fail has nothing to do with the software. It is almost always a people problem disguised as a technology problem.

I have seen organizations spend months configuring BOM structures and routing operations down to the decimal, only to discover that nobody on the shop floor understood how to log completions in the new system. The data was perfect. The adoption was zero.

In one manufacturing implementation, we had MRP runs producing technically correct suggestions that planners completely ignored because the lead times in the system did not reflect reality. The vendor had configured everything by the book, but nobody had walked the floor to validate the assumptions baked into the planning parameters.

ERP projects fail when the implementation team treats the system as a software install rather than a business transformation.

The Gap Between Vendor Promises and Reality

Every ERP vendor will show you a demo where everything works beautifully. The data flows, the dashboards update in real time, and the reports look polished. What they do not show you is the six months of data cleansing, the custom integrations your specific environment requires, and the workarounds you will build because their out-of-the-box functionality does not quite fit your process.

When I moved from CMS to Epicor for a mid-size manufacturer, the vendor positioned it as a straightforward migration. In practice, the shop floor reporting module needed significant customization to handle the way our production teams tracked scrap and rework. The BOM structures translated cleanly on paper, but the way engineers managed revisions in the old system had no direct equivalent in the new one.

With Oracle Cloud, the promise of seamless cloud updates turned out to mean quarterly updates that occasionally broke custom reports. With SAP, the depth of configuration was impressive but the learning curve for end users was steep enough that we needed double the training time we had originally budgeted.

None of this makes these bad platforms. It means that every implementation requires honest scoping, and honest scoping means talking to the people who will actually use the system every day.

Change Management Is Not Optional

I have trained over 30 production staff during ERP rollouts, and the single biggest factor in whether a system sticks is not how good the software is. It is whether the people using it believe it makes their job easier.

On the shop floor, operators care about three things: Can I clock into my job quickly? Can I see what I need to run next? Will this system make me look bad if I enter something wrong? If the answer to the first two is no and the third is yes, you have already lost them.

The most effective training approach I have found is running parallel systems for two to four weeks. Let people use the old process alongside the new one. It doubles the work temporarily, but it builds confidence. When operators see that the new system produces the same results as the spreadsheet they trust, resistance drops significantly.

I also learned to identify the informal leaders on every shift. These are not always supervisors. They are the people others go to when they have a question. Get those individuals comfortable with the system first, and they become your best trainers.

Manufacturing ERP vs. E-Commerce ERP

One thing that surprised me was how different ERP looks in manufacturing versus e-commerce. In manufacturing, the complexity lives in production planning — work orders, MRP, shop floor control, quality holds, and BOM management with multi-level assemblies. The transactional volume is moderate but each transaction is complex.

In e-commerce, the complexity flips. Transactions are simple but volume is massive. Inventory accuracy needs to be near-perfect because a customer can see stock in real time. The integration layer between the ERP and the storefront becomes the critical path, and any latency there directly costs revenue.

I have worked both sides, and the mistake I see most often is organizations hiring implementation partners who specialize in one but not the other. A consultant who is excellent at configuring shop floor modules may have no idea how to handle the event-driven integration patterns that e-commerce requires.

What Actually Works

After four platforms and more go-lives than I want to count, my checklist is short:

Walk the floor before you configure anything. Watch how people actually work, not how the process map says they work.

Budget twice the training time you think you need. Then add a week.

Get your data right before migration. Cleaning data during go-live is like changing a tire while driving.

Identify your power users early and invest in them. They will carry the implementation after the consultants leave.

And finally, accept that no ERP will be perfect on day one. Plan for a 90-day stabilization period where you fix what the real world reveals. The organizations that treat go-live as the finish line are the ones that end up on their second implementation two years later.