Change management in Business Central implementations: why it matters, why it fails, and how to make it work

When a Business Central implementation is reviewed afterwards, the technical failures are easy to list: the migration that did not reconcile, the integration that fell over, the extension that broke at the update. They are also, oddly, the easy ones to fix. The hard failure is the quiet one: the system went live, it works, and six months later the warehouse is back on a spreadsheet, finance has a parallel process "just to be safe", and the sales team enters orders in the old way through a workaround someone found in week two. Nothing is broken. The business simply did not change.

That is a change management failure, and it is the most common way a technically successful project delivers a fraction of what it was bought for. This post is about what change management actually is on a Business Central project, why it matters so much, what it looks like at different sizes of business, why it fails, and what to do about it.

What change management is, and is not

Change management is the structured work of moving the people in a business from the way they work today to the way they will work on the new system, so that on the Monday after go-live they can do their jobs, want to, and do not go back. It is not a communications plan, although it includes one. It is not training, although training is the most visible part. It is not a kickoff meeting and a poster. It is the combination of sponsorship, involvement, communication, training, support and measurement that means the change sticks.

The reason it matters disproportionately on an ERP project is that an ERP is not a tool people pick up; it is the process they work inside. Business Central decides what a sales order is, what has to be true before it can be shipped, how stock is counted, when the month closes. Swapping it changes the daily work of everyone who touches it. If they were not part of deciding how, do not understand why, and were not shown how, they will find a way to do it the old way. People are very good at that.

Why it is at the top of the list

This is not a soft opinion. Prosci's research, built over 25 years and more than 10,800 responses, finds that projects with excellent change management are roughly seven times more likely to meet their objectives than those with poor change management, and that the single biggest contributor to success, in every edition since 1998, is active and visible executive sponsorship. The 2026 ERP failure surveys attribute more failures to inadequate change management than to any other cause, ahead of data, scope and the software itself. And our own experience matches: of the projects we have seen go wrong, more went wrong in the people than in the system. We wrote about the causes in why ERP projects fail; change management is the thread that runs through most of them.

What it looks like at different sizes

The principles do not change with the size of the business; the amount of formal structure does. Over-engineer it in a small business and people stop listening. Under-engineer it in a large one and the message never reaches the shop floor.

Small: up to about 20 users, one site, moving from Xero or Sage

Everyone knows everyone. The managing director is the sponsor and is probably in the workshops. Change management here is mostly about involvement and honesty: the four or five people who do most of the work are in the design conversations, see the sandbox early, and are trained by doing. Communication is a weekly five-minute stand-up and a one-page "what changes for you". The risk at this size is not resistance; it is that nobody is given any time at all because everyone is busy, and the MD assumes that because they are excited everyone else is. The fix is a named super user per area with a day a week, and the MD saying out loud that the project matters more than this week's convenience.

Medium: 20 to 150 users, several departments, maybe a warehouse or a factory

This is where change management becomes a workstream with a name and an owner. There are people who will not be in the workshops and will hear about the system second-hand, departments whose process is changing in ways they did not ask for, and at least one group (usually the warehouse or the shop floor) for whom the system is a scanner and a screen rather than a career. The structure that works: a sponsor who is visibly accountable; process owners per department who decide and sign off; super users per team who are trained early and carry the message; a communication rhythm (monthly all-hands update, fortnightly department notes, a visible plan on a wall); role-based training delivered by the super users on the real configuration; and a hypercare period with the super users in the departments, not on a help desk. The budget for this is real: around a day a week per super user for six months, and a change lead (often the customer's project manager, sometimes a contractor) at two or three days a week. See the right project team for how to resource it.

Large: 150 users and up, multiple sites or companies, phased rollouts

Now change management is a discipline with a method behind it (Prosci's ADKAR, or Kotter, or whatever the business already uses), a dedicated change manager, a stakeholder map, an impact assessment per role, a training needs analysis, a communications calendar, readiness assessments before each go-live, and measurement afterwards. Each site or company is its own change, with its own local champions, because head office saying "we are going live" means nothing to a warehouse 200 miles away. Resistance is organised here: a department that sees the system as head office control, a union that wants to know about job changes, a site that was happy with its own way. These have to be engaged early and honestly, not managed around. The failure mode at this size is a change management workstream that produces artefacts (the plan, the matrix, the newsletter) and no change, because it is run as a communications exercise rather than as a line-management responsibility.

Why it fails

1. The sponsor delegated it. The MD announced the project and went back to the day job; the change was left to IT or the partner. Everyone below the sponsor read the signal correctly.
2. It started too late. Change management as a training plan in the last month. By then the design is done without the users and the attitudes are set.
3. The "why" was never explained. People were told what was changing and when, not why it mattered to the business or to them. "Because the old system is end of life" is not a reason anyone changes their behaviour for.
4. The people most affected were least involved. Designed by finance and the partner; delivered to the warehouse.
5. Training was an event, not a process. A classroom day from slides, three weeks before go-live, on a sandbox that did not look like production, by a consultant the users had never met.
6. No time was given. People were told it was important and measured on their day job. Covered in business as usual comes first.
7. The workarounds were tolerated. Week two, someone found a way to do it the old way, nobody stopped it, and by month three it was the process.
8. Nobody measured whether the change stuck. Go-live was declared a success on the day. Six months later nobody could say whether anyone was using the new process, because nobody had looked.
9. Middle managers were bypassed. Messages went from the sponsor to all staff. The team leaders, who are who people actually listen to, were neither briefed nor made responsible.
10. Resistance was treated as a problem to suppress. The person saying "this won't work for our customers" was usually right about something, and was ignored instead of asked.

How to stop it failing

• Sponsor, visibly, for the whole project. The sponsor opens every all-hands, chairs the steering group, walks the floor during UAT, and is there on go-live Monday. Prosci's finding is that this one thing is worth more than everything else combined.
• Start in the Diagnostic phase. The stakeholder map and the "what changes for whom" assessment are done before design starts, so that design involves the right people and the communication starts before the rumours.
• Explain why, in their terms. For finance, "month-end in five days instead of twelve". For the warehouse, "no more re-counting because the system was wrong". For sales, "you can see stock and promise a date". And honestly: "some of this will be harder for the first month".
• Involve the affected. Super users from every team in the workshops and the fit-gap, named in Analysis, trained from Development, running UAT, delivering end-user training. The super user post is most of the mechanism.
• Make middle managers responsible. Each team leader owns their team's readiness: attendance at training, questions answered, workarounds stopped. It is in their objectives.
• Train by role, on the real system, close to go-live, by people they know. Short sessions, each person's actual tasks, on the production configuration with migrated data, delivered by the super users with the consultant in support. Then a one-page guide per role on the desk on Monday morning.
• Communicate on a rhythm, and listen on the same rhythm. A fixed cadence of updates, and a fixed channel for questions and objections that gets answered within days. The objections are design input.
• Protect the time. Secondment or protected percentage, written down, with backfill. Decided by the sponsor, enforced by the managers.
• Kill the workarounds in hypercare. Super users in the departments for the first fortnight, whose job includes noticing the spreadsheet coming back and fixing the reason it came back. See hypercare.
• Measure adoption, not go-live. Pick five things the new process should make true (orders entered in the system same day, picks confirmed on the scanner, month-end closed by day five, no parallel spreadsheet in finance, supplier invoices matched to POs) and check them at 30, 90 and 180 days. Report them to the board. What is measured is what sticks.
• Treat resistance as information. Ask the resister what they are worried about. Half the time it is a real gap in the design; the other half it is a fear that a straight answer resolves.

The partner's part

Change management is the business's responsibility; nobody outside can make a company's people change. But the partner can make it easier or harder: by involving super users properly rather than treating them as testers, by training on the real configuration rather than a demo, by explaining the system in the business's language, by keeping the same consultants so the users build trust (continuity), and by being honest in the steering group about readiness rather than about the plan. A partner who says "the system is ready but your people are not, and here is what to do about it" is doing their job.

The short version

A Business Central implementation is a change to how people work with some software attached. The software will work. Whether the people work differently depends on a sponsor who shows up, super users who were involved from the start, managers who own their teams' readiness, training on the real thing by people they know, time that was actually given, workarounds that were stopped, and adoption that was measured. Scale the formality to the size of the business; do not scale the principles. If your project plan has a line called "training" and nothing else about people, that is the gap, and it is the one that decides whether the project was worth it. We are happy to look at a plan and tell you where it stands: get in touch.

More from the blog

• The right project team: business as usual comes first, and that is the problem Projects
• Field types, field lengths and overflow errors: getting the data model right the first time Development
• Coding patterns in AL: why use fifty lines when three will do Development