5 Ways to Manage Staff Resistance to New ERP Software
Here’s the uncomfortable truth about replacing a city’s ERP:
The software is rarely the hard part.
The people are.
Managing staff resistance to new ERP software really comes down to reducing fear.
You do that by setting honest expectations about the rollout, respecting the decade of muscle memory people are about to lose, engineering an early win, giving them peer support, and proving that their feedback changes the system.
Get those five right and “we’ve always done it this way” softens into “okay, show me.”
At Kreative Core Technologies, we’ve run public-sector ERP go-lives and recoveries for cities and agencies across the country.
The projects that succeed have one thing in common.
The people using the system feel secure.
The ones that stall usually have the technology working fine while staff quietly go back to their spreadsheets.
Most advice treats resistance like a communications problem.
Send more emails, run more trainings.
But the real issue is fear.
When a clerk who has closed the books the same way for twelve years watches that skill turn worthless overnight, she isn’t being difficult.
She’s staring at a genuine professional risk, and it feels a lot like grief.
The numbers say the same thing.
McKinsey found that about 70% of large-scale transformations miss their goals, and employee resistance is one of the two biggest reasons.
Narrow it to software, and Godlan’s 2025 ERP research traces 42% of ERP failures back to weak change management.
So here are the five things we do to calm staff anxiety on a new ERP, tax, or permitting platform.
How to reduce staff resistance when switching to new ERP software
1. Kill the “perfection” myth on day one
The fastest way to spike anxiety is to promise a flawless go-live.
So don’t.
Tell staff straight out that the first few weeks will be rough, and that rough is normal.
When leadership oversells “seamless,” every ordinary glitch turns into evidence that the whole thing is broken.
And glitches are guaranteed.
Even after thorough pre-launch training, users still struggle once they’re working in the live system.
That struggle has nothing to do with bad training. It’s the normal cost of learning something new.
So spell out what “normal turbulence” looks like before go-live.
Put out a plain-language “first 30 days” note. What will feel slow, what’s likely to break, who to call, and when it eases up.
Name the bumps in advance, and people stop panicking when they hit one.
Make it specific to their world.
Warn the utility-billing team that the first bill run might take twice as long and need a manual check, and that you’ve already planned for it.
Warn the tax office that a few parcels will have to be reconciled by hand that first week.
Naming the exact bump in their exact workflow is what separates “the system is broken” from “right, they told us about this one.”
2. Respect the “muscle-memory” debt
Your most experienced staff usually take this the hardest.
They spent years building expertise, and a new system just made it irrelevant, and that loss is real.
Picture what actually happens at go-live.
A payroll specialist who could run the old system in her sleep is suddenly a beginner again, clicking around unfamiliar screens in front of the same coworkers she used to rescue.
Resistance usually traces back to four things (economic, sociological, psychological, and rational), and the people with the deepest muscle memory push back hardest because they have the most to lose.
Public-sector shops feel it more, since tenures run long and a lot of institutional knowledge lives in a handful of veterans.
Pay that debt down on purpose.
List the five or ten tasks people do on autopilot (month-end close, reconciliations, permit intake) and build side-by-side “old way → new way” cheat sheets for each one.
Do that, and you’re doing more than teaching software.
You’re telling your veterans the skill they built still counts.
3. Engineer an early win
Sequence the rollout, so staff feels a genuine improvement in the first week instead of somewhere around month six.
The opening days set the mood for everything that follows, and confidence builds on itself.
Find a real headache in the old system and make sure the new one kills it first.
Maybe a report that took three days to pull.
A month-end reconciliation everyone did by hand.
Some form that made people log in three separate times.
The day a daily annoyance vanishes, the mood shifts from “this is being done to us” to “wait, this is actually better.”
It’s the pattern behind the turnarounds in our public-sector case studies, where we built momentum early on purpose.
That makes sequencing a design decision, not an afterthought.
It’s a big part of how we run a full-spectrum ERP implementation.
We deliberately put a visible “hero workflow” first, one that clearly improves on day one, because a fast, concrete win buys patience for the harder stuff waiting behind it.
Roll out in the order that helps staff, not the order that’s easiest for IT. The first thing people touch should be the thing that most obviously makes their day better.
4. Designate “digital champions” for peer-to-peer support
When your staff gets stuck, most of them would rather lean over to the coworker beside them than open a ticket or raise a hand in a meeting.
The real help desk sits two desks over.
A mentorship setup where the tech-comfortable employees help the ones who are struggling.
That peer layer catches all the small frustrations that never reach a support queue but quietly kill adoption anyway.
Stand it up early.
Name one champion for every eight to ten users, give them access ahead of the crowd, and hand them a direct line to the project team so their questions get quick answers.
They end up translating between the vendor’s jargon and the way your people actually describe the work.
Every question a champion fields is one that never had the chance to harden into resentment.
5. The “feedback loop” guarantee
People stop flagging problems the moment they decide nothing will come of it.
So make the loop real.
Every piece of feedback gets read and answered, where people can see it.
This is where change management actually lives or dies.
Organizations with weak change management get only about one project in eight to hit its objectives, and a dead feedback loop is one of the surest signs you’re headed there.
Once people submit an issue into silence, they quit submitting, and you lose your best early warning right when you need it.
Keep it concrete.
Set up one obvious place to send feedback, then run a short weekly “you said, we did” update, naming the actual fixes that shipped because someone spoke up.
The first time a staffer sees her own suggestion turn into a change, her resistance starts turning into ownership.
That’s when the system stops being something done to them and becomes theirs.
Frequently asked questions
Why do employees resist new software?
Employees resist new software mostly out of fear. A new system wipes out years of muscle memory and makes experienced staff feel like beginners again.
How do you reduce stress when switching to new software?
You reduce stress by managing the fear, not just the features. Set honest expectations about a bumpy start, respect the muscle memory people are giving up, engineer a visible early win, and give staff a trusted peer to ask for help. Stress drops fastest when people feel supported and see the change improving their day.
How do you get staff to adopt a new ERP system?
You get staff to adopt a new ERP by reducing fear and proving value early. Set honest expectations about a rough start, deliver a visible improvement in week one, give people peer “digital champions” for day-to-day help, and run a feedback loop that turns their input into real fixes. Adoption follows trust.
How long does it take to get used to new software?
Most staff need several weeks to rebuild fluency on a new ERP, and comfort keeps improving for months after go-live. The timeline depends less on the software’s complexity than on the support around it. Hands-on, scenario-based training and strong peer support shorten the curve dramatically; a “figure it out” rollout stretches it.
What is the biggest cause of ERP implementation failure?
Inadequate change management is the biggest avoidable cause of ERP implementation failure. Godlan’s 2025 research attributes 42% of ERP failures to it, and McKinsey ties roughly 70% of transformation failures largely to employee resistance. The technology usually works. Projects fail when the people meant to use them never fully adopt them.
Final Words
On an ERP project, empathy does real structural work. It carries as much weight as data migration or the cutover plan.
Here’s why these systems almost never die on the server.
They die at the desk, the moment someone loses confidence and slips back to the workaround they trust.
So give the human side the same rigor you’d give the build.
If you’re already mid-go-live and adoption is sliding, that’s fixable, and it’s most of what our management advisory and ERP recovery and optimization work involves.
Usually, it comes down to rebuilding trust rather than rewriting code. Get the people right, and the software finally gets to do the job you bought it for.