ERP Change Management Best Practices

ERP change management is the structured discipline of preparing, equipping and supporting the people in your organization so they actually adopt a new ERP system. It covers the vision for change, stakeholder engagement, communications, training, readiness assessment and post-go-live reinforcement — everything outside the software itself that determines whether the investment pays back.

Updated July 2026.

Lack of adequate change management is the single most commonly cited reason ERP projects fail to deliver. The software goes live, but people work around it — and the business case evaporates. This guide sets out the ERP change management best practices that separate projects that stick from projects that quietly revert to spreadsheets.

We'll cover:

1. What is ERP change management?
2. Why change management determines ERP success
3. The five-phase ERP change management framework
4. Building your change management team
5. The best practices checklist
6. Frequently asked questions

What Is ERP Change Management?

Change management should be considered an integral component of any project which affects people, process or technology. The activities inside it vary by project type, but the goal never does: to move the organization successfully from its current state of working to its target state, and to make that new state stick.

The Four Change Workstreams

In an ERP context that means four things running continuously alongside the technical workstreams — preparing the business and its people for change, giving them the rationale for it, equipping them with the knowledge to operate in the new world, and monitoring and responding to feedback. At the heart of all four sits the common denominator of every project's success: people.

Change Management Determines ERP Implementation Success

Change management sounds simple, which is exactly why it is so often treated as a tick-box exercise. McKinsey's widely cited figure — that around 70% of change programs fail to achieve their goals, largely because of employee resistance and insufficient management support — comes from its article "Changing change management". The number is contested by academics who note that McKinsey published no sample or method behind it, so treat it as directional rather than precise. The direction, however, is not in dispute: the people side, not the software, is where transformation programs break.

That matters disproportionately for ERP because ERP touches every process and almost every employee at once. When a company undertakes an ERP program, the organizational focus is usually on the technology — what will it do, what will it cost, how fast can it go in? Those questions all skip the load-bearing assumption: technology only produces benefit if it is set up and used by the people who own the processes it affects. Where employees are not invested in the change, they either avoid the new system or engineer workarounds. Adoption stalls, the reporting layer fills with bad data, and the expected benefits never land. Our ERP implementation failure case studies show the same root cause again and again.

The ERP Change Management Framework

Most successful ERP change programs follow the same five phases, each with a clear owner. Use this as the backbone of your plan and assign a named person — not a department — to every row.

The two phases most often skipped are the first and the last. Teams start change management at training and stop it at go-live — precisely the two points where it delivers the least. Adoption cannot be measured until after go-live, so a program that ends at cutover has no way of knowing whether it worked.

Developing a Vision for Change

The first substantive deliverable of any ERP change program is a clear vision for change, and it is arguably the most important. Without it, the narrative for the program — and every communication, training message and engagement activity derived from that narrative — has no anchor.

A usable vision for change answers four questions in plain language: why is this needed, what will it give us, where does it take us, and what happens if we do nothing? It must be agreed by, and unite, the key stakeholders, because it becomes the single version of the truth from which everything else is built. Leaders who each describe the project differently will produce an organization that trusts none of them.

Keep it concrete. "Modernize our systems" is not a vision; "close the books in five days instead of fifteen, and give every branch manager live stock visibility" is. Concrete visions also give you the measurable success criteria you will need in phase five.

Building Your ERP Change Management Team

Ownership is where most ERP change programs quietly fail — everyone agrees change management matters and no one is accountable for it. Three roles are non-negotiable.

• The Executive Sponsor. A senior stakeholder — ideally at board or executive-committee level — who visibly owns the change. Their job is to give the workstream gravitas, adjust competing business priorities, unblock decisions and provide the escalation route when change activities slip. Sponsorship cannot be delegated to a project manager; research from Prosci consistently identifies active and visible executive sponsorship as the largest single contributor to change success.
• The Change Manager. The full-time (or near full-time) owner of the change plan: readiness assessment, communications, training coordination, adoption measurement. This role sits in program governance on equal footing with the technical workstream leads — attending steering committees, raising risks and issues, and submitting change requests like anyone else.
• The Change Network. Ten to fifty influential people drawn from across the affected business units, depending on your size. Critically, these are people with influence, not necessarily people with management titles. They test messages before they go out, surface resistance early, and become the super users who coach their peers after go-live.

Many organizations bring in external consultants for change management expertise, and where internal capability is thin that is usually money well spent. But change management cannot be outsourced wholesale. Every deliverable has to be tailored to and accepted by the receiving organization, and neither is achievable without heavy involvement from people who know how the business actually works. For a full RACI breakdown of the wider project structure, see our ERP project teams guide. If you are evaluating outside help, our ERP consulting overview explains what to look for.

ERP Change Management Best Practices Checklist

1. Start before selection, not before training. Run a change readiness assessment during evaluation so the results shape your timeline, budget and choice of implementation partner.
2. Name an executive sponsor with real authority. If no one senior enough to reprioritize work owns the change, it will lose every resource conflict it enters.
3. Write the vision for change down and get it signed off. One narrative, agreed by all leaders, before any communication goes out.
4. Budget change management as a workstream, not a line item. A common planning benchmark is 10-15% of total implementation cost. Compare against our ERP implementation cost breakdown.
5. Assess impact role by role. Generic communications fail. Every affected role should receive a short "what changes for you" briefing.
6. Build a change network of influencers. Peer advocacy moves adoption further than any executive email.
7. Train by role, in a sandbox, close to go-live — then again after. Training delivered too early is forgotten; training delivered once is ignored.
8. Measure adoption, not attendance. Login rates, transaction volumes by module, workaround incidence and support-ticket themes are the real signals.
9. Keep going after go-live. Reinforcement through the first year is what converts compliance into habit.
10. Tailor everything. There is no one-size-fits-all approach — organization size, module scope, headcount affected and your track record with previous change programs should all move the dial on how much engagement you need.

If you want these steps laid out as a document you can hand to a sponsor, our ERP change management plan template and structure walks through what to put in the plan itself.

Common ERP Change Management Risks and How to Avoid Them

• Change management starts too late. The classic pattern is calling for change support once the program is already showing signs of failure. Recovery at that point costs far more than prevention, and the trust of the organization is hard to win back. Mitigation: fund the workstream at kickoff.
• No accountable owner. "Everyone's responsible" means no one is. Mitigation: name the sponsor and change manager in the project charter.
• A one-size-fits-all approach. An organization that has delivered technology change successfully before needs far less engagement than one that has not. Mitigation: size activities against your actual change maturity.
• Communications that stop at announcement. A launch email is not a communications plan. Mitigation: publish a cadence by audience and hold to it.
• Training treated as a one-off event. Mitigation: role-based training plus post-go-live refreshers and permanent job aids.
• Change activities that never adapt. A plan written at kickoff will not survive contact with a design phase. Mitigation: review the impact of change activities at each stage gate and add sessions or extend scope where adoption signals are weak.
• Scope changes that skip the change assessment. Every new module or department pulled into scope creates new impacted users. Mitigation: assess people impact in every change request, as documented in your ERP project scope document.

Frequently Asked Questions

Who should own change management in an ERP project?

Two named people share it. An executive sponsor at board or exec-committee level owns visible commitment, resource conflicts and escalation. A dedicated change manager owns day-to-day delivery: readiness assessment, communications, training coordination and adoption measurement. Both sit in program governance alongside technical leads, supported by a change network of influential users. Ownership should never sit with IT alone or be fully outsourced.

What is an ERP change management plan?

An ERP change management plan is the document that turns best practices into scheduled, owned activity. It typically contains the vision for change, a stakeholder and impact analysis by role, the communications plan and cadence, the training approach, readiness criteria for go-live, adoption metrics, and the post-go-live reinforcement schedule. Best practices tell you what good looks like; the plan says who does what, by when, and how success will be measured.

How long does ERP change management take?

It runs the full length of the project and beyond. Practically, change activity begins during system selection — three to six months before implementation starts — continues through the six to eighteen months of a typical mid-market rollout, and carries on for six to twelve months after go-live. Adoption cannot be assessed until people are using the live system, so a change program that ends at cutover has no evidence it worked.

Does the Prosci ADKAR model apply to ERP projects?

Yes. ADKAR — Awareness, Desire, Knowledge, Ability, Reinforcement — maps cleanly onto an ERP timeline: awareness and desire during selection and design, knowledge and ability through training and UAT, reinforcement through hypercare and beyond. Its value in ERP is diagnostic: when adoption stalls, ADKAR tells you which stage failed, so you fix the right thing. Kotter's eight steps work similarly. Any recognized model beats no model.

What are the biggest risks of poor ERP change management?

Low user adoption is the headline risk, and it cascades: staff revert to spreadsheets and shadow systems, master data quality degrades, reporting becomes untrusted, and the benefits case never materializes. Secondary effects include extended and costly hypercare, higher support volumes, delayed benefit realization, key-staff attrition during the disruption, and — in the worst cases — an expensive second implementation to fix what adoption failure broke.

Next Steps

Change management is a broad discipline and this guide covers the elements that matter most in an ERP context. The pattern is consistent: projects that treat adoption as a funded, owned workstream from selection through the first year post-go-live deliver their business case; projects that treat it as training in the final month do not.

If you are earlier in the process, start with our explainer on what enterprise resource planning is, then work through the wider ERP implementation best practices that change management supports.