“How long is this going to take?” is usually the second question a school asks when it starts thinking about switching providers. The first is “is it actually worth it?” Once that’s been answered, the next worry is always time.
The short answer, for most schools, is shorter than you’d think.
The active implementation, from vendor selected to system live and stabilised, typically runs 30 to 90 days. If you include the work that happens before vendor selection, you’re looking at three to five months end to end.
Most people, when we tell them this, don’t quite believe it. They assume a year. They assume disruption. They assume their school is somehow uniquely complicated. That disbelief is doing real damage, because it’s the reason a lot of schools never start.
So let’s walk through what actually happens, in roughly what order, and why the timelines are what they are.
The numbers below are realistic for most international and independent schools. They aren’t a guarantee. Three things shift them either way: how clean your existing data is, how decisively your team can answer configuration questions, and how organised your chosen provider is.
A school with tidy data, a named project lead, and a provider that runs disciplined implementations can be live in around 60 days. A school with messy data, no clear owner, and a provider that improvises can take twice that or more. The framework is the same. The variables are local.
Roughly two to four weeks.
This is the work that happens before you talk to any vendor seriously. It’s not glamorous, but it’s the phase that determines almost everything that follows.
You’re doing five things. Naming the person who owns this project (one person, not a committee). Mapping your existing workflows so you actually know what you have. Auditing your current data so you don’t migrate junk into a clean system. Agreeing what success looks like, in language specific enough to measure. And lining up your timeline with your academic and fiscal cycles so you’re not asking your team to go live during exam week.
Schools that skip this phase pay for it later. Schools that take it seriously often discover that half the problems they thought were “system problems” were actually process problems, and the new tool will inherit them unless they’re sorted first.
Roughly two to four weeks.
Once you know what you need, you can have meaningful conversations with vendors. This phase is shorter than people expect, partly because the work from phase one cuts most of the noise.
You’re running demos, asking specific questions, checking integration requirements, talking to schools that already use the platform. By the end of it, you’ve signed, and the provider has handed you a milestone-driven project plan with named contacts on both sides.
What slows this phase down is doing it without phase one. If you’re trying to evaluate vendors before you’ve clarified your own requirements, every demo feels equally good, every conversation goes in circles, and the decision keeps getting deferred. The clarity you bring into the room is what makes the procurement quick.
Roughly two to six weeks.
This is the heaviest technical phase, but it’s also the one where almost nothing changes for the wider staff. Configuration is happening in the background. The current system is still running. Day-to-day life carries on.
The work here is data mapping (what fields live where, what gets imported, what gets archived), role and permission setup (who sees what), workflow configuration (the bits specific to your school), integration setup where it applies, and sandbox testing so the project team can poke at the system before anyone else sees it.
This phase varies the most in length. Clean data and decisive answers can compress it to two weeks. Tangled legacy data and a hundred edge-case questions can stretch it to six. A good provider will give you clear data preparation requirements early, so this isn’t a surprise.
Roughly two to four weeks.
Effective training is role-based and phased. Nobody learns a new system by drinking from a firehose.
You start with administrators and core team leads, who need the deepest understanding. Then you bring in the wider user groups in waves, focused on the specific things they need to do rather than a comprehensive system tour. A registrar doesn’t need to know how the boarding module works. A boarding supervisor doesn’t need to know the finance reconciliation flow.
When training is sequenced like this, confidence builds quickly. Resistance is almost always about uncertainty, not difficulty. When users understand both why the change is happening and how the support around them is structured, they get on with it.
Roughly two to four weeks post-launch.
Go-live is the start of structured adoption, not the end of the project. The system switches on, the team starts using it for real, and the first few weeks are spent ironing out the small things that only surface in actual use.
A good provider stays close during this stretch. There’s a defined launch date, real-time support availability for the first few weeks, scheduled check-ins, and a formal handover from the implementation team to long-term account management. The school should feel surrounded, not abandoned.
If a provider treats go-live as a finish line and disappears the day after, that’s the kind of thing you want to find out before you sign, not after.
The most common objection we hear isn’t about whether to switch. It’s about timing.
“We can’t do this mid-year.” “We’re heading into enrolment.” “We’ve got an inspection in March.” Every school has a reason that the next six months are the wrong six months.
Here’s the honest version. There’s almost never a perfect window. But there are sensible windows, and they’re easier to find than people think. Most schools time their go-live to coincide with the start of an academic year, the start of a new term, or the start of a fiscal cycle, depending on what’s switching. Admissions tools often go live in the autumn before the next intake. Curriculum tools tend to go live at the start of the academic year. Finance tools often go live at the start of the fiscal year.
The planning and configuration phases happen in the months before, while the current system carries on doing its job. The visible change happens at a moment that’s already a natural reset for everyone.
If the timing genuinely doesn’t work, it’s worth saying out loud. But most “we can’t right now” conversations turn out to be “we can, just not next month,” and that’s a planning problem, not a blocker.
Three questions will get you to a reasonable estimate.
How clean is your existing data? If you’d be comfortable sending a sample to a stranger without apologising for the state of it, you’re in good shape. If not, add a week or two to phase three.
How clear is your internal ownership? If one person can already answer “who’s running this?”, you’re set. If not, your real timeline starts after that person is named.
How structured is the provider you’re considering? Ask them, in the first conversation, to walk you through a typical implementation plan. If they can describe it confidently, with named roles and milestone check-ins, you’re looking at the lower end of the range. If they’re vague, you’re looking at the higher end, plus a fair amount of stress.
The thing about timing is that the calendar isn’t going to clear itself.
If your school is already past the point where the current setup is costing you time, money, or clarity, the right question isn’t “when’s the perfect moment to switch?” It’s “what’s the earliest point at which we can run this properly?”
We’ve put together a full guide on how to do exactly that. It covers the five-phase framework in more practical detail, the questions to ask a provider during procurement, and what good implementation support actually looks like.
The schools that handle this well aren’t the ones who found a magical clear quarter. They’re the ones who picked a sensible window, named an owner, and got on with it.
