Why ERP migrations actually fail (it is almost never the software)

The failures rarely come from the software. They come from how the switch was managed — which is the part you control.

Ask a manufacturer why their last ERP project went badly and you will usually get a story about the software. It was too rigid, the vendor overpromised, the modules did not talk to each other.

Sometimes that is true. Far more often, the software was fine and the switch was managed badly. Which is worth knowing, because the second problem is one you control.

Here are the five that do the most damage.

Mistake 1: rebuilding your old process in new software

This is the most common and the most expensive. The current system has twenty years of workarounds baked into it — the spreadsheet that sits beside it, the job number format that means something only to Dave, the two-step approval that exists because of one bad order in 2014.

A new system is the one chance you get to leave that behind. Rebuild it faithfully and you have paid for a migration and kept every problem you were trying to escape.

Instead: map the process you want, then build that. Fix it on the way in. If a step exists only because the old software could not do it another way, that step does not need to survive.

Mistake 2: migrating everything

Nobody has ever regretted migrating less data. Plenty of shops have regretted migrating more.

Fifteen years of closed jobs, obsolete part numbers, and customers who stopped ordering in 2019 do not make the new system more useful. They make search worse, reporting noisier, and every validation error a week-long archaeology project.

Instead: migrate the data that runs the business today — open orders, active customers, current BOMs and routings, live inventory. Archive the rest somewhere you can still reach it if you ever need to.

Mistake 3: the big-bang go-live

Switching every department on one Monday morning is the highest-risk option available to you, and it is the one that gets picked most often, usually because it looks cheapest on the project plan.

The trouble is that everything fails at once, on the day you have the least slack, and you cannot tell which failure is causing which. So you spend the week firefighting instead of fixing, and the team’s first experience of the new system is that it does not work.

Instead: run in parallel, or phase by area, until the new system has proven itself. Yes, parallel running is duplicated effort for a few weeks. It is dramatically cheaper than a bad go-live.

Mistake 4: leaving the floor out of it

Selection meetings tend to fill with the people who will look at reports and empty of the people who will use the system every hour of every shift.

Then go-live arrives, the shop floor discovers a workflow that takes eleven clicks to do what used to take two, and adoption dies. Not through resistance — through arithmetic.

Instead: get the floor involved early, let them shape the workflows they will live in, and train on their real jobs rather than on demo data. The operator who helped design the work order screen becomes the person who defends it.

Mistake 5: picking another system you cannot change

This one is quieter than the others and does the most long-term damage. You escape a rigid system by buying a different rigid system. Every process change becomes a support ticket, a quote, and a six-week wait. Within two years the spreadsheets are back, because that is what people do when the software will not bend.

Instead: weight adaptability properly during selection. Ask specifically: when our process changes, who makes the change, how long does it take, and what does it cost? If every answer routes through the vendor, you already know how this ends.

The question is not whether the software fits your process today. It is who gets to change it when your process changes.

The phased approach that avoids all five

The guide lays out six steps in order:

1. Assess the actual problems — the specific ones, not “our ERP is old”
2. Test with your real workflows — your parts, your routings, your awkward orders
3. Pilot with a difficult job — the easy ones prove nothing
4. Migrate selectively — today’s operating data, not the archive
5. Phase the rollout — by area, with parallel running where it matters
6. Keep improving after go-live — the switch is the start, not the finish

Step six is the one most projects skip, and it is where the compounding value lives. A system that improves monthly after go-live beats a system that was perfect on day one and frozen ever since.

Where an adaptable system changes the math

Four of these five pitfalls are process discipline. You can fix them with good project management and a willingness to say no.

The fifth one is structural, and it is the reason we built Tangle the way we did. Milo, Tangle’s built-in AI engineer, can read and change the system from a plain-English description of what you want — so the approval rule you need in month four is a conversation, not a change request. You preview the change before it goes live, and you keep the flexibility that usually gets traded away at signature.

It also takes pressure off mistake 1. You no longer have to get every process decision right during implementation, because getting it wrong is cheap to correct.

→ Download the guide: 5 Pitfalls to Avoid When Switching ERP

---

See what your current system cannot do

Tell us the process your current ERP makes you work around. We will show you what it looks like when the software adapts instead.

→ Book a 30-minute demo → Try Tangle free

---

By Tangle Software Inc. Tangle is the world’s first self-customizing ERP for manufacturers, with Milo wired into every customer’s instance. tangle.io.