5 ERP integration mistakes and how to avoid them

An ERP integration is rarely a purely technical project. The software usually works. What goes wrong almost always sits in the preparation: processes nobody mapped, integrations that surface too late, data that migrates dirty. Most mistakes are therefore not accidents. They are predictable patterns. Below are the five we see most often, each with a way to prevent it.

In short: ERP integrations rarely fail on technology and almost always on preparation. The five biggest mistakes are choosing without process analysis, underestimating links with existing systems, letting the vendor define when it is done, migrating polluted data and postponing change management until after go-live. Four of the five arise before the first line of code. Mapping processes, integrations and data quality upfront prevents all of them. How an ERP works together with custom business software is explained on our service page.

Timeline: where the five mistakes originate

Four of the five mistakes occur before the first line of code. This is the order in which they appear.

1. Choosing software without analysis
2. Underestimating integrations with satellite systems
3. Letting the vendor define what "done" means
4. Ignoring data quality and data migration
5. Underestimating change management and the real cost

The first four happen before the contract is signed. The fifth only becomes visible after go-live.

The five mistakes

Mistake 1. Choosing software without analysis

Many projects start at the demo. The slickest interface or the best-known name wins. Only then do people check whether the processes fit. You end up integrating a system around ways of working that nobody wrote down first. The consequence: customisation piles up, the standard gets bypassed and every exception becomes expensive extra work after signing.

How to prevent it. Process analysis first. Map your current processes and their exceptions before implementation or development starts. That way you choose on process fit rather than on the demo.

Mistake 2. Underestimating integrations with satellite systems

An ERP never stands alone: web shop, CRM, WMS, accounting, PIM, EDI, CAD. Each integration is a small project in its own right. It has its own data flow, its own owner and its own failure scenario. "We'll solve that later with a standard connector" is the classic that comes back to bite. Forgotten or deferred integrations are a top cause of budget overruns after go-live. Suddenly the ERP turns out to be worth only half without that connection.

How to prevent it. Draw up an integration map. Name every connection, which data flows through it and who owns it, so that no satellite system gets "deferred". In a recent project we mapped eight satellite systems this way before a single quote was on the table.

Mistake 3. Letting the vendor define what "done" means

Without your own acceptance criteria you sign off on a demo that works instead of on your processes that work. The definition of "delivered" then comes from the party that benefits from delivering fast. The consequence shows up after go-live: scope discussions, extra work and no negotiating position left. After all, the contract is already signed.

How to prevent it. Define per phase what "done" means, in your own words and in measurable terms. That way you do not depend on your vendor's definition and everyone knows upfront what gets signed off.

Mistake 4. Ignoring data quality and data migration

Migrating fifteen years of data from the old system without cleaning it is asking for trouble. Duplicate customers, half-filled article numbers, fields nobody understands anymore: the new ERP simply inherits the chaos of the old one. Garbage in, garbage out. Users who see wrong data on day one immediately lose trust in the system.

How to prevent it. Treat data quality and migration as an explicit requirement with its own acceptance criteria, not as an afterthought just before go-live. Cleaning, mapping and testing with real data belong in the plan from the start.

Mistake 5. Underestimating change management and the real cost

Attention goes to the licence price in the quote. On average that shows only one fifth of what the project really costs over five years. Training, internal time and the productivity dip in the first months after go-live appear in no budget. The result: people fall back on the old way of working or on Excel, adoption stalls and the business case evaporates.

How to prevent it. Calculate a realistic total cost over five years upfront, including training, internal time and operations. Also plan support during and after the implementation, so adoption is not left to chance. Read more in our article on the real cost of an ERP over five years.

From practice

One of our clients runs on an established ERP package. Over the years five separate platforms were added alongside it. Not all at once. Each time something turned out to be missing: a function that was not there, a process that fitted nowhere. And another tool came in. Every one of those calls was defensible, made by people who simply wanted to get on with their work.

The result is five integrations, five contracts and five vendors looking at each other the moment something breaks. Nobody intended it. It crept in.

We do not see that as a fault of the package. What was missing was the exercise at the start: writing down what had to be covered operationally before anyone signed. That takes a few days and decides whether you buy one system or six.

Out of respect for the client and the vendor we name no names.

The common thread

Four of these five mistakes are made before the first line of code, not after. So you can also make them visible before you sign. That is the whole idea behind a thorough analysis upfront: first know what you need and only then sign. That keeps the focus on one question: does your investment deliver what it should?

Frequently asked questions

What is the biggest mistake in an ERP integration? Choosing software before you know your processes. Selecting on the demo rather than on process fit is something you pay for later in customisation and extra work. Map your processes and exceptions first, then choose.

Why do integrations with other systems go wrong so often? Because they come into view too late. Every integration with a web shop, CRM, WMS or accounting package is a separate small project. An integration map before selection makes every data flow and every owner explicit, so nothing is left "for later".

How do you stop an ERP project from going over budget after go-live? Make the hidden costs visible upfront. The quote shows on average one fifth of the real cost over five years. Budget integrations, data migration, training and internal time separately and keep a buffer. That way the business case does not run dry after delivery.