Why most ERP migrations fail (and the third option most businesses don't consider)

We don't migrate businesses to SAP or NetSuite. We're not an implementation partner for the big ERP vendors. What we do is build custom operational systems for businesses where a packaged ERP isn't the right fit, and we've watched plenty of ERP migrations from the outside go in directions the client didn't expect.

Industry research backs up the failure pattern. Gartner has reported that 55 to 75% of ERP projects miss their objectives. Panorama Consulting's annual report routinely shows more than half of implementations running over budget and around two-thirds running over schedule.

Most articles on this topic are written by ERP vendors who frame the failures as something other companies do, then sell their own product as the answer. We're writing from a different angle. ERP migrations fail for a small number of recurring reasons, most of them rooted in decisions made before the migration starts. And for some businesses, the right answer isn't a different ERP. It's a custom system built around the workflows the business actually has.

What "failure" actually means

It's rarely a cancelled project. It's usually one that ships and disappoints.

ERP migration failure rarely looks like a cancelled project. Most failures ship. The system goes live, the team starts using it, and over the following 6 to 18 months it becomes clear the migration didn't deliver what was promised.

The common patterns: the new system runs over budget by 30 to 80%. The launch is 6 to 18 months later than planned. Key business processes work less well after migration than before. Reports are slower to produce or harder to trust. Users build workarounds that recreate the workflows the old system supported. The promised efficiency gains don't materialise. Six months in, leadership starts asking whether the migration was worth it.

Failure also includes outright disasters that end up in case studies and lawsuits, but those are rare. The quiet failures are where most of the cost lives, and they're harder to recognise because they don't have a clear breaking point.

The five reasons ERP migrations go wrong

Most failures trace back to decisions made before the technical work begins.

1. Treating it as a technical project

ERP migration is a business transformation project that happens to involve software. Most companies scope it as a software implementation and end up surprised when the hard parts are organisational. The team handling the migration is usually IT, but the decisions that determine success live with operations, finance, sales, and customer service.

When IT runs the project alone, the business process work gets deferred or skipped. Users get a system that does what the old one did, slightly differently, with no real improvement to show for the spend.

2. Underestimating the data

ERP migrations involve moving years of structured business data into a new schema. Customer records, product catalogues, transaction history, financial entries, supplier information. The data is rarely as clean as people assume. Duplicates, inconsistent formatting, missing fields, abandoned categories. Cleaning it is usually 20 to 40% of the project effort, and teams routinely allocate 5%.

When data migration is rushed, the new system goes live with bad data, and the cost surfaces in every report and every customer interaction for months afterwards.

3. Customising too much

Modern ERPs are designed around standard business processes. The right way to use them is usually to adapt your processes to the system's defaults, with limited customisation only where the business has a genuine competitive reason to be different. Most companies do the opposite. They try to make the new ERP behave exactly like the old one, customising every screen and workflow until the result is a custom build with an ERP base.

This approach inflates the project cost, makes upgrades harder, traps the company in a heavily-customised system, and drives up maintenance costs for years afterwards. Most ERP failures we see from the outside have customisation as a primary or secondary cause. If a business is heading toward heavy customisation, a custom build often becomes the more honest comparison.

4. Ignoring the user training problem

ERP migrations change how people do their daily work. Order processing, invoice handling, customer lookups, reporting. Users need real training and real time to learn the system. Most projects budget two to four weeks of training. The honest number is closer to three to six months of partial productivity loss while users get up to speed.

Companies that don't plan for this end up with users building workarounds in Excel that undermine the migration within weeks of launch.

5. Picking the wrong moment

ERP migration is a 12 to 24 month commitment that touches every part of the business. Doing it during a period of major strategic change (acquisition, geographic expansion, leadership transition, market shift) is asking for trouble. The migration runs into business changes that change requirements mid-flight, and the project loses coherence.

The right time to migrate is when the business is operationally stable but the existing ERP is limiting growth. Doing it earlier is premature. Doing it during a turbulent period means taking on two hard projects at once.

Warning signs in the first three months

Patterns that show up early and predict trouble later.

Migrations that go wrong usually show signals in the first quarter. The earliest indicators:

• The project sponsor has delegated meaningful decisions to IT. If the head of operations or the CFO can't tell you what the new ERP will change about the business, the project is going to drift.

• The data audit hasn't started. If you're three months in and nobody has assessed the quality of the data being migrated, the data work will collapse the timeline later.

• Customisation requests are being approved without serious challenge. Every customisation should require a written business case. If requests are getting added to the backlog without scrutiny, the project is heading toward over-customisation and over-budget.

• The implementation partner is talking about "go-live" more than "adoption." Going live is the easy part. Getting the business to run on the new system is where the hard work lives.

• Training is being scheduled for the last two weeks before launch. By that point users should already have spent weeks in a sandbox environment getting familiar with the system. Two weeks of training before go-live is too late.

Why "lift and shift" usually doesn't work

Moving the old system's logic into a new platform is the most expensive way to migrate.

The intuitive approach to ERP migration is to keep doing what you do today, just on a new platform. This is called lift and shift, and it's the wrong default for ERP work.

ERPs encode business processes. The current ERP encodes processes that may have made sense five or ten years ago, when the business was different and the previous ERP was newer. Migrating those processes verbatim into a new system means you've paid to recreate decisions you'd make differently today, and you've trapped the new system into supporting them.

A better approach: every business process gets reviewed during migration. Some get migrated as-is because they're working well. Some get redesigned to match the new ERP's defaults because the new defaults are better. Some get retired because they were workarounds for problems the new system doesn't have. Some get combined with others because the migration is a chance to simplify workflows that had drifted apart. This work is harder than lift and shift, but the savings show up over the next decade of using the new system.

The three options most businesses don't compare properly

ERP vendors present two options. There's a third that often gets skipped.

When a business decides its current systems aren't working, the discussion usually narrows quickly to two options: migrate to a new packaged ERP, or stay with the current one. Sometimes a third option gets mentioned in passing: keep the current ERP and integrate around it. A fourth option rarely makes it into the conversation, and for some businesses, it's the right call.

Option 1: Migrate to a new packaged ERP.

SAP, Oracle, Microsoft Dynamics, NetSuite, Odoo. Best for businesses whose processes match the platform's defaults reasonably well, who have the budget for a 12 to 24 month implementation, who can absorb the change management cost, and who have the internal capacity to drive the project through. The right call for many mid-market businesses.

Option 2: Keep the current ERP and integrate around it

Build a modern reporting layer, a customer-facing portal, or workflow tools that connect to the existing system. Cheaper than migration, lower risk, but only works if the underlying ERP is still functional enough to keep using. Best for businesses whose core financials work fine but who need modern interfaces around them.

Option 3: Stay where you are and accept the limits

Sometimes the current system is fine and the pain points don't justify a project. The cheapest option. Easy to dismiss, but legitimately the right answer when the business case for change is weak.

Option 4: Build a custom system instead of buying one

Best for businesses whose processes don't match any packaged ERP well, who have specific workflows that need bespoke handling, or who've watched too many peers get burned by heavy customisation of standard platforms. This is what we do, and it's underdiscussed because the ERP vendors who write most of the content on this topic don't sell it.

The choice between these four depends on how unusual your business processes are, how much custom logic you'd end up adding to a packaged ERP, what your total budget actually is, and what your tolerance is for a long implementation. The honest comparison includes all four, not just two.

When custom software is the right answer

Specific situations where a custom build beats a packaged ERP for mid-market operations.

Custom software gets pitched in two ways. The first way is dishonest: "we'll build you whatever you want, no constraints, just like the old days." This is how custom builds get expensive and unmaintainable.

The second way is the one that works: a custom system designed around the specific workflows the business actually has, built on modern web technology, with the scope tightly defined and the build phased to manage risk. This is the work we do.

A custom build tends to make sense when:

Your processes don't fit any packaged ERP well

B2B wholesale with unusual dealer relationships, complex credit terms, region-specific pricing, multi-brand catalogues with different rules per brand. We've built systems handling exactly this kind of complexity. Packaged ERPs can do it, but only with heavy customisation that breaks the upgrade path.

You need a B2B trade portal as the core of the business

Dealer login, trade account application, credit management per dealer, ordering with their specific pricing, returns, brochure and asset downloads, third-party integrations for product lookup. We built this exact system for a UK wholesaler in the motorcycle equipment industry, including a third-party integration that lets dealers look up a vehicle registration plate and see the parts they can order for that bike. A packaged ERP with a portal bolt-on would have cost more and worked less well.

You want full operational control without paying for what you don't use

Stock management, supplier and dealer management, order entry, invoice generation in PDF and CSV, tax reporting, customer enable/disable, warehouse stock arrival tracking, full reporting. We built a full custom ERP covering this for a UK wholesaler of garden furniture and ornaments. The system replaces what would otherwise have been a five-figure-per-year licensing bill on a packaged platform, plus customisation costs.

You're a mid-market business below the scale where SAP or Oracle makes sense

For businesses under 200 employees, the licensing and implementation cost of enterprise ERPs is rarely justified. A custom system in the €50k to €500k+ range, scoped to what the business actually needs, often delivers the operational coverage required without the licensing overhead.

Custom isn't always the right call. If your processes are standard, a packaged ERP is cheaper and faster to ship. If your team has the bandwidth to adapt to a vendor's defaults, the savings are real. If you're growing past 500 employees and your operations are getting complex, a packaged ERP starts to make sense again. The honest version of "custom vs packaged" includes the cases where custom is wrong as well as the cases where it's right.

Action plan: stress-testing your systems decision before you commit

An eight-step audit you can run before signing any contract, packaged or custom.

If you're considering an ERP migration or a custom build, run this audit before signing anything. It typically takes 3 to 4 weeks and saves 6 to 12 months of avoidable problems.

1. Define what success looks like

Three to six measurable business outcomes. "Month-end close in 5 days instead of 12." "B2B order processing time cut by 40%." If you can't articulate success in business terms, the project will be measured on whether the software went live, which is the wrong bar.

2. Audit your current data

Sample 100 records each from customers, products, transactions, and suppliers. Check for inconsistent formatting, duplicates, missing fields, and abandoned categories. The percentage of records needing cleanup determines a major part of the project cost. If you don't know that percentage now, find out before signing.

3. List every customisation in your current system

Document every screen change, workflow modification, custom report, and integration the current system has. For each one, ask: is this still needed? Is it a competitive advantage or just legacy habit? If the list is long, that's a signal a packaged ERP may not fit your business as well as a custom system.

4. Map your integration surface

Every system the new platform will need to talk to: CRM, webshop, payroll, banking, reporting tools, third-party lookups. Document what data flows where. Integration work is often underestimated, and projects routinely run aground on it.

5. Pressure-test your project sponsor

The project sponsor (usually CFO or COO) needs to commit at a deeper level than approving budget. They need to make business process decisions, defend scope discipline against department pressure, own adoption metrics, and drive change management through to launch. If your sponsor can't commit at that level, find another sponsor or delay the project.

6. Compare all four options honestly

Packaged migration, keep-and-integrate, stay-and-accept-limits, custom build. Get rough cost ranges and timelines for each. Many businesses skip this step because a vendor or consultant has already narrowed the conversation to one option. The cheapest option you didn't seriously consider is often the right one.

7. Plan the change management

Training, documentation, support during transition, internal communications. Allocate 15 to 25% of project budget to change management. Most companies allocate 2 to 5% and pay for the gap in lost productivity later.

8. Build a no-go criteria list

What would need to be true for you to pause the project? Specific data quality issues, sponsor changes, business strategy shifts, and clear cost overruns past a stated threshold. Write these down before starting. Projects without explicit pause criteria tend to push through warning signs that should have stopped them.

By the end of four weeks you have a realistic picture of what each path will cost, what could go wrong, whether your organisation is ready, and which questions still need answering. About a third of businesses that run this audit decide to delay or cancel the project they were planning. The other two-thirds go in with a much higher chance of success.

Frequently asked questions