Pick the boundary,
then count backwards.
A school year has natural seams, and a cut-over that lands on one inherits a clean start. Between terms, no register is half-complete, no course has been invoiced under one system and delivered under another, and no family is holding a receipt the new platform has never heard of. The same change made in week six has to reconcile all three by hand, in the weeks the office has least room, and the reconciliation is what people remember about the migration years afterwards.
So the date is not "when we are ready". It is the next boundary you can reach without rushing, worked out by counting backwards through the sequence below. If the export, the rebuild, the import and a fortnight of staff practice do not fit before the next one, take the one after. Nothing is lost by running another term on the old system, and a great deal is lost by arriving at the first week of term with a timetable that is half-built. This is the single most common way a competent school makes a mess of a sound decision.
Seven steps,
each in its place for a reason.
Two of these are worth expanding. Step three before step four is not a preference, it is a dependency: students are enrolled into classes, so the classes have to exist first. In SprintUp the student import takes a file with a name and an email column and can enrol everyone in it into one class as the accounts are created, which is a good reason to import class by class rather than in a single file of everyone — the enrolment comes free, and a failure tells you which group to look at. Your plan's student limit is checked once for the whole file before any account is made, so an import that is over the cap stops at the start rather than leaving you half-done.
Step five is a person, not an import. The list of who currently owes what is short, it is real money, and it is the one thing you should not trust to a file. Print it, carry it across by hand, and have two people check the total against the old system before anyone raises an invoice in the new one. The arrears article covers what to do with the balances once they are there.
One message, late,
after staff can answer it.
Families do not care which platform a school uses and should not be asked to. What they care about is whether they will lose access to something, whether they have to do anything, and who to ask if it goes wrong. So the announcement is short, it comes after the staff dry run rather than before it, and it answers those three questions in that order. Announcing a fortnight early produces a fortnight of questions nobody can answer yet, which converts a routine change into a source of anxiety.
Keep the work on your side of the line. If families need a new login, send it at the moment it works, with one link, and expect to resend a proportion of them however well you write it. Do not ask parents to re-enter details you already hold; you are migrating so that they do not have to. And name a person, not an inbox — the parent who cannot get in on the first evening wants to know who is fixing it.
Rollback is partial.
Say so in advance.
It is tempting to reassure everyone that you can simply go back. You can, up to a point, and it is worth being clear where that point is before you cross it rather than discovering it in the middle of a bad week.
The line falls at money and at communication. Once a family has paid through the new system, that payment is a fact in your accounts and should stay where it was raised — invoices are retained even where a person is later erased, because accounting law requires it, and no platform can honestly offer otherwise. Once families have been told, the change is social as much as technical. Everything before those two lines is genuinely reversible, which is the argument for keeping the announcement and the first payment run as late in the sequence as you can.
And keep the old system readable for a year, on the cheapest plan it offers or as an archive you exported. It costs little and it is the difference between answering a question about last March in two minutes and not being able to answer it at all.
Three things to watch,
and one to resist.
Watch the registers on day one: if a class has no attendance marked by the end of its first session, the problem is not the software, it is that nobody knows whose job it is now. Watch the first invoice run end to end, from raising to the money arriving, before you assume billing is fine — most billing problems only appear at the moment of collection. And watch the first parent question: how long it took to answer tells you more about the migration than any dashboard.
What to resist is redesigning the school while you are at it. A migration is the moment when everyone remembers a process they always wanted to change, and doing both at once means that when something breaks you will not know whether it was the platform or the new policy. Move first, keep the way you work as close to identical as the new product allows, and make the improvements a month later, deliberately, one at a time.