A weekend cut-over
assumes you were right.
The appeal of moving everything at once is that it is over quickly and nobody has to hold two ideas in their head. The problem is that it stakes the whole school on the assumption that the evaluation was correct — that the product does what the demo suggested, that your staff can use it under pressure, and that the parts nobody demonstrated work too. Evaluations are good at features and poor at friction, and friction is what actually decides whether software gets used. You find it in week three, with real classes.
A parallel term changes the question from "was our judgement right?" to "what do we now know?". One group runs on the new platform. Everything else carries on as it was. If the product turns out to be wrong for you, the damage is one group's administration for one term, recoverable in an afternoon, rather than a school that cannot produce a register or an invoice in the week a parent asks. That is what you are buying, and it is worth being explicit that it is insurance, because insurance always looks expensive to anyone who has not yet had the accident.
Representative, contained,
and run by a sceptic.
The pilot group has to be small enough that a mess is survivable and typical enough that what you learn transfers. A single level, one site, one programme, or one age band works well. What does not work is the group everyone considers easiest, because a system that handles your most straightforward classes teaches you nothing about the ones that actually consume the office's week — the group with rolling enrolment, the one with three make-up lessons a fortnight, the family paying in instalments.
Pick the teacher deliberately too, and pick one who will tell you it is bad if it is bad. Enthusiasts are the wrong choice: they work around problems without mentioning them, and you will only learn what they concealed when the whole school hits the same wall. A competent sceptic who likes their existing routine is the best instrument you have. Ask them to keep a note of every moment they had to think about how to do something, which is a better record than a satisfaction score and takes less time to produce.
On cost: a pilot should not need a purchase. Most platforms have a free tier or a trial that will carry one class, and ours does — one educator and ten students at no charge — so a school can run a genuine small pilot before any money changes hands. If a vendor will not let you try the real product with real students before committing, treat that as an answer in itself.
Every kind of data
has exactly one home.
Parallel running fails in exactly one way, and it is always the same one: the same fact gets maintained in both systems, the two versions drift, and then nobody can say which is right. The cure is a single rule, written down before the term starts and visible to everyone who touches either system — for each kind of data, one system is authoritative, and the other is not updated at all.
The hardest line to hold is the second one, because a cautious administrator will keep a paper register "just while we settle in", and within a fortnight the paper is the real record and the new system is a chore people perform afterwards from memory. That is not a pilot; it is double work producing worse data. If the new system is trusted enough to run a group, it is trusted enough to be the only register for that group. If it is not, do not pilot it yet.
Contacts deserve their own mention. Families change phone numbers mid-term, and if a change is typed into the new system it will be lost when you eventually import from the old one, or worse, it will silently overwrite a good value with a stale one. Keep changes flowing into the old system until cut-over and re-import.
More hours, not fewer.
Count them honestly.
It would be easy to present a parallel term as the cheap option. It is not. You are running two products, teaching staff a second way of working, rebuilding a slice of your structure, and reconciling at the end. The reason to do it is risk, not effort, and a school that goes in expecting it to be effortless will abandon it halfway, which is the worst of the available outcomes.
Count four things before you start, in hours, at your own numbers: rebuilding the structure for the pilot group, importing and checking its students, the weekly overhead of the person who holds both systems in their head, and the reconciliation at cut-over. The last is the one people forget and it is rarely small. Add those hours to the price of the software when you compare vendors — they are as real as the subscription, and the total cost article explains why they belong in the same number.
Four signals,
one of which means stop.
Decide the abort criterion before the term begins, while you are still calm, and write it down. Something like: if at half-term the pilot group's register is incomplete, or the teacher would rather go back, we stop and return that group to the old system. Having the sentence in advance is what makes abandoning a bad choice a decision rather than an admission, and it is the reason a pilot is safe to attempt at all. A school that cannot say what would make it stop has not run a pilot, it has begun an irreversible migration with fewer students.
The happier signal is the first row, and it is quieter than you expect. Nobody announces that the software is working. They simply stop asking, and the questions in the staffroom move on to something else.