Most schools spend the bulk of their procurement effort comparing features. Which platform handles boarding management better. Which one has the cleanest curriculum module. Whose admissions workflow looks the most polished in the demo.
Features matter, obviously. But they’re rarely what separates a successful switch from a failed one.
Two providers can have functionally identical capabilities and produce completely different outcomes once the contract is signed. The variable isn’t what the software does. It’s what the people behind it do after you’ve handed over the cheque.
We’ve watched schools sign with strong-on-paper providers and end up six months in, still trying to get their data migrated, with no clear point of contact, and a sense that they’ve been handed off to a support inbox somewhere. We’ve also watched schools sign with providers whose products had a slightly less impressive demo, and be fully live in 60 days with a team that knows their names.
The difference is implementation support. Here’s what to actually look for, and the red flags that tend to give the game away.
The five things below aren’t a wishlist. They’re the bare minimum for a serious provider. If something on this list isn’t on offer, treat that as information.
You’ll know within the first few sales conversations whether a provider takes implementation seriously or treats it as an afterthought. The signs are easy to spot once you know what you’re looking at.
When you sign a contract, somebody specific should own your project. One person, with a name, a job title, and an inbox you can email directly.
That person should introduce themselves before the project starts. They should be in your kick-off meeting. They should be the consistent point of contact through configuration, training, and go-live. When something needs deciding, they’re who you talk to. When something goes wrong, they’re who you escalate to.
The red flag. You ask who’ll be running the implementation and you get a vague answer. “Our team,” or “we have specialists who handle that,” or “you’ll be in great hands.” If nobody can give you a name during the sales process, you’re going to be passed around once the contract is signed.
A second version of the red flag: you do get a name, but that person is on every customer’s account simultaneously and you struggle to get time on their calendar. Ask, during procurement, how many active implementations the named person is typically running at once. The honest answer should be small enough that they can actually focus on you.
A serious provider has a default implementation plan. Not a generic Gantt chart they email after kick-off, but a real, structured framework with named phases, defined milestones, and clear checkpoints. They’ve run this many times. They know what week three looks like.
You should leave the procurement conversation with a clear picture of the project from end to end. When does data preparation start? When does configuration begin? When are training sessions scheduled? When is go-live? What happens in the two weeks after go-live?
If the answer to those questions is “we’ll work that out together once you’re a customer,” you’re being handed a project that hasn’t been properly designed.
The red flag. Vague timelines. Phrases like “it depends” used as a substitute for “here’s how it typically goes, with these variables.” The honest version of “it depends” is a specific answer with caveats. The unhelpful version is a shrug.
Another red flag: a project plan that doesn’t include a stabilisation phase after go-live. If the implementation timeline ends on launch day, you’re looking at a provider who sees go-live as a finish line. It isn’t. It’s the start of the bit that determines whether the switch actually worked.
Data migration is the part schools worry about most, often for good reason. It’s also the part where the difference between a structured provider and an improvising one shows up most clearly.
A serious provider will give you, early in the project, a clear data preparation document. It tells you what fields they need, in what format, with what naming conventions, and what to do about the fields that don’t translate cleanly. They run test imports before the real one. They have validation steps. They tell you, before go-live, what was migrated, what was archived, and what didn’t make the cut.
The red flag. Lack of specificity about how data migration actually works. If a provider can’t walk you through their migration process step by step during procurement, they don’t have one. They’re going to invent it during your project, with all the surprises that implies.
Another red flag: no test or sandbox environment. If the first time your data lives in the new system is also the first time staff start using it, you’ve removed your only opportunity to spot problems before they become real ones.
The phrase “we’ll provide training” can mean many different things. Some of them are useful. Many aren’t.
What good looks like: a training plan structured by role and sequenced over time. Administrators and core leads first, because they need the deepest understanding. Wider user groups in waves, focused on the specific tasks they’ll actually do. Documentation staff can refer back to. A pilot group that goes live first and helps refine the rollout for everyone else.
The red flag. A single-session, all-users, everything-at-once approach. If the training plan is “we’ll run a two-hour Zoom session for your whole team,” your staff aren’t being trained, they’re being introduced. The two are very different things.
Another red flag: training that’s purely product-focused, with no attention to the school’s actual workflows. A registrar doesn’t need to know what every button does. They need to know how to do their job in the new system. Good training is built around the second question.
Go-live week is the moment of truth. It’s when the system is in real use, by real staff, under real pressure. It’s also the moment when the gap between a structured provider and a hands-off one becomes painfully obvious.
What good looks like: real-time availability during launch week. Defined escalation paths if something goes wrong. Scheduled check-ins in the first few weeks, not just whenever the school happens to email. A formal handover from the implementation team to long-term account management, with the new team properly briefed on your school’s setup.
The red flag. A go-live plan that consists of “we’ll be on email if you need us.” Email is not a support strategy for the most volatile two weeks of the project.
Another red flag: a complete handover to “general support” the day after go-live, with no continuity between the people who implemented the system and the people you’ll be working with afterwards. The institutional knowledge of how your school is set up shouldn’t have to be re-learned by a new team.
The good news is that all of this is testable before you sign. You don’t have to take anyone’s word for it. Three things to do during evaluation.
First, ask for a sample implementation plan. Not your customised one, just an example of how they typically structure a project. If they can hand it over readily, they have one. If they fudge or promise to send it later, they don’t.
Second, ask to speak to a recent customer about their implementation specifically. Not a feature reference, an implementation reference. The questions to ask: was the timeline accurate? Was the named contact actually accessible? Did go-live go smoothly? Did they feel supported afterwards? Those answers tell you more than any sales conversation will.
Third, watch how the provider behaves during the sales process itself. Are they responsive? Do they answer specific questions specifically, or with general reassurance? Do they meet the commitments they make about meeting times, follow-up materials, and timelines? Implementation is a project. Sales is a smaller project. If a provider doesn’t run the small one well, the big one is unlikely to go better.
The shorthand version is this. You’re looking for a provider who treats your implementation as a project they’re running, not a transaction they’re processing.
The signs of the first kind: specific people, specific plans, specific timelines, specific commitments. The signs of the second kind: vague reassurance, generalised statements about “great support,” and an unwillingness to talk in detail about what week three actually involves.
We’ve put together a full guide on how to run a structured switch, including more on the procurement and implementation side, what good looks like across all five phases of the project, and how to set up the partnership for the long term.
The schools that switch well tend to be the ones who asked harder questions before signing. That’s the bit nobody regrets putting effort into.
