The nine pages Google ranks for ERP implementation best practices hold roughly 80 practices between them, and not one names a project that died for lack of a single one. That’s not an accident. Eight of the nine are written by companies that sell ERP software or implementation services (the ninth is a university selling a degree), and a named failure is awkward when the failed project could have been yours to sell.
So this list works differently. Every practice below comes paired with the public project that skipped it, what that cost, and a test you can run on your own program this week. If a practice can’t point to a body, it didn’t make the cut.
Why Most ERP Implementation Best Practices Lists Fail the Test
Start with the number every list quotes. One ranking guide says “55-70% of ERP implementations fail to meet their objectives,” and the link behind the claim goes to a general Gartner topic page on ERP (enterprise resource planning), not to a study. The real figure exists. Gartner’s published prediction is that by 2027, more than 70% of recently implemented ERP initiatives will fail to fully meet their original business goals, per its analyst Denis Torii on Gartner’s own insights page. Panorama Consulting’s 2015 ERP report put budget overruns at 58% of projects and schedule overruns at 65%.
Those numbers have not moved much while the advice has stayed the same. “The risk of failure hasn’t really decreased over time; in fact, it’s probably increased,” Third Stage Consulting’s Eric Kimberling told TechTarget. In the same piece, analyst Bill McNee said implementation cycles now run about one-third of what they used to. Faster projects, same failure rate. The list isn’t the problem. Nobody checks whether it’s being followed.
If you’re scoping an S/4HANA program (SAP’s current ERP suite, which replaces the older ECC system), our S/4HANA migration guide covers the path decision. This post covers execution. For the full catalog of how projects die, see why ERP implementations fail; here we work backward from those deaths to the habits that would have stopped them.
The practices that protect you most are written go-live criteria, the right to delay, and independent quality checks. They are also the three that cost your integrator money, which is why they’re missing from most vendor lists.
The Practice-to-Failure Matrix
Here’s the whole argument on one screen. Each row is a practice, the named project that skipped it, and the check that tells you whether you’re doing it or just saying you are.
| Practice | Named failure | What happened | The test on your project |
|---|---|---|---|
| Own the business case | Waste Management (2005-2010) | Bought on a promised $220M annual benefit; sued for $100M, amended to $500M, settled | Every benefit has a baseline number your team measured, not the vendor |
| Staff with people you can’t spare | The SAP.com arithmetic | A 12-month plan needing 42,000 hours against 28,080 available is late on day one | Hours required divided by hours available fits the plan |
| Build the calendar from hours | Hershey (1999) | Compressed a recommended 48 months into 30; about $100M in orders went unshipped | Nobody can name the date before the work estimate exists |
| Hire the named people | MillerCoors (2014-2017) | $100M suit over whether blueprinting was ever finished; countersuit; settled | Named consultants and phase-exit criteria are in the contract |
| Fit to standard | Lidl (2011-2018) | Bent SAP to its own inventory valuation; roughly €500M written off | Every customization has a business owner and a reason in writing |
| Run data as its own workstream | Target Canada (2013) | About 70% of manually entered supply-chain data was wrong | Three mock migrations, reconciled totals, a named data lead |
| Test the business, not the screens | Spar Group | Lost margin visibility after go-live; tests never checked it | Each critical report is tested with real data before cutover |
| Keep test and production apart | PG&E (2016) | Production data sat in a demo database; 47,000+ asset records exposed | A dedicated test environment with masked data |
| Design for the daily user | Avon (2013) | Aborted after 4 years and $125M; sales reps couldn’t use it | Real users complete real tasks in the pilot, unaided |
| Make go-live a vote with criteria | MillerCoors | Went live with 8 critical and 47 high-severity defects open | Written go/no-go criteria signed before the dress rehearsal |
| Never go live into your peak | Hershey; J&J Snack Foods (2022) | Halloween season go-live; a busy-period cutover cost about $20M in sales | The cutover date sits in your slowest window |
| Pay for independent assurance | National Grid (2012) | Month-end close went from 4 days to 43; about $585M to recover | A QA party reports to your board, not to the integrator |
Now the practices themselves, in the order you’ll hit them.
Before You Sign: Goals, People, and an Honest Calendar
1. Own the Business Case, Don’t Rent It
Every ranking guide says to define goals and KPIs (key performance indicators) before you pick software. True, and incomplete. The trap is letting the seller write the goals. Waste Management’s lawsuit pleaded that SAP had promised the system would deliver $220 million in annual benefits. The suit asked for $100 million, was amended to $500 million, and settled.
Write the benefits yourself, as numbers you could fail. “Cut the financial close in half” works, because you can measure today’s close. So do inventory turns, forecast accuracy, or order backlog for a manufacturer, and sell-through or sales per square foot for a retailer. Then put scope in a written document with in-scope processes, exclusions, and sign-offs. Every change request gets judged against that baseline, which is the cheapest insurance against scope creep you’ll ever buy.
2. Staff the Project With the People You Can’t Spare
SAP’s own guidance is blunt on this one. Companies that struggled, it says, assigned staff who “had the time.” The project needs the busy people who know the processes and have executive trust, ideally full time, and SAP’s floor is that nobody giving less than 25% of their week (10 hours) belongs on the key team.
I’d raise that floor. Twenty-five percent is the number that lets a company staff a program thinly and call it compliant. Practitioner guidance in our corpus says the project managers, analysts, and functional leads need to be full time, full stop. Backfill their day jobs with contractors. It’s cheaper than the alternative.
And don’t build it around one hero. “The person who’s leading the project can’t save the world on their own,” Lionel’s CIO Rick Gemereth told TechTarget. Plan for an executive sponsor with real authority to move budget and people, a full-time project manager, functional leads, a data migration lead, a change lead, and super users from the teams who’ll live in the system.
3. Build the Calendar From Hours, Then Find the Date
SAP’s best-practices page runs a calculation that every steering committee should see. Target go-live is 12 months away. The team has 540 hours a week, so 28,080 hours a year. The work needs 42,000 hours.
- 42,000 divided by 28,080 is 1.496 years.
- The go-live date is missed before the project starts.
- The only honest fixes: cut scope, move the date, add people, or split the program into phases.
Hershey ran that equation the other way in 1999. It took a plan recommended at 48 months and squeezed it into 30, then cut over ahead of its Halloween rush. About $100 million in orders didn’t ship. For an S/4HANA program, our SAP project timeline breakdown shows what each clock actually includes. Rough sizes from published guides (ERP Research’s, for one): 3 to 6 months for a small cloud rollout, 6 to 18 for mid-market, 18 or more for multi-country programs. Then put the costs that slip past the first budget in as line items. Workday’s implementation guide names them: extended customization work, extra integration projects, data cleansing, and the productivity dip while people learn the system. Then add contingency on top. Published rules of thumb range from 15 to 20% of budget up to 20 to 25%. Pick the top of the range if your data is old.
4. Hire the Named People, Not the Logo
Every list says to choose a partner with industry and product experience and to check references. Fine. The sharper version: interview the consultants who will actually staff your project, and write their names into the contract. The pitch team is not the delivery team. You should know who replaces whom, and how fast, if someone rolls off.
Also put phase-exit criteria in writing. MillerCoors sued HCL for $100 million in 2017 in the Northern District of Illinois, and the core dispute was whether the blueprint phase had ever really been completed before the build started. HCL countersued. It settled. Both sides had a contract; neither had an agreed definition of “done.”
Decide the delivery model on purpose, too. Some partners run a traditional, consultant-supported method; others run a turnkey, vendor-led one where the vendor’s consultants own configuration, pilots, and cutover. Either works. Not knowing which one you bought doesn’t.
Finding the partner who will sign up to those terms is the hard part, and it’s a matching problem more than a research problem. You can describe your project and see which partners rank for it, free, no signup, before anyone sends you a deck.
During the Build: Standard Processes, Clean Data, Real Tests
5. Fit to Standard, and Customize by Exception
Lidl spent seven years and about €500 million on an SAP program before pulling the plug in 2018. The widely reported sticking point: Lidl valued inventory at purchase prices, SAP’s standard retail model works from retail prices, and Lidl chose to bend the software rather than the process. A year earlier, SAP had named Lidl a top customer.
SAP’s own methodology, SAP Activate, has moved toward this lesson. Older on-premise projects ran “fit-gap” workshops that catalogued everything the software didn’t do. Current projects run fit-to-standard workshops: key users walk the standard processes in a sandbox with SAP’s test scripts first, then each workshop is co-owned by an SAP consultant and a business process owner, typically five or six line-of-business teams in parallel. What doesn’t fit goes to a backlog as a delta requirement, and the phase closes with a quality assessment. For RISE with SAP Private Edition (SAP’s subscription bundle), the methodology adds “clean core” quality gates at the end of each phase. Clean core means a system kept close to standard, including its extensions and integrations, so upgrades don’t turn into reimplementations.
There’s a catch in SAP’s own advice. Its best-practices page also says to “match the business direction and do not force unnecessary process changes,” and Deloitte’s guide repeats the point. Both instructions are right, which is why the call needs a rule rather than a slogan: change the process when the standard is merely different from your habit, and customize only where the difference is something customers pay you for.
Not every heavy customizer fails. Lionel told TechTarget it “twisted NetSuite in numerous ways” and made it work because it documented every change. That’s the real rule: customization needs an owner, a reason, and paperwork. Whether you start from a clean build or convert your old system changes how much of this you inherit, which is the core of the greenfield vs brownfield decision.
6. Run Data as Its Own Workstream
Target Canada’s 2013 launch is the cleanest data lesson on record: roughly 70% of the supply-chain data entered by hand was wrong. The shelves showed it.
Every ranking page says to cleanse data early. What they skip is how long “early” lasts. The SAP PRESS migration handbook Migrating to SAP S/4HANA notes that data cleansing “is usually a permanent process that lasts until the final data migration.” Treat it that way:
- Name a data migration lead, with authority, on day one.
- Run at least three mock migrations into a sandbox, and reconcile the totals on both sides every time.
- Hand-check the high-risk objects: customer records, open financial items, inventory.
- Agree on data definitions across systems before mapping starts. “Dirty data can cost you millions,” as McNee put it.
7. Test the Business, Not the Screens
Spar Group, the South African distributor, went live on SAP and lost visibility into its product margins, in a business that runs on thin ones. Testing never checked whether the margin reports worked. That’s a test-script problem, not a software problem.
Unit and integration testing prove the system runs. User acceptance testing (UAT) with real scenarios and real data proves the business runs on it. Add a conference room pilot (a multi-week test drive of all processes before rollout) and, where you can afford it, a parallel run. “I don’t think it’s wise to unplug old systems and plug in new systems and say, ‘OK, we’re going,'” Gemereth said.
Keep the environments honest, too. At PG&E in 2016, production data ended up in a demo database and more than 47,000 asset records were exposed. A dedicated test environment with masked data is a line item. Put it in the budget.
Two test types fall off most plans: performance testing at the transaction volumes you expect on your busiest days, and security testing of roles and access controls. IntelliChief’s and Itransition’s guides both list them. A system that passes UAT with ten testers and stalls with five hundred users has not been tested.
8. Design and Train for the Person Who Uses It Daily
Avon spent four years and about $125 million on an SAP project and walked away in 2013. The trouble landed on the sales representatives in the field, who found the system hard to use and in some cases were locked out of it. In a direct-sales company, that’s the business.
“An ERP rollout is not an IT project. It’s a company project,” as Gemereth put it. Make that concrete: role-based training, super users in every team, and timing that matches memory. One practitioner in our corpus describes a retailer that trained everyone two months before go-live; by launch day they’d forgotten it, and the team doubled floor support. Train within two to three weeks of use. SAP’s page splits training into four audiences: the project team, IT, business users, and new hires who join after go-live. The last group is easy to forget and is what keeps the system usable in year three.
Before training starts, run a change readiness check. Itransition’s guide suggests looking at how the company handled its last big change and how much change fatigue it’s still carrying from earlier initiatives. If people can’t do their jobs in the new system, they’ll quietly go back to spreadsheets, and the investment goes with them.
At Cutover: Go-Live Gates Your Integrator Won’t Volunteer
9. Make Go-Live a Vote With Written Criteria
MillerCoors went live with 8 critical and 47 high-severity defects still open. National Grid’s team priced a delay at about $50 million and went live instead; the recovery took around $585 million. The cost of a delay is almost always smaller than the cost of a broken go-live. It just shows up sooner.
SAP’s methodology agrees, quietly. Its guidance on the cutover dress rehearsal, in Denecken, Musil and Santhanam’s SAP Activate (3rd ed., SAP PRESS, 2025), says: “There may be a need to postpone the go-live date if significant changes and critical items are raised as a result of this rehearsal.” So write the criteria down before the rehearsal, and agree who votes. Here’s the gate card.
| Gate | Threshold | Where it comes from |
|---|---|---|
| Core team time | Leads full time; nobody under 25% of the week (10 hours) | SAP.com floor; practitioner full-time rule |
| Calendar math | Hours required ÷ hours available fits the plan | SAP.com worked example |
| Contingency | 15-25% of budget, held by the sponsor | Published rules of thumb |
| Mock migrations | At least three, totals reconciled | Practitioner guidance |
| Test completion | 90% or more of planned test cases passed | Practitioner guidance |
| Critical defects | None open on core processes | No “go” until critical processes pass end to end |
| Integrations | Every external interface validated before testing closes | Practitioner guidance; SAP Activate integration validation |
| Dress rehearsal | Full cutover rehearsed in a production-like system | SAP Activate |
| Operations readiness | Support model checked a couple of weeks before go-live | SAP Activate |
| Training timing | Within 2-3 weeks of first use | Practitioner guidance |
| Hypercare | Staffed for at least 2-4 weeks; 4-8 is common | Practitioner guidance |
Bottom line: if your go/no-go criteria aren’t signed before the dress rehearsal, the date will win every argument. Dates always do.
10. Never Go Live Into Your Peak
Hershey went live in the run-up to Halloween, its biggest season. J&J Snack Foods cut over mid-quarter in a busy period in 2022 and reported about $20 million in lost sales. The full Hershey autopsy covers the rest. Pick your slowest window, and avoid month-end and quarter-end.
The rollout shape matters as much as the date. SAP describes four: big bang (everything at once), phased (by department, site, or user group), pilot (a small group first), and hybrid (some mix). Big bang is faster and concentrates the risk on one weekend. Phased takes longer and lets each wave teach the next. If you can’t name what you’d do if the first site goes badly, you’re not ready for big bang.
11. Pay for Independent Assurance
National Grid’s month-end close went from 4 days to 43 after its 2012 go-live, with roughly 15,000 supplier invoices unpaid. The utility later settled with Wipro for $75 million. The post-mortem advice from Third Stage Consulting is the line most vendor lists can’t print: “You are in charge of your project, not your system integrator.”
An independent quality assurance (QA) party that reports to your steering committee, not to the integrator, is the board’s insurance policy. It costs money. So does a 43-day close.
After Go-Live: Hypercare, Then the Marriage
12. Plan for the Years After the Go-Live Party
Hypercare (the intensive support period right after go-live) usually runs four to eight weeks. The two classic mistakes are ending it early to save money and moving your best people onto the next project the week after launch. Don’t do either.
The longer view comes from Michael Doane, writing in 2012 in The SAP Green Book: “Many of the post Go-Live disappointments can be squarely laid at the doorstep of the implementation project in the vein of ‘bad wedding, worse marriage.'” New clients, he wrote, concentrate on the wedding and give “short shrift to the long-term deployment (the marriage).” The clients he found doing well had set up a center of excellence, a permanent internal team that owns the system, at the outset.
The marriage is where the bills land. Revlon disclosed a material weakness in its controls after its 2018 go-live, lost about $64 million in sales, and watched its stock fall 6.9% within a day of the announcement. At Invacare, the board ousted the CEO in August 2022 and cited the stalled transformation. Watch for the early signals: missed milestones, users back on spreadsheets, reports that don’t match, manual workarounds. Measure the KPIs from practice 1 before and after, with the baseline taken before the project starts, as IntelliChief’s guide advises, or you’ll have nothing to compare against. Review the system against business priorities quarterly or twice a year (the cadence Workday’s guide suggests), and adopt releases on purpose.
Sometimes the best practice is patience. Kimberling’s advice to TechTarget: if processes are broken or people aren’t trained, fix that first. Waiting is cheaper than a bad wedding.
Frequently Asked Questions
What are the 7 steps for successful ERP implementation?
The seven most often quoted come from SAP’s planning guidance, which Deloitte’s guide repeats: choose a software and services partner, detail every project task, calculate the work hours, build a realistic schedule from those hours, run a conference room pilot, cleanse the data, and keep everybody informed. Workday counts seven phases instead: planning, system selection, design and configuration, data migration, testing and training, go-live, and post-implementation optimization. Either list works only if each step ends in a test you can fail.
What are the 6 steps in ERP implementation?
For an SAP project, the six are the SAP Activate phases: Discover, Prepare, Explore, Realize, Deploy, and Run. Fit-to-standard workshops happen in Explore, the build and testing in Realize, and the dress rehearsal, cutover, and hypercare in Deploy. Other guides count seven or eight phases (Workday and Rand Group, for example), but the work inside them is the same.
What are the ERP implementation strategies?
SAP describes four. Big bang switches everything over at once. Phased rollout goes in stages by department, site, or user group. A pilot starts with a small group before full rollout. Hybrid mixes these, for example phasing core functions while piloting new features. Big bang is fastest and concentrates the risk; phased takes longer and spreads it.
Which two factors are most critical for successful ERP implementation?
The team and the top. Deloitte’s guide calls the implementation team “your biggest success factor” and names upper-management support as the other essential, and SAP says to staff the team with people you can’t do without, none under 25% of their week. Our addition: both only count if they hold the authority to delay go-live when the written criteria aren’t met.
How to measure ERP implementation success?
Take baselines before the project starts, then track the same numbers after go-live: user adoption, cycle times such as the financial close or order-to-cash, error rates, report accuracy, and return on investment against total cost of ownership. Going live on schedule is not a success metric. A system people work around with spreadsheets has failed, whatever the date said.
Sources
- Gartner, “What IT Leaders Must Do to Avoid Disappointing ERP Initiatives”: the 2027 prediction (Denis Torii).
- Panorama Consulting, 2015 ERP Report: budget and schedule overrun rates.
- SAP, “ERP implementation best practices”: the team-time floor, the work-hours calculation, the seven planning steps, the four training audiences, and the four rollout strategies.
- Denecken, Musil and Santhanam, SAP Activate, 3rd ed. (SAP PRESS, 2025): fit-to-standard workshops, clean core gates, and the dress rehearsal guidance.
- Michael Doane, The SAP Green Book (SAP PRESS, 2012): the wedding and the marriage.
- Densborn, Finkbohner, Höft, Rubarth, Klöß and Mathäß, Migrating to SAP S/4HANA (SAP PRESS, 2024): data cleansing as a permanent process.
- Deloitte Malta, “Implementing an ERP: some best practices” (2022): the team as the biggest success factor and the process-change caution.
- Workday, “The Ultimate Guide to ERP Implementation”: the seven phases, hidden cost drivers, and review cadence.
- IntelliChief, “ERP Implementation Best Practices”: performance and security testing, and baseline-first measurement.
- Itransition, “10 Best Practices for ERP Implementation”: the change readiness assessment.
- Tony Kontzer, “Top 8 ERP implementation best practices”, TechTarget: quotes from Eric Kimberling, Bill McNee, and Rick Gemereth.
- Third Stage Consulting, lessons from the National Grid v. Wipro lawsuit: the 4-to-43-day close and the governance advice.
- TechTarget, MillerCoors ERP lawsuit coverage: the HCL dispute, the countersuit, and the settlement.
None of these practices is new. What’s rare is a program that writes them down as tests and lets the tests overrule the calendar. If you want partners matched to how you plan to run the project, not just to the module list, see how the matching works.
