Moving a school across without losing a term
Changing student systems is disruptive in a way that changing most software is not — the data is irreplaceable and the calendar does not pause. Six stages, sequenced around your school year rather than ours.
We look at what you already have
Every school arrives with history — a previous system, a set of spreadsheets, or both. The first stage is establishing what data exists, what condition it is in, and what actually needs to move. Schools are usually surprised by how much duplication surfaces here.
- Student records, current and historic
- Existing assessment data and report formats
- Class, section and timetable structure
- Parent and guardian contact records
Data is migrated and checked against itself
Migration is not a single import. Records come across, then get reconciled — sibling links, duplicate families, students who appear twice under slightly different spellings. The check matters more than the load, because errors carried in at this stage stay for years.
- Student records imported with historic data retained
- Duplicates and near-duplicates surfaced for review
- Sibling and family links reconstructed
- A reconciliation report you sign off before going further
Your structure is configured, not assumed
Grading scales, report cycles, assessment points, house and section structures differ between schools even on the same curriculum. These are set up to match how your school already reports, rather than asking staff to adopt a template.
- Assessment model configured to your curriculum
- Report cycles and marking periods set per year group
- Roles and permissions mapped to your actual staff structure
- Class, section and house structures built out
Modules go live in the order that suits your calendar
Not every module needs to launch at once, and for most schools that would be the wrong choice. Admissions before an intake season, attendance from a term boundary, assessment ahead of a reporting cycle — sequencing follows the school year rather than the project plan.
- A launch order agreed against your term dates
- Each module confirmed working before the next begins
- Parallel running where a clean cutover is not sensible
Staff are trained by role, not in one large session
A form tutor, an admissions officer and a head of year use entirely different parts of the system. Training is delivered by role so people learn the part they actually touch, which is the difference between adoption and a system everyone avoids.
- Separate sessions for teaching staff, admin and leadership
- Written guides kept for staff who join later
- A named contact during the first weeks
You complete a full reporting cycle
The implementation is not finished when the data is loaded — it is finished when a full reporting cycle has run end to end and the reports produced are ones the school is willing to send to parents. That is the point at which the system is genuinely in use.
- A complete assessment and reporting cycle run through
- Report output reviewed before it reaches families
- Any adjustments made while support is still hands-on
What we ask from your side
Implementations stall for predictable reasons, and almost all of them are about availability rather than technology. Three things make the difference:
One decision-maker
Someone who can settle questions about grading scales and report formats without a committee. These questions arrive constantly during configuration.
Access to your current data
Exports from the existing system early, not at the end. Data condition is the single biggest variable in how long migration takes.
Time from the people who will use it
A few hours from an admissions officer and a head of year during configuration prevents weeks of rework after launch.
Talk through your own migration
Bring the system you are on now and the term dates you are working around. We will be straight with you about what is realistic.