Why ERP–WMS integrations fail – the master's thesis

In the spring of 2025 I submitted my master’s thesis in logistics at Molde University College. The subject was system integration, and the question was a practical one: why does it so often go wrong when an ERP system and a warehouse management system have to talk to each other – and what do the ones who get it right do differently?

My supervisor was Terje Andersen. This episode is the walk-through of what the study actually showed.

The two systems

The terms first, because they get mixed up.

One system for the business, one for the warehouse

ERP

Enterprise Resource Planning

• Broad – finance, purchasing, sales, production, HR
• Sees stock at an aggregated level
• Used for planning and control
• Acts as the core other systems connect to

WMS

Warehouse Management System

• Narrow and detailed – the warehouse only
• Locations, picking, packing, put-away
• Real-time tracking, and links to automation
• Does what the ERP has only basic functions for

How the study was done

The study combined two sources. A digital questionnaire went out through LinkedIn and professional groups for people working with ERP and WMS, and produced 22 responses. I then conducted four semi-structured interviews with an ERP consultant, a WMS consultant, a solution architect and a project manager. The data was collected between March and May 2025.

The respondents were experienced: 45.5 per cent had six to ten years behind them, 18.2 per cent more than ten. Most came from logistics and warehousing, but also from distribution, manufacturing, food and beverage and retail – several from more than one industry.

The questionnaire gave the breadth. The interviews gave the depth, and explained what the numbers meant in practice.

The biggest number is not a technical one

This is the main finding, and it surprised me.

What the respondents reported as causes

It is worth pausing there. This is called an integration project, and the discussion is about APIs and data models. But what the respondents pointed to most often was that the business processes had not been defined well enough before anyone started connecting systems together.

Two systems cannot agree on a process that has not been decided.

How it showed up in the cases: several of the projects ran without a defined integration strategy. The consequence was not a missing document – it was that testing, training and change management were not prioritised, but handled along the way, as things caught fire. The projects ran from six months to a year, and many of the companies had limited internal IT capacity and depended on external consultants. Several had never done an integration like this before.

The technical side

That does not make the technology innocent. Three problems recurred, and they are connected.

Data synchronisation was the most frequently reported technical cause. Without real-time updates the stock figures go wrong, order processing slows, and somebody has to correct things by hand – which is exactly what the integration was meant to remove.

Incompatible APIs came up especially where the ERP and the WMS came from different vendors. A lack of standardisation, failures in the data exchange, and more complexity than the project had planned for.

Master data was described in the interviews as a foundational cause – not a fault in itself, but the reason other faults occur. If product and customer data is incomplete or inconsistent, the warehouse performs the wrong operations, or none at all.

Respondents also mentioned version mismatches between systems, handling of backorders, transactions going missing, and security weaknesses in the data exchange.

The delays

Here the answers were strikingly consistent.

How often do the projects run late?

Answer	Share
Occasionally – 10–30% of projects	42.9%
Frequently – 30–50% of projects	38.1%
Rarely – around 10% of projects	9.5%
Very frequently – over 60% of projects	9.5%

And one explanation came up unprompted from several informants:

Scope creep – the project growing as it goes – was described as common, and as a direct cause of slippage.

Why it is worse here than elsewhere: when the scope changes in an integration project, it is not just one deliverable that changes. What was tested has to be tested again, the data that was mapped has to be mapped again, and the training that was planned now applies to a different system than the users will get. It is the same mechanism that made unclear scope the second most cited success factor in the study – 59.1 per cent pointed to a clear project scope and requirements.

What actually helps

This is the part I find most useful myself, because it is concrete.

The measures respondents rated highest

1. Involve end users early – 77.3%The highest rated measure of all. The people who will use the system know how the work is actually done.
2. Thorough pre-implementation analysis – 72.7%A proper pre-study that settles the requirements before the project starts.
3. Extensive pilot testing before go-live – 68.2%The interviews made it concrete: unit testing, system testing and integration testing, each in its own right.
4. Continuous training and support – 68.2%Not one session before go-live, but something that carries on once the system is live.
5. Middleware or an integration platform – 40.9%A layer between the systems, rather than wiring them straight together.

Asked what is critical to success, an experienced implementation team came top at 63.6 per cent, clear scope at 59.1 per cent, and well-documented, standardised integration processes at 40.9 per cent.

A contradiction worth naming

The numbers are not entirely consistent, and that should be said out loud.

In the questionnaire, strong executive sponsorship was the lowest rated success factor – only 18.2 per cent pointed to it. In the interviews, a lack of engagement from management was raised as a real cause of weak delivery.

I have no basis for saying which of them is right. One possible explanation is that management support is easy to undervalue when ticking boxes in a form, and easy to see when recounting a project that went wrong. But that is an interpretation, not a finding.

What the study cannot say

This is in the thesis, and it belongs here too.

Four reservations

1. 22 responses is fewEnough to show tendencies in the field, not enough to generalise. A larger sample could have weighted things differently.
2. The ones with opinions answerAnyone with strong experiences, good or bad, is more willing to spend time on a questionnaire.
3. Four interviews give depth, not breadthOther industries or other countries might have pointed somewhere else.
4. All of it is self-reportedI observed no projects while they were running. These are practitioners' accounts of what happened.

What I take from it

That integration is an organisational problem dressed as a technical one. Middleware and standardised APIs solve real problems, but they do not solve two departments holding different views of how an order should be handled.

And that the order matters. Nearly every measure the respondents thought worked had to be set in motion before the project started – the pre-study, the requirements, the users, the test strategy. It is hard to recover a project that began without them.

The thesis is a study of what practitioners in the field report, not a measurement of projects. Companies, informants and anything that could identify participants are anonymised in the thesis. The content here is general information, not a recommendation for any particular project.

Main topics

• What ERP and WMS are, and why they have to talk to each other
• How the study was carried out
• The technical reasons integrations fail
• The biggest number is not a technical one
• Delays – almost every project
• What actually helps
• Scope creep
• A contradiction in the numbers
• What the study cannot say

Questions this episode answers

• What is the difference between an ERP system and a WMS?
• Why do integrations between ERP and WMS fail?
• What is the most common technical cause?
• What is the most commonly reported cause overall?
• How often do these projects run late?
• Which measures do practitioners themselves rate highest?
• What is scope creep?
• What is master data, and why does it derail projects?

Key points

• The most frequently reported cause of integration failure is not technical. Poorly defined business processes comes top at 76.2 per cent.
• On the technical side data synchronisation leads at 71.4 per cent, followed by incompatible APIs at 66.7 per cent.
• A lack of testing before go-live was reported by 66.7 per cent. The fault is then found in production.
• Nine out of ten respondents reported delays in at least one project in ten.
• The most recommended measure was involving end users early – 77.3 per cent.
• Training has to be a continuous process, not a box ticked before go-live.
• Several projects ran without a defined integration strategy. Testing, training and change management were then handled as they came up.
• Scope creep was described as common, and as a direct cause of delay.
• The study has 22 questionnaire responses and four interviews. It shows tendencies, not figures that can be generalised.

Sources and references

• Jan Sindre Heltne – «Which technical and process related factors contribute to failures in ERP-WMS integrations, and what strategies can be used to mitigate them?». Master's thesis LOG950, MSc in Logistics, Molde University College, 20 May 2025. Supervisor Terje Andersen.