ERP Change Management Best Practices

ERP change management is the structured discipline of preparing, equipping and supporting the people in your organisation 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 programmes that stick from programmes 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 programme which affects people, process or technology. The activities inside it vary by project type, but the goal never does: to move the organisation 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 programmes 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 programmes break.

That matters disproportionately for ERP because ERP touches every process and almost every employee at once. When a company undertakes an ERP programme, the organisational 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 programmes 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 programme 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 programme is a clear vision for change, and it is arguably the most important. Without it, the narrative for the programme — 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 programme differently will produce an organisation that trusts none of them.

Keep it concrete. "Modernise 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 programmes 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 co-ordination, adoption measurement. This role sits in programme 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 organisations 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 organisation, 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 reprioritise 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 — organisation size, module scope, headcount affected and your track record with previous change programmes 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 programme is already showing signs of failure. Recovery at that point costs far more than prevention, and the trust of the organisation is hard to win back. Mitigation: fund the workstream at kick-off.
• No accountable owner. "Everyone's responsible" means no one is. Mitigation: name the sponsor and change manager in the programme charter.
• A one-size-fits-all approach. An organisation 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 kick-off 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 co-ordination and adoption measurement. Both sit in programme 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 programme 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 programme 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 recognised 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 materialises. Secondary effects include extended and costly hypercare, higher support volumes, delayed benefit realisation, 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: programmes that treat adoption as a funded, owned workstream from selection through the first year post-go-live deliver their business case; programmes 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.