The period between signing off a new system and starting formal training is where most preparation failures happen. Business owners often assume that once the contract is signed, the hard work is done. In practice, the technical build is only part of the transition. If staff arrive at their first training session without understanding why the system is changing, what will be different for them personally, and what is expected of them, adoption will suffer regardless of how well the software works.
Preparation is distinct from training. Training teaches people which buttons to press. Preparation ensures they understand why they are pressing them, what happens to their existing workarounds, and how their daily routine will shift. Skipping preparation and jumping straight to training creates confusion: people learn the mechanics of a new CRM or portal but cannot connect those mechanics to their actual job.
The scope of preparation depends on how far the new system departs from current working practices. Replacing a legacy CRM with a modern version that follows the same broad workflow requires less groundwork than moving from spreadsheets to a structured application with defined roles, permissions and mandatory fields. The bigger the behavioural shift, the more preparation the change demands.
Rollout decisions that affect adoption
Mapping who is affected and how
Before any communication goes out, identify every group that will interact with the new system. This is not just the people who will log in daily. It includes staff who currently receive reports from the old system, managers who approve workflows, and anyone who supplies data that feeds into the process. For each group, document what they do today, what they will do after go-live, and what specifically changes for them.
Understanding informal workarounds
Most business systems accumulate unofficial processes over time. A CRM might have a formal lead-handling workflow, but the sales team might actually coordinate through a shared spreadsheet or a messaging channel. A document management system might be bypassed for urgent items emailed directly. If the new system does not accommodate these real-world behaviours, or if it eliminates them without a clear replacement, staff will resist. Part of preparation is surfacing these workarounds before go-live so they can be addressed in the system design or acknowledged in the transition plan.
Communicating the rationale clearly
Staff need to understand the business reason for the change, not just the feature list. "We are moving to a new portal because the old system cannot handle the volume of document approvals and is creating delays for clients" is more useful than "the new portal has role-based access and an audit trail." Different groups may need different framing. A finance team might care about data accuracy and reporting speed. A customer-facing team might care about reducing manual re-entry. Tailor the message to what each group stands to gain or lose.
Identifying internal champions
Most organisations have at least one person in each affected team who is naturally curious about new tools and influential among peers. Involving these people early, giving them access to pre-release versions or demonstrations, and making them a point of contact for questions from their team can significantly reduce resistance. Champions do not replace formal training, but they provide a local, trusted voice that a project manager or external supplier cannot offer.
Timing the preparation phase
Preparation should begin well before the system is ready for training. A practical starting point is when the core processes and role structures have been defined, even if the interface is still being built. At that stage, you can communicate what will change, who will be affected, and roughly when. Waiting until the system is fully built before telling staff about it compresses the preparation window and leaves people feeling that the change is being imposed without consultation.
Treating an email as preparation
Sending a company-wide announcement that a new system is coming is not preparation. It is notification. Preparation requires two-way communication: opportunities for staff to ask questions, raise concerns, and understand how their specific role will change. Without this, the email is filed and forgotten, and the first real engagement happens in a training session when it is too late to influence expectations.
Assuming uniform impact
Not everyone is affected equally by a new system. A front-line data-entry operator may see their entire daily routine change. A senior manager may only notice a different report format. Treating the whole organisation as a single audience leads to communications that are too vague for some and unnecessarily detailed for others. Segment the audience and prepare each group according to their actual exposure.
Overlooking what is being taken away
Staff often focus on what a new system removes rather than what it adds. A familiar shortcut, a custom view they built themselves, a report they could generate in seconds — these disappear. If preparation does not acknowledge these losses and explain what replaces them, people will perceive the new system as a downgrade regardless of its objective improvements.
Failing to set realistic expectations
If the first version of the new system does not include every feature of the old one, say so explicitly. Promising a seamless transition and then delivering something that is clearly incomplete destroys trust. Be clear about what will be available at launch, what will follow in later phases, and what is being deliberately dropped. Staff can handle an honest phased approach; they cannot handle unexpected gaps.
Checks before approving the rollout plan
Before transitioning from preparation to a formal training plan, verify the following: every affected group has been identified and understands what changes for them; informal workarounds have been surfaced and either accommodated or explicitly retired; the business rationale has been communicated in terms relevant to each group; at least one champion per team has been briefed and is available for peer questions; and staff know the rough timeline and what to expect in the training phase. If any of these are missing, preparation is incomplete and training will absorb problems that should have been resolved earlier.