In a 2025 study of two hundred SAP user companies that had completed their S/4HANA migration, only eight percent finished on schedule. Projects ran an average of thirty percent longer than planned. More than six in ten exceeded their planned budget. The report, from Horváth, was widely circulated in the SAP community when it came out — and then, almost as widely, ignored.

The reason it was ignored is that everyone in the industry already knew. SAP project overruns are not news. They are the background condition of the field. What was useful about the Horváth study was not the headline numbers but the diagnosis. The leading reasons projects failed were not technical. They were, in roughly this order: scope expansion during transformation, poorly managed data transition, a blueprint that gets revised rather than fixed, and a lack of clear governance.

Read those four causes carefully. None of them is a problem with the SAP software. None is a problem with technical configuration, integration architecture, or cloud infrastructure. They are all problems of human and organizational behavior — of process, of decision-making, of stakeholder alignment. They are, in other words, adoption problems wearing technical clothing.

Why this matters now

The mainstream support deadline for SAP ECC is December 2027. Roughly forty percent of original ECC customers — somewhere on the order of fourteen thousand organizations globally — will still be on the legacy platform when that deadline lands. Of those, a substantial share are in the planning or exploration phase as of early 2026. The window for a controlled migration is narrow and closing.

What this means in practice is that the next eighteen months will see the largest concurrent enterprise software migration cycle in the history of the field. Consulting capacity is already constrained. Senior S/4HANA roles are taking ninety-plus days to fill. Contract rates are projected to rise thirty to fifty percent in 2026 and 2027. The economics of delay are punishing.

The temptation, under that pressure, is to focus relentlessly on the technical execution. Which migration path: greenfield, brownfield, selective? Which deployment model: public cloud, private cloud, on-premise? Which integration architecture? Which data migration approach? These are real questions. They have to be answered. But they are not the questions that decide whether a migration succeeds.

The questions that decide whether a migration succeeds are almost entirely about humans — and they are mostly being asked too late, by the wrong people, with the wrong tools.

What the human factors literature actually says

Human factors and ergonomics is, broadly speaking, the academic discipline concerned with how humans interact with complex systems. It has been studying enterprise software adoption — under various names — for roughly thirty years. The findings, distilled to their essence, are not surprising. But they are remarkably consistent, and remarkably absent from most ERP migration playbooks.

Three findings matter most for what's about to happen in the SAP world.

1. Adoption is a function of perceived effort relative to perceived benefit, not of actual capability.

Davis's Technology Acceptance Model — first published in 1989 and replicated more times than almost any other behavioral model in information systems — found that two perceptions, and only two, robustly predict whether users will adopt a new system: perceived usefulness and perceived ease of use. Both are perceptions, not facts. A system that is objectively more capable than what it replaces will fail to be adopted if users perceive it as harder to use, or if they perceive its benefits as accruing to someone other than themselves.

The implication for S/4HANA migrations is direct. Most communication about migration is framed around organizational benefit — modernization, capability, compliance with the deadline. Almost none of it is framed around the daily user's perception. The accounts payable clerk does not care that the platform is on a modern cloud architecture. She cares whether her invoice posting workflow takes longer or shorter, and whether the reports she has to run for her manager still produce the same numbers in the same places. These are not trivial concerns. They are the concerns that determine adoption.

2. Workarounds are the strongest signal of failed adoption — and they typically appear before go-live.

One of the most replicated findings in the workplace adoption literature is that users develop workarounds when system designs do not match the contours of their actual work. The workarounds appear in roughly three forms: shadow systems (the spreadsheet kept on a personal drive), informal information networks (the Slack channel where people ask each other how to do things the system makes hard), and procedural drift (the steps people skip or invent because following the official process is too slow).

What is less widely understood is that workarounds typically begin during the implementation phase, not after. End users, watching their workflow being redesigned in workshops they are sometimes invited to and sometimes not, begin preparing their workarounds before the system goes live. By the time hypercare ends, the shadow systems are already deeply embedded.

The remedy is not to prevent workarounds — that is futile. It is to detect them early, treat them as diagnostic information about where the design is failing, and feed that information back into the implementation. This is exactly what most S/4HANA programs do not do.

3. Organizational change effort is non-linear in scale.

The third finding, less famous than the first two but perhaps more consequential, is that the effort required to manage adoption does not scale linearly with the size of the implementation. It scales with the square of the number of affected stakeholder groups multiplied by the depth of process change. A migration that touches fifty users in one function with light process change is a tractable problem. A migration that touches five thousand users across ten functions with deep process change is, from an adoption perspective, a hundred times harder — not ten times harder.

This is why the S/4HANA migrations in trouble right now are mostly the ones at large enterprises with complex landscapes, and why the migrations going relatively smoothly are mostly at organizations with simpler footprints. It is also why the standard playbook — borrowed from smaller mid-market implementations — fails when applied at scale. The playbook scales linearly. The problem does not.

What this looks like in practice

Translated to specific recommendations, the literature suggests three things that any S/4HANA program in the planning or blueprint phase should be doing right now, regardless of which migration path or deployment model has been chosen.

First, treat the discovery phase as a research problem, not a documentation problem. Most S/4HANA discovery work today consists of process modelers interviewing process owners and producing as-is process maps. These maps are necessary but insufficient. They capture the formal process. They almost never capture the informal process — the workarounds, the shadow systems, the procedural drift — and it is the informal process that determines what happens at go-live. A discovery phase that wants to predict adoption needs ethnographic methods: shadowing, journey mapping, telemetry of actual workflow use. None of this is exotic. The methodology has been mature for decades. It is simply not in the standard SAP implementation toolkit.

Second, instrument the implementation for adoption signals from day one of hypercare, not from a quarterly review six months later. If users are going to develop workarounds, the question is whether the implementation team detects them early enough to do something about it. That requires deliberate design — observation protocols, lightweight check-ins, anonymous reporting channels, telemetry on which features are actually being used and which are being avoided. Most programs do not have this instrumentation. They have a hypercare desk that responds to tickets, which is a different thing entirely. Tickets surface only the workarounds users are willing to admit to.

Third, recognize that change enablement is a discipline, not a workstream. In most S/4HANA program structures, change management is one workstream among many — peer to data migration, integration, testing, and cutover. This is the wrong organizational shape. Change enablement is not a parallel activity to those workstreams; it is the lens through which all of them have to be evaluated. A data migration that is technically correct but breaks a workflow users depend on has not succeeded. An integration that meets all functional requirements but introduces latency that makes users abandon the new system has not succeeded. These judgments require a change-enablement function with authority across workstreams, not embedded inside one of them.

Why this is hard

None of what I've written here is new. The technology acceptance model has been published for thirty-six years. The workarounds literature is comparably old. The non-linear scaling of organizational change has been a working assumption in the change management field for at least two decades.

And yet the same problems recur, S/4HANA program after S/4HANA program. They recur because the organizational structures that govern enterprise software implementations are not built to absorb behavioral findings. The decision rights sit with technical and program leadership. The deliverables are technical and procedural. The success metrics are go-live, budget, and timeline. Adoption does not appear in the metric set until after the program has shipped — at which point the levers to improve it have largely closed.

This will not change because of an essay. It might change at the margin because of a deadline that is now eighteen months away, with consequences serious enough that organizations are starting to ask different questions about what they are buying when they buy implementation services.

The migrations that land standing in 2027 will not be the ones that executed flawlessly on the technical side. They will be the ones that took the human factors seriously enough, early enough, to build them into the program architecture. There is still time to do that. But the window is closing.

Ikechukwu Ohu, PhD is an independent consultant working on enterprise process, adoption, and human factors. He spent three and a half years as a UX Researcher in AWS Fintech R&D and is Full Professor and Program Director of Industrial & Robotics Engineering at Gannon University. His research on motion-based assessment of clinical training has been funded by the American Heart Association and is published widely. He is currently certifying in SAP S/4HANA Cloud Public Edition Financial Accounting.