Rollout walkthrough
A school replacing an incumbent platform
How a replacement differs from a first rollout: the data is better, the exit is harder, and the staff have opinions.
What this is, and what it is not
This is a composite, not a customer story. It describes how a rollout typically goes for this kind of school, drawn from implementation experience across several. No school is named, no figures are attributed to a customer, and nothing here is presented as a measured outcome. Named case studies appear on this page only with written consent and stated measurement methods, and none are published yet.
The school described: Already running a school ERP, moving because of cost, support, or a capability the incumbent will not deliver.
Starting position
What brings a school like this to look for a platform
The presenting complaint and the underlying condition are usually different things, and the difference decides the sequence.
Unlike a first rollout, the data is already structured. That is a genuine advantage and it comes with a specific risk: structured data carries the incumbent’s model, including decisions made years ago by someone who has left, and importing it faithfully means importing those decisions too.
The harder problem is exit. What you can extract from the incumbent, in what format, and within what notice period is often unclear until you ask formally. Schools routinely discover that the export they assumed was available is a report rather than a data extract, or that historical academic records are viewable but not extractable.
The third difference is human. Staff have used a system for years. They know its workarounds, they have built local processes around its limitations, and some of those workarounds now look like requirements. Distinguishing a real requirement from an inherited workaround is most of the configuration work.
Sequence
What moves when, and why that order
Each phase states the reason it cannot sensibly come earlier or later. The reason matters more than the phase, because your school will need a different order for at least one of them.
- Before notice is servedStep 1
Establish what you can actually extract
Request a full data export from the incumbent in writing and inspect what arrives. Specifically check historical academic records, fee history, guardian relationships, and document attachments.
Why here: Notice periods and contract end dates are fixed. Discovering after notice that historical results are not extractable leaves you choosing between running two systems and losing records you may be legally obliged to retain.
- EvaluationStep 2
Separate requirements from inherited workarounds
Inventory the local processes built around the incumbent. For each, decide whether it is a requirement of your school or an accommodation of your old software. Do this with the people who perform them.
Why here: Configuring a new platform to reproduce old workarounds is the most common way a replacement ends up no better than what it replaced, and it is usually done with the best intentions by people trying to minimise disruption.
- Term oneStep 3
Import and reconcile, not just import
Load students, guardians, staff, and fee positions, then reconcile counts and balances against the incumbent while you still have access to it. Verify a sample of historical academic records end to end.
Why here: Having both systems available simultaneously is a window that closes. Reconciliation is cheap while it is open and effectively impossible afterwards.
- Term one to twoStep 4
Configure to the school, then retrain
Configure permissions, fee rules, and assessment to your policy rather than to the incumbent’s shape. Retrain deliberately, acknowledging that staff are being asked to unlearn something they were good at.
Why here: A replacement asks experienced staff to become beginners again. Rollouts that skip this framing get resistance that looks like a software objection and is actually a competence objection.
- Before the incumbent contract endsStep 5
Retention and archive
Confirm what you are obliged to retain and for how long, extract it, and store it somewhere you control. Verify you can produce a transcript for a former student from the new platform or the archive.
Why here: This is the obligation that outlives the vendor relationship, and the one most likely to be discovered as unmet when a former student requests a document two years later.
Friction
What reliably goes wrong
Not risks in the abstract. These are the things that recur, so they can be planned for rather than discovered.
The export is a report
Many platforms offer reports rather than data extracts. A PDF of a mark sheet is not migratable academic history. Ask for the extract specifically and inspect the file before relying on it.
Permissions imported wholesale
Incumbent permission models accumulate exceptions, usually administrator rights granted as a temporary workaround. A replacement is the one clean opportunity to design permissions properly. Reproducing the old model wastes it.
Two systems, one term
Overlap is necessary for reconciliation and dangerous for data entry. Be explicit about which system is authoritative for each workflow on each date, in writing, visible to staff.
Confidence that the second time will be easy
Schools that have done this before often under-resource it, reasoning that they know how now. The data is better and the human change is harder. Net, it is not faster.
Limits
What a platform does not fix for this school
Stated because the alternative is a school discovering it in term two.
- It does not extract data the incumbent will not release. Where an export is unavailable, the options are a manual rebuild or an archive of documents, and both are your work rather than ours.
- It does not decide which inherited workarounds were requirements. That judgement needs the people who do the work.
- It does not remove the retention obligation for records held in the old system.
- It does not shorten the incumbent’s notice period or reduce the cost of overlap.
A school replacing an incumbent platform: common questions
What schools in this position ask before committing to a sequence.
Is a replacement easier than a first rollout?+
The data stage is easier and the human stage is harder. Structured data imports more cleanly than spreadsheets, but experienced staff are being asked to give up fluency, and inherited workarounds have to be examined one by one. Budget similar total effort, distributed differently.
How much overlap between systems do we need?+
Enough to reconcile counts and balances and to verify a sample of historical records, which is usually weeks rather than months. Longer overlap increases the risk of divergent data entry, and the authoritative-system-per-workflow rule matters more than the duration.
What if we cannot get our academic history out?+
Establish this before serving notice. If extraction is genuinely unavailable, you are choosing between a manual rebuild, a document archive, and retaining read-only access to the incumbent. All three are worse than knowing early, which is why this is the first task rather than a later one.
Do you help with the migration from the incumbent?+
We import what you can supply and tell you plainly what we cannot map. We have no permissioned migration evidence from any named vendor, so we do not claim experience with a specific incumbent’s export format unless you send us the file and we say so afterwards.
Go deeper
Related planning material
Describe your own starting position
Tell us what your data looks like and which term you need to be live in. We will tell you what is realistic, including when the answer is not this year.
Already using Schoolyi? Sign in