Change Management Is the Most Underfunded Part of Every SAP Migration

Change Management Is the Most
Underfunded Part of Every SAP Migration

Every study of ERP failure points to the same pattern: technology gets the budget, and
the people who have to run the new system every day get what's left over. With SAP's
2027 support deadline compressing timelines across the industry, that imbalance is
getting harder to absorb, even with AI tools helping stretch the training budget a bit
further.

SAP's mainstream maintenance for ECC ends December 31, 2027, and the pressure that date creates
isn't limited to SAP itself. As the installed base moves toward S/4HANA, the pool of consultants,
systems integrators, and third-party support providers still fluent in ECC-era configuration is thinning out
too, a predictable pattern whenever a platform generation winds down. Organizations weighing when to
move are increasingly weighing it against a shrinking bench of people who can still support the old
system well.

That deadline pressure tends to pull attention toward the technical workstream: data conversion, custom
code remediation, testing, cutover sequencing. What it doesn't pull attention toward, consistently, is the
several thousand employees who will have to do their jobs differently the day the new system goes live.
This piece looks at why organizations chronically underfund the human side of ERP transformation
relative to the technical side, and what that gap costs once the deadline arrives. AI-assisted training
tools get one mention near the end, as a way to stretch an already thin change-management budget a
little further, not as the fix for the underlying funding problem.

Prosci's 2025 research on ERP implementations quantifies a pattern that shows up across virtually
every large transformation. Organizations spend an average of 92% of ERP budgets on technology and
roughly 8% on change management. Yet the same organizations' leaders, asked in hindsight what

they'd do differently, say the people side of the project accounts for 36% of what they would change.
Prosci's research goes further and puts a number on the gap: human factors matter roughly six times
more than technical factors in determining whether an ERP program actually realizes its intended
benefits.

That gap isn't a training-budget footnote. It's a structural mismatch between where the risk actually sits
and where the money goes. And it's a big part of why so many technically successful go-lives (the
system works, the data migrated, the integrations hold) still fail to deliver the productivity and adoption
the business case assumed.

Traditional ERP training follows a fixed sequence: classroom or e-learning sessions before go-live, a set
of static job aids, and a help desk queue after go-live for whatever the training didn't cover. When the
change management budget is already a fraction of what the technology workstream gets, that
sequence tends to get compressed further under deadline pressure, and the compression usually falls
on the parts hardest to see from a project plan: refresher sessions, role-specific job aids, and contextual
support during the weeks after cutover, when the change is heaviest. Employees who get one training
pass weeks before go-live often meet the actual system for the first time on the day they're expected to
be productive in it.

Some organizations are using AI copilots and in-app assistants, including SAP's Joule and comparable
tools, to put a fraction of that support back without adding headcount, answering routine how-do-I
questions in the moment instead of routing them to a training team or help desk that's already stretched
thin. It's a genuine efficiency gain and a reasonable way to make a thin training budget cover more
ground. It doesn't change the underlying math, though. A program that starts from a
change-management allocation in the single digits is still starting from that allocation, whatever tools it
deploys inside it.

The more interesting number in SAVIC's research isn't the deflection rate. It's what adoption intensity
does to measured productivity. Deployments reaching 60% or higher weekly-active adoption produced
three to four times the measured productivity improvement of low-adoption deployments using the same
underlying tools. The AI copilot itself doesn't generate that value. Getting enough of the workforce to
actually use it, consistently, does. And that puts change management back at the center of the picture
instead of the periphery.

SAVIC's research also offers a specific, actionable number here: high-performing implementations
allocate 15–25% of their total AI programme budget specifically to change management, nearly double
the average share Prosci found across ERP programs generally. There's a reason for that. It's the
closest thing in this research to a direct causal link between change management investment and
realized value from AI-assisted tooling.

the productivity improvement seen in deployments with 60%+
weekly-active adoption, compared to low-adoption deployments using
identical AI tooling. (SAVIC Technologies, citing SAP data)

An always-available AI copilot can quietly become a crutch instead of a bridge to real capability, if it's the
only investment a program makes in adoption. A user who can always ask a chatbot how to complete a
transaction may never build the underlying process fluency the organization needs, particularly for less
routine scenarios the copilot hasn't seen enough of to answer well. The programs getting this right use
AI copilots to absorb the high-volume, routine question load. That frees a genuinely well-resourced
change management team (trainers, champions, super-users) to focus on the harder work: building real
capability and handling process changes that need more than a quick answer.

Change management is one of the areas Orpington Technologies pushes hardest on, both in the
programs it leads directly and in the independent diagnostics it runs for clients weighing their own
migration timeline. With the ECC support window closing at the end of 2027 and the pool of specialists
who know that platform well shrinking alongside it, waiting to fix the training gap until closer to go-live
only compresses an already tight schedule. Orpington's migration practice pairs deep SAP technical
delivery with a change management function built to actual scale rather than bolted on near cutover,
using AI-assisted tooling as one of several ways to make that investment go further. Learn more about
Orpington's approach at orpingtontech.com.