Migration

The demo is not the risk. This is.

No-one in this market was burned by a bad demo. They were burned by a migration that summarised twelve years of records into a spreadsheet and called it done. Here is how ours runs, and what it will cost you in staff time.

What goes wrong.

Not a list of our strengths. A list of the four failures that make schools regret switching, all of which we have seen or been told about.

History gets summarisedAttendance and assessment arrive as totals, with the underlying records dropped. Two years later somebody needs the actual roll from a specific day for a legal request, and it is gone.

The old licence never diesNo-one quite trusts the migration, so the previous system is kept running "just in case", and the school pays twice, indefinitely.

Silent mapping failuresA field that had meaning in the old system lands somewhere plausible in the new one, and no-one notices until the census does not reconcile.

Cutover in the wrong weekGo-live scheduled to suit the vendor, landing beside reports, the census, or the start of term.

You will migrate anyway. The only question is who picks the date.

Schools tend to treat a migration as something they might choose to do. In practice it is something that happens to them, on someone else’s schedule, for reasons that have nothing to do with whether the current system still works.

DeploymentDesktop clients and on-premise servers are being retired across the category. When your vendor moves you to their cloud version, that is a migration, with a data model change, retraining and a cutover weekend, whether or not the invoice calls it one.

Security postureThe bar rises on a schedule you do not set. Phishing-resistant sign-in, access control below the module level, queryable audit, stated data residency, and the Children’s Online Privacy Code from 10 December 2026. A system that cannot meet a requirement has to be replaced by the date the requirement lands.

IntegrationEach tool your school adds, the LMS, the consent app and the wellbeing platform, assumes the record can be read programmatically. A system without a usable API eventually stops being the centre of the school and becomes a thing other systems work around.

Vendor strategyOwnership changes, portfolios get rationalised, products reach end of life. You are told when the decision has already been made, and the timeline is theirs.

A migration you plan for the December break is a different event from one you are given nine months’ notice to complete. Same work, different amount of choice.

We are not arguing you should move now, or to us. We are arguing that “we will deal with it when we have to” is a decision to hand the timing to somebody else, and the timing is most of the risk.

How it runs.

Six phases. You validate before anything is committed, and you can stop at the end of phase three with nothing lost but time.

Discovery

We take a full extract of your current system and read all of it. You get a written report of what we found, including the fields we cannot map and the data that is already inconsistent in your existing system. Most schools learn something here.

Us
[DURATION]

Trial migration

A complete migration into a private environment that is yours to break. Real data at real volumes.

Us
[DURATION]

Your validation

Your registrar, business manager and a head of house check their own records against the old system, using a checklist we provide. This is the phase schools skip and should not. Nothing is committed until you sign this off.

You
[DURATION]

Correction and re-run

We fix what validation found and migrate again from scratch. Repeated as many times as it takes; we do not charge per run.

Us
[DURATION]

Cutover

A final delta migration over a weekend or a break. Both systems readable, one system writable.

Both
[DURATION]

What comes across, and what does not.

Every vendor promises a clean migration. This is the table that makes the promise checkable. It is written against the general case; your discovery report names the specifics for your system.

Data	Detail	Result
People and relationships	Students, staff, parents, alumni, households, guardianship, siblings, emergency contacts.	Comes across
Enrolment history	Application through withdrawal, dated and reasoned. The spans the census and attendance rates derive from.	Comes across
Attendance	Per-day and, where your system held it, per-period. Code sets are re-mapped to your state’s current set, and the mapping is published to you.	Comes across
Assessment and reports	Marks and published report PDFs migrate. Markbook structure , with its weightings, custom scales and calculated columns, frequently does not survive, because the two systems compute differently.	With caveats
Wellbeing and medical	Entries, conditions, action plans, with their confidentiality tier preserved. Where your old system had one wellbeing permission, we will ask you to assign the tiers yourself.	With caveats
Documents	Files attached to people, with type and retention class where recorded. Where retention class was never set, they arrive unclassified and we tell you how many.	With caveats
Family and fee-payer data	Who pays, split percentages, sibling discounts, scholarship flags. The ledger itself stays in your finance platform.	Comes across
Free-text with no structure	Notes fields used as improvised databases, holding a decade of conventions no schema describes. These land in a searchable notes field. Searchable is not the same as queryable, and we will not pretend otherwise.	Not structured
Custom reports and templates	Report writer definitions from the old system do not migrate. They are rebuilt, and in Kestrel most of them stop being necessary.	Does not migrate
Third-party bolt-ons	Data held in a separate CRM, consent tool or boarding app is a separate migration with its own discovery.	Separate exercise

If a row here matters to you and lands in the wrong column, that is a reason not to buy from us. We would rather you knew now.

Send us an export and we will tell you which of those rows lands in the wrong column for your school. You will know before you shortlist.

Ask about your data

You should be able to stop paying your old vendor.

A migration that leaves the school running two systems has not finished. The archive is a read-only copy of your previous system’s data, hosted by us, searchable by your staff, with no per-seat licence. It exists so that the answer to “can we turn the old one off?” is yes.

Who does the work, honestly.

The phase table above names an owner for each step. The part schools underestimate is phase three.

What we doExtract, map, migrate, re-run, archive. Each run is ours, and re-runs are not chargeable.

What you doValidation. Roughly [HOURS] across your registrar, business manager and one head of house, concentrated in phase three. We provide the checklist; we cannot provide the judgement about whether a record looks right.

What it costsMigration is included. It is not a professional-services line item, because a vendor who profits from migration has the wrong incentive about how hard it is.

When to switch.

The Australian school year decides this. Two windows work and the rest do not.

BestCutover in the December–January break, with discovery and validation running through Term 4. A clean year boundary means enrolment spans, attendance rates and the next census all start in one system.

WorkableA mid-year break, accepting that the August census will draw on both systems and needs care.

AvoidAnything within six weeks of reports, the August census, or the start of a term. We will say no to these dates even if you ask.

If it goes wrong.

Through phase three, nothing has changed in your live system and stopping costs you the time you have spent. After cutover, your previous system remains readable and we hold a restorable point from the moment before the delta ran. We will tell you within one business day if we believe a migration should not proceed, including when the reason is us.

Ask us what will not come across.

Forty minutes. Bring the person who remembers what is in the notes fields.

Book a walkthrough