A few weeks ago, I met with the executive team of a financial services group preparing to migrate from JD Edwards to Oracle Cloud ERP. Contracts had been signed, the implementation methodology had been agreed and the project plan was ready. Before the project kick-off, however, they asked me to meet with them to discuss what the organization itself needed to have in place before implementation began.

As we reviewed the implementation plan, I raised three concerns that I believed deserved immediate attention, because all three depended far more on the customer’s own preparation than on Oracle or the implementation partner.

The first involved integrations. Their internal IT team was responsible for developing a significant number of critical interfaces early in the project. These integrations could not wait until the testing phase; they had to be functional from the start.

The second concerned key users’ availability. If the business experts responsible for validating future processes remained buried in day-to-day operations, the project would inevitably outpace the organization’s capacity to adapt.

They had already thought through the first two, but the third one surprised them: I asked how they intended to manage user adoption throughout the project.

When I explained that organizational adoption should begin long before training, the conversation changed. The CIO and CFO immediately began discussing who inside the organization should own that responsibility and how they would monitor progress throughout the implementation. They simply realized that someone within the business needed to take ownership of preparing the organization while the project was still being designed.

That conversation stayed with me because it illustrates a misconception that has become increasingly common in the SaaS era: treating adoption as something that begins with training.

That approach is a carryover from the era of on-premises ERPs. Twenty years ago, implementations dragged on for years, giving users a natural buffer to absorb change. Modern Cloud methodologies have compressed configuration timelines through standard, out-of-the-box functionality, but they have not compressed the human learning curve.

People still need time to understand why familiar processes are being replaced, to develop confidence in new ways of working, to redefine responsibilities, to make decisions they may never have faced before and to help their own teams navigate uncertainty. None of those activities occur automatically because configuration progresses according to schedule.

This is where I believe many CIOs continue planning SaaS implementations using assumptions inherited from an earlier generation of ERP projects.

Twenty years ago, organizations could afford to postpone many of these conversations. ERP implementations lasted years, giving business users time to absorb change while the project progressed. Modern SaaS methodologies deliberately eliminate that buffer. Configuration advances faster, key business decisions are expected much earlier and organizations have far less time to build understanding, alignment and commitment before go-live.

Key users influence solution design from the first workshops. Standard processes require organizations to challenge historical practices instead of recreating them. By the time end-user training begins, many of the decisions that determine whether people will ultimately embrace the new system have already been made.

Perhaps the most persistent misconception is that user adoption begins when training begins. In reality, training simply teaches users how to execute decisions that have already been made. Adoption starts much earlier. That means assigning adoption ownership in Phase 0, identifying stakeholder impacts during design, preparing managers as processes change, measuring readiness before UAT, and treating training as one milestone in a much longer adoption workstream.

Training remains essential, but it is no longer where adoption begins.

The organizations that navigate this transition most successfully usually recognize that organizational readiness deserves the same level of planning as technical readiness. They identify who will own adoption before the project starts. They ensure that key users have enough capacity to participate in design decisions. They prepare managers to lead conversations about changing processes rather than waiting until the software is ready. Most importantly, they treat adoption as a workstream that progresses alongside configuration, not as an activity scheduled after it.

That distinction has become increasingly important because today’s implementation timelines leave little opportunity to recover once organizational engagement starts falling behind. Integrations that are delivered late become visible quickly. Delayed configuration is immediately reflected in the project schedule. Poor adoption is different. The first symptoms often appear much later, even though the conditions that created them were already present during the earliest phases of the implementation.

Perhaps that is one of the most significant changes introduced by modern SaaS ERP implementations.

Looking back at that conversation, what changed was not the implementation plan, but their understanding of when adoption needed to begin. The organizations that benefit most from SaaS speed are usually those that begin preparing people long before they begin training them.