The most common reason schools defer a software switch isn’t disagreement about whether to do it. It’s disagreement about when.
Term’s already started. Inspection’s coming up. The enrolment cycle is in full swing. The board meets in a month. We can’t possibly do this right now.
These are all real considerations. Schools run on cycles, and dropping a major change into the wrong part of the cycle is genuinely disruptive. But “not right now” can quietly become “not this year,” which can quietly become “we keep meaning to look at this.”
There isn’t a magical window where everything goes quiet. There are, however, sensible windows for different kinds of system, and there are honest answers about when mid-year is fine and when it isn’t. This piece is about picking the right window rather than waiting for the perfect one.
The timing question is harder than it looks because it’s actually three questions wearing the same coat.
The first is: when can we afford the planning bandwidth? Implementation projects need attention, especially from the leadership team and the people running the workflows being changed. If that bandwidth doesn’t exist for the next six months, you’re not ready, regardless of what the calendar says.
The second is: when will the go-live moment cause the least disruption to staff and students? This is the bit most people focus on, and it’s the most concrete. Going live the week before exams is bad. Going live during the start-of-term staff briefings is good.
The third is: when’s the cleanest data handover point? Some systems naturally reset at certain moments. Admissions cycles end. Academic years close. Fiscal years roll over. Migrating around those natural boundaries is much simpler than migrating in the middle of an active dataset.
The hardest part is that those three questions sometimes point at different windows. Leadership bandwidth might be best in February. The cleanest data handover might be in August. Go-live disruption is lowest in September. Picking a window means weighing those against each other, not waiting for them to align perfectly.
Different systems have different natural windows. The most useful thing you can do early on is map your switch to its actual cycle, rather than treating “school timing” as one big undifferentiated thing.
The natural window is the autumn before the next admissions cycle starts in earnest. That gives you time to configure, train, and pilot before applications start arriving for the following year.
What you want to avoid is switching mid-cycle, with live applications in flight. Migrating half-completed applications, partial communication threads, and active workflows is technically possible but unnecessarily painful. Wait for the cycle to close.
For an SIS, the cleanest moment is the summer between academic years. The previous year’s data is closed. The new year’s enrolments are finalising. Staff are mostly off-site, which means training in the final weeks before term tends to work well.
The trickier version is when an SIS needs replacing mid-year because the existing one is genuinely failing. In that case, the question shifts to: what’s the next natural pause? A half-term break can work. The Christmas-to-January window can work. The point is to find a moment where running parallel systems for a week or two won’t break things.
Start of the academic year, almost always. Curriculum tools are deeply tied to how teachers structure their year, and asking them to change mid-year while they’re already mid-flow is the kind of thing that creates resistance you didn’t need to invite.
For IB schools specifically, the rhythm tends to be: configure over the summer, go live for the start of the new academic year, with the first round of reporting running through the new system from term one.
Finance is the one system that’s pegged to a different calendar. Most schools time finance switches to the start of the fiscal year, regardless of where that sits in the academic calendar. The reasons are practical: clean year-end close on the old system, fresh ledger on the new one, no awkward mid-year reconciliation.
This is also the case where “we’ll do it in summer” sometimes turns out to be wrong. If your fiscal year starts in April, April is your moment, not August.
These are the most flexible. Operations tools (transport, activities, communications, parent engagement) can usually be switched at the start of any term, or even mid-term, with relatively little disruption. The data is less interconnected with academic cycles, and the day-to-day workflows are easier to transition in waves.
If you’re switching one of these, you have more freedom than you think. The question becomes less “when’s the right moment?” and more “when can we run the project properly?”
The reflexive answer to “can we switch mid-year?” is “no, wait for summer.” That’s usually wrong.
Mid-year switching is fine, sometimes even sensible, in three scenarios.
The first is when the current system is failing badly enough that the cost of waiting outweighs the disruption of switching. If your registrar is spending six hours a week working around the existing tool, summer is too far away.
The second is when the new system can go live alongside the old one, with a defined cutover point. Many systems support a parallel run period where the new platform is configured and validated while the old one carries on. The visible switch happens at a planned moment, often a half-term break or the end of a reporting cycle.
The third is when the system you’re switching isn’t tightly bound to the academic calendar. Operations, communications, or activities tools fall into this bucket. The decision to wait six months for “the right moment” is often unnecessary caution.
Where mid-year switching genuinely doesn’t work: a major SIS or curriculum platform change in the middle of an active reporting cycle, or anything that requires significant staff training while teachers are already at full capacity. Those genuinely need the summer or a term boundary.
There’s a pattern we see often enough to name. A school identifies a problem with its current system. The conversation about switching starts. A few weeks later, an objection surfaces: the timing isn’t right. Six months pass. The conversation restarts. Same outcome. Another six months pass.
What’s happening here is rarely a real timing problem. It’s almost always something else dressed up as one. The decision feels too big. Nobody wants to own it. The current system, however imperfect, is at least familiar.
The diagnostic question is straightforward. If you had to switch in the next 12 months, when in that window would be best? If the answer is “March, but only if we start planning in November,” that’s a plan. If the answer is “honestly, I don’t know,” that’s a different problem, and it isn’t about timing.
The schools that handle this well treat the timing question with the same seriousness as the rest of the decision, but they don’t let it become a permanent excuse. They pick a window, even an imperfect one, and they work backwards from there.
Three steps will get most schools to a good answer.
First, identify the natural windows for the specific system you’re switching. Use the categories above as a starting point. The right window for an SIS is different from the right window for a finance tool.
Second, work backwards from the go-live moment to figure out when planning needs to start. Most full implementations run three to five months from kick-off to stabilisation. So if you want to go live at the start of the next academic year, you’re starting the project four to five months earlier. If that puts you in a busy stretch, that’s important information, not a deal-breaker.
Third, sanity-check the timing against your leadership bandwidth. The project will need an owner, regular decisions, and engaged senior involvement. If the months between now and go-live are unusually demanding for other reasons (inspection, leadership transition, capital project), factor that in. Sometimes the right move is to wait a term and start fresh.
The honest answer for most schools is: sooner than they think.
If you’ve already had the “we should look at switching” conversation more than once, the timing concern is probably doing more work as a delay mechanism than as a real planning constraint. The natural windows for most systems are predictable. The implementation timeline is predictable. The bandwidth question is answerable.
We’ve put together a full guide that covers timing in more depth, alongside the five-phase framework for running a switch, what to look for in a provider, and how to set the project up for long-term success.
The schools that switch well aren’t the ones who found a perfect six-month window of calm. They’re the ones who picked a sensible one, prepared properly, and got on with it.
