Student Data Migration: What Actually Goes Wrong
Migrations rarely fail on the import. They fail on everything that was already wrong in the data, discovered halfway through, when the calendar has stopped being negotiable.
Migrations rarely fail on the import. Loading records into a new system is the straightforward part and it is usually finished early. What overruns is everything that was already wrong in the data — discovered halfway through, at the point the academic calendar has stopped being negotiable.
Here is what actually goes wrong, roughly in the order schools encounter it.
The data is in worse condition than anyone believed
Almost every school underestimates this, and not through carelessness. The problems are invisible in daily use because staff work around them without noticing:
- Duplicate students. The same child under two spellings, or created fresh on return after a year away. Each duplicate quietly breaks every report that counts students.
- Unlinked siblings. Three children of one family as three unrelated records, which is why the same passport gets requested three times.
- Inconsistent date formats. Especially where data has passed through spreadsheets, where a date of birth can silently become a different date entirely.
- Free-text where structure was needed. Nationality, year group or status typed rather than selected, producing eleven spellings of the same value.
- Orphaned history. Assessment attached to a class that no longer exists, so it disappears when the class does.
None of these prevent a school running. All of them surface the moment data is moved somewhere that expects consistency.
Nobody decided what “done” means
A migration without an agreed definition of complete will expand indefinitely, because there is always one more field someone would like brought across.
Decide, before starting, which of these you are doing:
- Current students only, current year only — fastest, and loses the ability to show progress.
- Current students with full history — the usual right answer.
- Current and former students with full history — necessary if you field records requests for leavers, which most schools do.
The third option is more work and is frequently the correct choice. A request about a student who left four years ago is not unusual, and answering it from a decommissioned system nobody can log into is considerably worse than migrating the data now.
The reconciliation step gets skipped
This is the single most common cause of a migration that appears successful and is not. Records come across; nobody checks them against each other.
Reconciliation means surfacing duplicates and near-duplicates for a human to judge, rebuilding sibling and family links, and confirming that counts match — the number of students in the new system equals the number in the old one, per year group, with the difference explained rather than assumed.
A migration should produce a report you sign off before anything else proceeds. If nobody offers you one, ask for it. Errors carried in at this stage do not stay contained; they propagate into every report built on top of them, for years.
The timeline was quoted from school size
Vendors quote from roll size because it is the number they have. It is close to irrelevant. A 2,000-student school with a clean export from a modern system migrates faster than a 600-student school with fifteen years of spreadsheets.
What actually determines the timeline is: how many source systems the data lives in, how much manual reconciliation the duplicates require, how much history moves, and how quickly the school can answer configuration questions. A vendor who assesses your data before committing to a date is telling you something useful. One who does not is guessing, and you will absorb the variance.
Configuration questions arrive with nobody to answer them
Migration is not only data movement. It requires decisions: which grading scale, how report cycles run per year group, what the permission structure looks like, which fields are mandatory.
These questions arrive constantly and they are not IT questions. If they queue behind a committee that meets fortnightly, the project stalls — not because anything is difficult, but because it is waiting. A single named decision-maker who can settle a grading-scale question in an afternoon is worth more to the timeline than any amount of technical capacity.
The cutover lands in the wrong week
Sequencing matters more than most schools expect, and the right order follows the academic calendar rather than the project plan:
- Attendance moves cleanly at a term boundary, not mid-term.
- Admissions should be live before an intake season begins, not during it.
- Assessment should never cut over mid-reporting-cycle. A half-migrated cycle is worse than an old system you dislike.
- Student records go first, because everything else attaches to them.
Not every module needs to launch together, and for most schools launching them together is the wrong choice. Our stage-by-stage rollout process sequences against your term dates for this reason.
Training was one large session
A form tutor, an admissions officer and a head of year use entirely different parts of a student system. Training everyone together means each person sits through the parts that do not apply to them and retains less of the part that does.
Training by role is the difference between adoption and a system staff avoid — and staff who avoid the system keep their own spreadsheets, which recreates the original problem inside a more expensive tool.
What a good migration looks like
- An honest audit of what exists and what condition it is in, done before any dates are agreed.
- An explicit decision about how much history moves.
- Records imported, then reconciled — with a report the school signs off.
- Configuration matched to how the school already reports, not to a template.
- Modules launched in an order that follows the academic calendar.
- Training delivered by role.
- A full reporting cycle completed end to end before the implementation is called finished.
That last point is the one worth holding vendors to. A migration is not complete when the data is loaded. It is complete when a full reporting cycle has run and the reports produced are ones the school is willing to send to parents.
If you are weighing this up, the questions worth asking before you shortlist cover what to establish before a migration is even on the table.
Frequently asked questions
How far back should historic data be migrated?
As far as you hold it, unless there is a retention policy saying otherwise. A record that begins on the migration date cannot answer a records request or show a multi-year trend, and those are the two things schools most often need years later.
Can we run both systems in parallel for a while?
For some modules, yes, and where a clean cutover would be risky it is the sensible choice. It costs more work during the overlap, so it is worth doing deliberately for specific modules rather than as a blanket approach.
Who should own the migration on the school side?
Whoever knows the data best, which is usually the registrar rather than IT. IT can move records; only the registrar can tell you whether two similar entries are the same child.
Keep reading
Running Two Curricula on One Campus
Multi-curriculum campuses are ordinary in the UAE and awkward in most software. The problem is not capacity — it is that the assessment models genuinely disagree with each other.
OperationsEvidencing Attendance and Progress in UAE Schools
Every school can produce evidence given a fortnight. The question is what you can produce on the day you are asked — and whether it holds up when someone reads it closely.
BuyingHow to Choose a Student Information System in the UAE
Most SIS shortlists are built on feature checklists, and feature checklists are where schools get caught. The differences that matter here are structural, and they only surface if you ask about them directly.
See it against your own school
A walkthrough configured to your curriculum, run by someone who can answer migration questions rather than defer them.
Book a demo