Why School ERP Migrations Fail Mid-Year — and the Only Safe Time to Move

“The system is ready” is not a cutover criterion

A school ERP can pass configuration and technical testing while the school remains unready to move. The dangerous question is, “When can the vendor go live?” The useful question is, “At what point can we stop changing the old record, prove the new one and still recover before the next irreversible school event?”

Mid-year is usually the wrong answer because almost every core object is in motion:

• students enrol, withdraw and change class;
• attendance is recorded daily and may carry safeguarding, progression or regulatory consequence;
• marks remain provisional, moderated or open to change;
• fees, concessions, receipts, refunds and transport charges continue to post;
• timetables and cover arrangements change;
• parent and staff identities drive access to other systems;
• statutory or ministry submissions depend on effective-dated populations;
• integrations keep creating downstream copies.

The migration is not one database replacing another. It is a change to the institution's official record while that record is being actively created. A missing historical address is a data defect; a missing same-day withdrawal, allergy alert, receipt or bus change can become an immediate operational incident.

The only generally safe window

There is no globally safe calendar date. School years end in different months, financial calendars vary, and some schools operate summer programmes or year-round admissions. The generally safe state is the boundary between academic years, when the old year can be frozen and the next has not yet become operationally irreversible.

The window opens only after:

• final grades and reports are approved;
• attendance and behaviour records for the old year are complete;
• leavers, graduates, withdrawals and promotions are confirmed;
• invoices, receipts, credits and agreed opening balances are reconciled;
• required returns or census snapshots are submitted or reproducible;
• the old timetable and teaching groups no longer need live changes;
• archives and retention copies have been verified.

It closes before:

• new-year invoices or direct-debit instructions are issued;
• class and timetable data provision learning platforms and access;
• parents are invited to validate profiles or use the portal;
• teachers record attendance, marks, incidents or communications;
• transport, catering, clinic, library or access-control operations rely on new assignments;
• the first required external return or ministry exchange.

The practical cutover sits between those two lists. For many schools it is part of a summer or long vacation. For a southern-hemisphere school it may be December or January. For an international school running continuous activities, it may be a short controlled outage with a separate operating process for summer students. The rule is academic state, not season.

Why mid-year migration fails

There is no clean transaction boundary

Suppose the final data extract starts Friday at 18:00 and the new system opens Monday. What happens to an online payment at 18:12, an admission accepted Saturday, an absence added by a teacher from home, or an address changed in the parent portal? If the old system remains writable, the extract is stale. If it is made read-only, every essential change needs a controlled capture-and-replay process.

At an academic-year boundary, the number of legitimate changes can be reduced and planned. Mid-year, the delta is the school.

Effective dates are flattened

School data describes relationships through time. A child did not simply belong to Year 6; they belonged to a school, year, class and timetable between dates, with changes that may affect attendance denominator, fees, reports and access.

The Ed-Fi school-calendar domain separates calendars, sessions, grading periods, calendar dates and the student-school association. That structure exposes the migration problem: copying today's value into one “current class” field loses when it became true and what preceded it.

Identity matching creates duplicates or false merges

One person can appear as applicant, student, sibling, parent, emergency contact, employee and payer. Names vary; phone numbers and addresses are shared; twins share birth dates; identifiers may have changed or be missing.

Matching only on name and date of birth can merge two people. Creating a new record whenever the match is uncertain duplicates a family and fragments balances, consent and communications. Mid-year, downstream platforms may then provision both identities.

Opening balances do not explain transactions

A student fee balance can be made to match while the underlying ledger is wrong. Migrating one net number hides invoices, credits, deposits, concessions, refunds, unapplied receipts, tax treatment and allocation. The balance agrees until a parent asks which invoice was paid or the school processes a refund.

Mid-year cutover forces two systems to explain one financial period. At a natural boundary, the school can bring forward controlled opening items and retain the old ledger as an accessible, immutable record—subject to local financial and retention requirements.

Integrations amplify every defect

The ERP or SIS supplies identity and structure to the LMS, assessment tools, library, transport, catering, clinic, finance, payment gateway, communications, access control and regulator. A migration can be correct internally but fail because an integration still expects the old identifier or year code.

OneRoster 1.2 demonstrates the breadth even in a standard K–12 exchange: academic sessions, organisations, users, demographics, courses, classes and enrolments, with separate gradebook and resource services. Conformance of a file format does not prove that the source meaning, identifiers or timing are correct.

Users invent a shadow continuity plan

When staff do not trust the new system during a live term, they keep parallel spreadsheets, paper registers and message groups “temporarily”. Those records quickly diverge. The migration team then reconciles not two sources but five.

Dual running sounds safe, but two writable systems create two truths. A controlled parallel test uses frozen or time-bounded inputs and compares outputs. It does not allow different staff to transact in whichever system they prefer.

What actually has to migrate

Migration scope must be decided by legal need, operational use and evidential value—not by “everything” or “the last five years”. Separate four treatments:

1. Migrate as structured live data. Needed to operate or report in the new system.
2. Migrate as structured history. Needed for trend, transcript, audit or safeguarding use.
3. Archive read-only. Must be retained but does not justify transformation into the new schema.
4. Dispose lawfully. No longer required and approved under the institution's retention policy.

Domain	Typical live requirement	Commonly missed dependency
Identity and family	Students, guardians, relationships, contacts, preferred language, permissions	One guardian linked to several children; restricted-contact rules
Admissions	Active applicants, decisions, offers, deposits, required documents	Conversion from applicant to student without a duplicate person
Enrolment	School, year, programme, class, status and effective dates	Withdrawals, repeat years, mid-year transfers and future enrolments
Academic structure	Years, subjects, courses, classes, terms, grading periods	Old and new codes meaning different things
Timetable	Rooms, teachers, periods, rotations and exceptions	Week patterns and individual calendars
Attendance	Sessions, marks, reasons, amendments and denominator	Late changes, authorised categories and timezone/cut-off rules
Assessment	Schemes, components, marks, grades, moderation and reports	Draft versus approved grades; scale changes across years
Fees and finance	Debtors, invoices, credits, receipts, deposits, concessions and balances	Unapplied cash, refunds and payer-versus-student relationship
Health and safeguarding	Alerts, care plans, consent, incidents and access restrictions	Confidential attachments and role-based visibility
Services	Transport, meals, activities, library and devices	Assignment dates and billing consequences
Documents	Type, owner, date, revision, sensitivity and retention	Files without metadata or linked to the wrong person
Security	Users, roles, scopes, status and authentication link	Leavers, shared accounts and over-broad inherited roles

The system-of-record decision comes first. If attendance is entered in an LMS but officially reported from the SIS, state which side is authoritative, the synchronisation cut-off and how amendments flow.

Build a migration control record

Every field or object in scope should have:

• source system, table or export;
• source definition and known data-quality issues;
• transformation and mapping rule;
• target object and field;
• treatment of null, invalid and legacy values;
• owner who can approve the meaning;
• reconciliation method and tolerance;
• privacy classification and access rule;
• retention or archive decision;
• sample cases and expected result.

The document is usually called a mapping specification, but it should behave like a controlled contract. Version it. When a rule changes after rehearsal two, record why and rerun every affected test.

Technical teams can map columns; they cannot decide whether “active” means attending, enrolled, offered a place, financially active or portal-enabled. The registrar, finance lead, safeguarding lead, academic owner and service owners must approve meanings in their domains.

Rehearse with the whole chain

A migration rehearsal is not “the import completed without errors”. It is a timed execution of the entire cutover on production-scale data, followed by reconciliation and real user tasks.

Run at least two full rehearsals after initial development:

Rehearsal one: expose meaning and scale

• extract every in-scope domain;
• transform and load in dependency order;
• record rejects, duplicates, duration and manual interventions;
• reconcile control totals;
• have domain owners inspect exceptions and representative records;
• run integrations with safe test consumers;
• measure the time needed to correct and rerun.

Rehearsal two: prove the final runbook

• use the production cutover sequence and named staff;
• start at the planned clock time;
• use only approved scripts, mappings and access;
• simulate the write freeze and delta process;
• perform full acceptance and decision meetings;
• test restore or rollback, not merely document it;
• prove completion inside the actual outage window with contingency.

If the final rehearsal finishes at 05:55 for a 06:00 opening, the plan has failed. A safe window includes time to diagnose, rerun, reconcile and still decide to roll back.

Reconcile meaning, not only row counts

Row counts are necessary and weak. A table can contain the same number of records with the wrong relationships, dates or money.

Use layered reconciliation:

Control totals

• students by school, status, year and class;
• guardians and students with no active guardian;
• active enrolments and future enrolments;
• attendance sessions and marks by term;
• grade records by subject, class and approval state;
• invoice, credit, receipt and outstanding values by currency and school;
• documents by type and security classification;
• users by role, status and school scope.

Referential tests

• no enrolment without a valid student, school, class and academic session;
• no student assigned to mutually exclusive active classes unless intended;
• no receipt allocated to a missing invoice;
• no timetable entry pointing to a missing teacher, room or subject;
• no parent portal account linked to the wrong family;
• no confidential document without an authorised owner and access rule.

Record-level samples

Select difficult cases deliberately: twins, split households, restricted contacts, mid-year transfer, withdrawn applicant, returning student, fee concession, refund, class change, amended attendance, grade appeal, staff member who is also a parent and a student with multiple service assignments.

End-to-end tasks

Ask users to admit a student, record attendance, change a guardian contact, collect a receipt, issue a credit, publish a timetable, produce a report, enrol a user into the LMS, record an incident and withdraw a leaver. The test is whether the school can work, not whether the screen opens.

Freeze, delta and rollback

The cutover runbook should state the last permitted transaction in every source and channel. The parent portal, payment gateway, admissions form, mobile app and integrations all count as writers.

Choose one of three treatments for changes during the freeze:

• stop: disable the process and communicate the outage;
• queue: accept through a controlled channel for replay after opening;
• redirect: transact in the new system after a defined point.

Avoid manual notes with no sequence or owner. A delta log needs timestamp, person or object, change, source evidence, target action, status and verifier.

Rollback must name a decision deadline, authority and objective triggers. Examples include unreconciled financial difference above zero or approved tolerance, missing safeguarding records, identity-linking defect, integration failure affecting opening, or insufficient time to complete acceptance.

The rollback plan must restore more than the database. It must address source write access, integrations, authentication, queued transactions, payment routing and user communications. NIST's system-backup controls require backup information to be tested for reliability and integrity; a backup that has never been restored is only an assumption.

The cutover decision gate

Go live only when all blocking criteria pass:

Gate	Evidence
Data	Required objects loaded; rejects resolved or accepted under a named exception
Reconciliation	Counts, relationships and financial totals pass approved tolerances
Safety and privacy	Safeguarding, health, consent and restricted-contact cases verified
Operations	Timetable, attendance, fees, admissions, communications and reporting tasks pass
Integrations	Identity, LMS, payment and critical service exchanges pass end to end
Security	Roles, leavers, privileged access and authentication tested
Performance	Peak login and essential transaction response meet acceptance
Recovery	Backup, restore and rollback sequence tested within the decision window
People	Trained users, floor support, service desk and vendor escalation are scheduled
Governance	Named business owners sign the decision; exceptions have owners and dates

Do not let the supplier alone declare success. The school remains accountable for its data and service. The UK Department for Education's supplier guidance makes the general governance point plainly: even when a third party provides a vital system such as an MIS, the school remains the data controller and must monitor supplier performance and agreed deliverables.

If mid-year cannot be avoided

Sometimes the existing supplier exits, the system is unsafe, a merger takes effect or a regulatory deadline removes the ideal window. A mid-year move is then a risk decision, not a routine implementation.

Reduce scope and change:

• migrate at a term or grading-period boundary rather than an arbitrary weekend;
• freeze configuration, reports and non-essential integrations;
• move only the live minimum and archive the rest for later controlled migration;
• close or snapshot attendance, grades and fees to a precise time;
• shorten the freeze with automated, repeatable extraction and load;
• staff manual continuity for attendance, safeguarding, payments and communications;
• maintain one authoritative transaction system at every moment;
• run intensified reconciliation each day after opening;
• keep the old system read-only and accessible under approved retention and security controls.

Do not solve timing pressure by dropping rehearsal, acceptance or rollback. Those controls become more important as the window becomes worse.

The first 30 days after opening

Hypercare should follow school processes, not generic ticket counts.

Review daily at first:

• unlinked or duplicate identities;
• students missing from class, timetable or downstream tools;
• attendance gaps and unusual denominator changes;
• payments not allocated or posted once;
• messages sent to wrong or inactive contacts;
• access failures and excessive permissions;
• integration queues and rejected records;
• data fixes performed directly without an audit trail.

Record correction rules in a controlled queue. Users should not repair history in spreadsheets and ask IT to “make the system match”. Every correction needs source evidence, approval where required, timestamp and downstream replay.

Keep the project team long enough to complete the first operational cycles: first attendance day, first invoice and receipt, first timetable change, first report, first withdrawal, first integration refresh and first required external return. Technical stability on day two is not migration completion.

Common failure modes

• The date is chosen by contract expiry. Academic and financial state is ignored.
• Only current students are tested. Leavers, future entrants and complex families break later.
• Balances match, transactions do not. Refunds and parent queries cannot be explained.
• A single trial load is called a rehearsal. Timing, ownership and rollback remain unproved.
• The old and new systems both stay writable. Staff create two official records.
• Integration testing starts after cutover. Correct students cannot access learning or services.
• Every legacy field is migrated. Old errors and unused customisations become new-system requirements.
• Too little history is retained. Transcripts, disputes and trend reporting become impossible.
• Training demonstrates screens. Staff cannot complete their actual first-week tasks.
• The vendor signs off its own work. Business owners never accept the meaning of their data.

FAQ

Is the summer holiday always the best migration time? No. It is useful only if the old academic year is closed and the new one has not begun operationally. Summer programmes, admissions, billing and results can make part of the holiday a poor window.

How long should the old ERP remain available? As long as the approved retention, audit and operational-access plan requires. Prefer read-only, secured access with named users and a tested archive; do not leave it writable “just in case”.

Should all historical data be migrated? No. Migrate history that must be searched, reported or used in the new workflow. Preserve other required records in an accessible, immutable archive, and dispose only under the institution's approved retention policy.

Can we run both systems in parallel for a term? Use parallel calculation and comparison for selected processes, but define one transactional system of record. Two writable systems for attendance, grades or fees create divergence rather than safety.

What is the most important rehearsal result? Not import success. It is the time at which reconciled business owners can make a confident go or rollback decision while enough recovery window remains.

Where a system helps

A well-designed school ERP reduces migration risk when its data model preserves effective-dated enrolments, family relationships, academic sessions, financial transactions and audit history instead of flattening them into current-state fields. The implementation should provide repeatable imports, exception reporting, reconciliation totals, controlled roles and standard exchanges such as OneRoster—then prove them against the school's real calendar and difficult records before cutover. See SchoolOS for school ERP.

Related reading: What Is a Student Information System? (KB-033) and What Is a Transfer Certificate? (KB-118).

Sources

• 1EdTech, OneRoster 1.2 Standard
• 1EdTech, OneRoster Planning and Procurement Guide
• Ed-Fi Alliance, School Calendar Domain
• UK Department for Education, Third-party suppliers for schools
• NIST SP 800-53 Rev. 5.1, System Backup controls