Six months after a new system goes live, a familiar thing happens. The head of year is keeping their own spreadsheet again, because "it is quicker." Two departments are still using the old process. Attendance is being entered twice, once in the system and once on paper because a teacher does not trust it. The software works. Nobody is using it as intended.
From the outside this looks like a bad product. From the inside it is almost always a bad rollout, and the failure modes repeat across schools with striking consistency.
The first is going live in September. It is the intuitive choice — new year, fresh start — and it is close to the worst possible timing. September is the single busiest, highest-stress period in a school. New students, new staff, new timetable, parents to meet, everything at once. Asking people to learn a new system in the week they have the least capacity guarantees they will fall back to whatever they already know the moment something is urgent, and that fallback becomes the habit. A quieter window, with the new system running before the pressure arrives, is far more likely to stick.
The second is running both systems in parallel indefinitely. It feels prudent — keep the old one available in case the new one falls over. In practice it guarantees failure, because when someone is in a hurry they will use the tool they already know, and the new system quietly becomes the one that holds a partial and therefore untrustworthy version of the truth. Once it is untrustworthy, nobody uses it, and the conclusion drawn is that the software did not work. A short overlap with a hard, announced cut-off date is uncomfortable and works. An open-ended overlap is comfortable and does not.
The third is training that teaches the software rather than the job. A two-hour session walking through menus produces staff who have seen the software and cannot do their work in it. What they need is their own task, in their own context: this is how you take your register, on your device, in your classroom, including what to do when the wifi drops. Role-specific, task-based, and ideally done in the room where the task actually happens. The generic all-staff walkthrough is the most common and least effective form of training in school technology.
The fourth is having no answer for the first week of problems. Something will not work — a login, a permission, a class list that imported oddly. If the answer is "email the vendor," people will not. They will work around it, and the workaround will become permanent. Someone on site, visibly available, for the first week, resolves more adoption risk than any amount of documentation.
The fifth is not deciding what success looks like. Without a measure, the evaluation defaults to whoever complains loudest, and in any change the loudest voices are the people who preferred the old way. Decide beforehand: registers completed within ten minutes of the period starting, parent messages sent from the system rather than personal phones, the timetable rebuilt without a spreadsheet. Then measure it. A rollout that improves three of five stated measures is a success with work to do; the same rollout with no measures is remembered as the year the new system caused problems.
The sixth is ignoring the people whose informal power the change disrupts. In most schools someone is the acknowledged expert on the current process. They built the spreadsheet everyone relies on and they are consulted constantly. A new system removes that role, and however professional they are, they have little incentive to make it succeed. The fix is to give them the equivalent role in the new system — make them the person who knows it best — rather than treating the resistance as an attitude problem.
What consistently works is less dramatic than any of this suggests. Go live with one module, not the whole platform. Pick the one where the current pain is worst, so the improvement is obvious and the goodwill is earned before you ask for more. Run it with one department first, fix what that surfaces, and let those staff tell their colleagues it works — peer endorsement moves adoption in a way that leadership endorsement does not. Then expand.
And migrate less data than you think you need. Schools routinely insist on bringing across a decade of history, which extends the project by months, introduces most of its data quality problems, and serves a need that a read-only archive of the old system would have met just as well. Current year plus whatever is legally required is usually the right answer.
It is worth naming the vendor’s share of this. A vendor who hands over logins and disappears has set the school up to fail, and the school should ask what implementation support actually looks like — who is available, for how long, and whether it costs extra. But the decisions that determine the outcome are mostly the school’s: when to go live, how long to run parallel, how to train, and what to measure.
Whatever you are rolling out, the software being good is a prerequisite and not a plan. The schools where adoption works are not the ones that bought the best product. They are the ones that went live in February with one module, cut the old system off on a stated date, trained people on their own tasks, and had someone in the building when it broke.