The real reason ERP rollouts stall at month four
There’s a specific, recognizable point where a lot of ERP rollouts start to wobble: somewhere around month four. Configuration is mostly done, the core workflows technically work, and momentum that felt strong at kickoff has quietly evaporated. The instinctive explanation is almost always “the software isn’t quite right yet” — a module needs tweaking, a report is missing a field, an integration is behaving strangely. Occasionally that’s true. Far more often, the software is basically fine, and what’s actually stalled is something nobody put a plan around in the first place: the humans who are supposed to use it every day.
The gap between “configured” and “adopted”
A go-live date measures whether the system technically works — whether data flows, whether a purchase order can be created and approved, whether the general ledger balances. It says nothing about whether the warehouse team trusts the new inventory numbers enough to stop keeping their own spreadsheet on the side, or whether sales still has a workaround because the new quoting process feels slower than what they’re used to. Those two things — technical readiness and organizational adoption — get tracked on completely different timelines, and most project plans only track the first one. The second one is where month four goes wrong, quietly, because nobody was measuring it.
Four patterns that predict a stall, and show up before month four if you’re watching for them
Training happened once, right before go-live, and covered “how to click the buttons,” not “how to do your job differently.” The standard training format — a few sessions in the two weeks before launch, walking through the interface — teaches people where things are. It doesn’t teach them why a process changed, what to do when a real-world situation doesn’t match the happy path shown in training, or how their specific role’s day-to-day judgment calls map onto the new system. Three weeks after go-live, when a genuinely ambiguous situation comes up that training never covered, the person facing it either guesses, reverts to the old way, or waits — none of which are captured as a “failure” anywhere, which is exactly why this pattern is so easy to miss until it’s already widespread.
There’s no visible executive sponsor after go-live, only before it. Executive sponsorship is usually strong during the sales and kickoff phase — leadership shows up, talks about strategic importance, sets the tone. Then the project moves into execution and that visible sponsorship often quietly disappears, exactly when middle management and frontline staff are deciding, in a hundred small daily moments, whether the new system is actually mandatory or just strongly suggested. If leadership isn’t visibly and consistently reinforcing that the old way is genuinely retired, that ambiguity gets resolved by employees defaulting to whatever’s most comfortable, which is usually the old process, kept alive through a workaround that never appears on any project status report.
Super-users were appointed, not developed. Nearly every ERP methodology includes designating “super-users” — the people other employees turn to with day-to-day questions. Where this breaks down: super-users are frequently chosen for availability or seniority rather than for aptitude, given a slightly longer version of the same generic training everyone else got, and then expected to field genuinely difficult, department-specific questions they were never actually prepared for. When a super-user can’t answer a question with confidence, that erodes trust in the system for everyone who was relying on them faster than almost anything else in the rollout.
Data migration was judged on “did it move,” not “do people trust it.” Data migration projects get measured against a technical benchmark — record counts matching, referential integrity holding, validation scripts passing — and those are the right things to check. What frequently doesn’t get checked with the same rigor: does the migrated data actually match what long-tenured employees know to be true about their own operational reality. If a warehouse supervisor pulls up the new system and sees a stock level they know is wrong, based on what they physically counted last week, that single moment can undo weeks of change-management effort — because from that point forward, they check the new system’s numbers against their own memory before trusting them, which is functionally the same as not trusting the system at all.
What prevents the stall
None of these four patterns are hard to prevent — they’re just easy to leave out of a plan that’s organized around technical milestones, because none of them show up as a checkbox on a standard project timeline. What actually prevents the month-four stall is treating change management as a workstream with its own real budget and its own owner, not as a slide in the kickoff deck.
Concretely, that means role-based training that covers judgment calls and edge cases, not just interface navigation — and training that continues past go-live, not just before it. It means a visible executive sponsor who keeps showing up after launch, closing off the old-system workarounds explicitly rather than letting them fade out on their own schedule. It means selecting super-users for genuine aptitude and giving them real, deep preparation — including a clear path to escalate the questions even they can’t answer, so gaps get closed instead of quietly eroding trust. And it means validating migrated data against the operational knowledge of the people who’ll actually use it, not just against technical integrity checks, before go-live rather than after someone spots the first wrong number.
The honest timeline
A rollout that takes change management this seriously often looks slower on paper in the early months — more time in training design, more time validating data against real operational knowledge, more visible ongoing sponsorship work that doesn’t show up as a technical milestone. What it buys in exchange is a system that’s actually being used the way it was designed to be used at month six, rather than a system that’s technically live while half the organization quietly keeps its old spreadsheet running in parallel, indefinitely, because nobody ever gave them a good enough reason — and enough support — to stop.