Your ERP go-live date gets pushed back for the third time.

First, it was a vendor delay. Then a resourcing issue. Now, it’s “unresolved data issues.” Every delay has an explanation, but nobody on the steering committee believes this will be the last one.

By then, the project team may be chasing symptoms instead of dealing with the issues underneath.

In Pemeco’s ERP assessment and recovery work, the root causes often trace back to four areas: design, data, testing, and training. These problems are common, and they are not random. They tend to follow predictable patterns, which means they can be addressed before they become go-live problems.

Here is where ERP projects most often break down, and what good looks like when each area is handled well.

1. Design: Anchor Decisions to Business Value

The design work in an ERP implementation is where the organization turns strategy into an operating model the new system can support. The goal is not simply to document future-state processes. It is to make sure the design can deliver strategic business value in the short term and remain scalable as the business changes.

When this work is done well, configuration, testing, training, and change management have a clear foundation. The team understands which process changes matter, which decisions support the business case, and where standardization, automation, controls, or better data will create value.

When it is not, design decisions tend to become ad hoc and unanchored from the outcomes the project was meant to deliver. Teams default to whatever is familiar, convenient, or loudest in the room. Department-specific preferences become system requirements. Customizations are approved before anyone has tested whether they support the broader operating model.

Those decisions can upend the value case. A customization meant to preserve one department’s current process creates friction for another. A local workaround weakens reporting or control requirements. A decision made in isolation surfaces during piloting, when it is already built into configuration. What could have been a design discussion becomes rework.

A good design phase starts with concrete deliverables and real cross-functional validation. Blueprint white papers should reflect the business value the implementation is expected to create, not simply document current habits. Walkthrough presentations should give departments a chance to show how they plan to operate and expose each other’s blind spots before configuration is locked in. Most importantly, the future state should trace back to the outcomes the project was meant to deliver, whether that means faster cycle times, better margins, stronger controls, improved visibility, or the ability to scale.

2. Data Migration: Treat Data as a Business Readiness Issue

In 2009, WestJet cut over to a new reservations system that was supposed to improve customer service. One of the major challenges was moving roughly 840,000 files tied to customer transactions from the old reservation system to the new one. The migration did not go smoothly. WestJet’s website crashed repeatedly, call centers were overwhelmed, and customers faced booking delays.

WestJet’s situation was specific, but the pattern is familiar. Data that appears usable in the old system often breaks when it is moved into a new operating model. Customer records, vendor records, item masters, pricing rules, tax fields, part numbers, and transaction histories may live across multiple systems and spreadsheets. Missing fields, duplicate records, inconsistent naming conventions, and weak cross-references can trigger errors at scale.

Large data migrations also have sequencing risk. Data often needs to move in a specific order. A quality issue early in that sequence can create problems downstream that are difficult to untangle during cutover.

Data migration also requires different strategies for different types of data. Static data, such as customers, vendors, items, parts, accounts, and open balances, may need cleansing, deduplication, mapping, validation, and controlled loading through programmatic tools. Dynamic data, such as open orders, transactions, inventory movements, purchase commitments, and production activity, often requires more careful timing, manual judgment, reconciliation, and cutover controls. Treating all data the same is one way migration plans become technically busy but operationally fragile.

But technical complexity is only half the problem. In many troubled ERP projects, data migration is treated as an IT task when it is really a business readiness workstream. Business leaders need to decide what data matters, what gets cleaned, what gets archived, what gets converted, and what standards the organization will follow after go-live.

Getting data migration right means assigning clear ownership long before extraction and loading begin. Data quality, conversion rules, governance decisions, and validation all need business accountability. Cutover rehearsals should be used to expose the issues that spreadsheets and mapping documents will not catch.

For a practical walkthrough, see Pemeco’s 8-step guide to ERP data migration.

3. Testing: Prove the Business Can Operate End to End

In 1999, Hershey’s undertook a major systems overhaul with SAP for ERP, Manugistics for supply chain, and Siebel for customer relationship management. Hershey’s took the systems live close to the company’s busiest sales periods, including Halloween and the holiday season. When the rollout faltered, Hershey had inventory available but could not process and fulfill orders properly. The company missed more than $100 million in orders.

The lesson is not just that Hershey chose a bad go-live window. The deeper issue is that testing did not appear to prove whether the business could operate end to end under real conditions.

ERP testing is hard because ERP systems do not affect one department at a time. A sales order touches pricing, credit, inventory, production, warehousing, shipping, invoicing, and financial reporting. A purchasing change can affect receiving, quality, costing, production planning, and supplier management. Testing each function on its own is necessary, but it is not enough.

Good testing is designed to find where things break, not to confirm that the software turns on. It should move in stages: validating individual functions first, testing integrated workflows next, and then simulating full operations across systems, roles, and realistic volumes.

It also requires governance. Someone must own operational readiness and have the authority to say the business is not ready for go-live. That means building enough time into the schedule for testing, protecting that time when the project is under pressure, and choosing a go-live window based on business risk rather than convenience or an external deadline.

4. Training: Prepare People to Work Differently

A few months after implementing a new ERP system, a plastics manufacturer was struggling with inaccurate reporting and forecasting. When Pemeco investigated, we found that sales and purchasing teams were not consistently using the system to generate quotes and purchase orders. The result was incomplete and unreliable data.

The issue was not that users refused to adopt the system. They had not been trained in a way that matched their actual work.

Training is often treated as a post-implementation activity: create materials, schedule sessions, show users where to click, and assume adoption will follow. But when training does not reflect how people actually work, go-live does not mean the business is ready. Teams fall back on workarounds, data becomes inconsistent, and leaders lose confidence in what the system is telling them.

Effective training is role-specific and workflow-driven. It should show people how to complete real tasks in the context of their jobs, not just how to navigate screens. It can also be collaborative. End users can help validate process maps, shape role-specific instructions, and identify where the new workflow does not match day-to-day reality.

Ownership matters here too. Someone must own user readiness, not just training completion. Attendance does not prove readiness. Neither does a slide deck. The better question is whether people can perform the work correctly in the system before the business depends on them doing it after go-live.

For more practical guidance, see Pemeco’s guide to ERP training milestones.

The Common Thread: Governance Turns Workstreams Into Outcomes

ERP failures rarely come down to effort or commitment. Most troubled projects have plenty of both.

The issue is that hard work without the right governance structure does not reliably translate into a successful cutover. Design decisions need cross-functional accountability. Data needs business ownership. Testing needs the authority to challenge the timeline. Training needs to prove readiness, not just attendance.

The ERP projects that succeed are not simply the ones with the best software or the biggest budgets. They are the ones where someone owns outcomes, not just tasks, and where that accountability stays active throughout the implementation.

When those gaps are hard to see from inside the project, an independent assessment can help surface the risks early, clarify what is really going wrong, and give the leadership team a practical path back to control.