School data migration: a controlled handover plan

Set the scope before exporting

List the records the school needs in the new system, the records that should remain in a controlled archive and the records that can be deleted under the approved retention arrangements. Do not copy everything simply because it is available. Historical records may need different access and a different purpose from current operational data.

Assign a school owner for each dataset. The supplier can explain its import format, but the school needs someone who can decide whether a contact relationship, financial balance or attendance history is correct. Record the decisions and the person authorised to approve exceptions.

Create a field mapping

For each source field, document the destination, format and any transformation. Include dates, codes, identifiers, text lengths and relationships. A field called status in one system may have a different meaning in another. Blank values, unknown values and not-applicable values should not be silently treated as equivalent.

Source detail	Migration question
Pupil identifier	Will it remain stable and preserve related records?
Contact relationship	Are priority and access restrictions separate fields?
Historical code	Does the new system recognise the original meaning?
Attachment	Will its file, label and record relationship survive?
Financial balance	What date and underlying transactions does it represent?
Free-text note	Is it necessary, appropriately restricted and correctly formatted?

Keep the mapping readable for operational staff. Technical conversion rules should be traceable to a school decision rather than hidden in an import script.

Clean carefully and keep evidence

Resolve duplicates and obvious data-quality problems before the final move, using an approved process. Avoid mass correction based on assumptions. Two similar pupil names may be separate people, and two adults at one address may need distinct accounts. Record significant merges or corrections so the school can explain them later.

Use secure working locations and restrict access to the migration team. Exports often concentrate information that is normally protected behind role-based screens. Keep a register of temporary files, who has them and when they should be removed. Demonstrations and training should use fictional data wherever practical.

Run a representative trial

A trial import should include enough variety to exercise the mapping: current pupils, leavers where required, complex contacts, group changes, relevant history and attachments. Check the resulting records through normal user screens as well as through import reports. A file can import successfully while producing an unusable operational record.

Reconcile counts by meaningful groups and compare critical totals. Sample individual records from different scenarios. Where the system holds money, reconcile opening balances and underlying supporting records separately. For attendance or reporting data, confirm that the new reports use the intended definitions and periods.

Test access and connected services

Log in with representative staff roles and confirm what each can see and change. Check whether parent access, notifications and automated messages are disabled until the planned launch point. A trial migration should not accidentally send account invitations to real families.

Test each downstream integration after the imported data is present. Confirm that stable identifiers match, leavers are treated correctly and duplicate accounts are not created. The migration and integration teams need one coordinated plan, because a correct import can still trigger incorrect changes in connected services.

Agree the cutover and rollback decision

Choose a realistic window based on school operations and supplier support. Specify when changes in the old system stop, how last-minute changes are recorded and who enters any approved updates after the final import. Tell staff which system is authoritative at each stage.

Set clear go or no-go criteria. Examples include reconciled critical data, acceptable performance, working permissions and completed essential reports. Name the person who can postpone launch and the latest point at which rollback remains practical. A rollback plan must account for records created in the new system; restoring an earlier copy alone may lose that work.

Close the old system deliberately

Keep any agreed read-only access or archive available to the authorised people for the approved period. Record export completeness, supplier deletion arrangements and the date the old service stops. Revoke integrations and accounts that are no longer required.

After launch, maintain a controlled issue log with the affected record type, impact, owner and resolution. Distinguish data defects from training questions. Recheck the most important reports after the first full operating cycle. The final sign-off should confirm usable records, reconciled exceptions and a documented home for retained history. See school data retention for planning the archive and disposal stages.