How to move school records into a new platform

What should a school settle before the first record moves?

Settle six things before anything is exported: the cut-off date after which the old system stops being updated, the person inside the school who owns the move, which record groups are in scope, who signs off that the import is correct, whether the import is included in the quoted price, and what the new vendor is contracted to do. One dated page holding those six answers is the plan.

Choose the cut-off date where the record set is already at rest: the end of a term, after results are published and before the next intake, not a week when marks, fees and attendance are all moving. It is the line the test import is later checked against.

Then make the vendor describe the import first. The UK Department for Education's Procuring educational technology (EdTech) guidance tells schools to “ask the supplier to walk through the way the personal data flows and what happens with it at every stage”. Moving into a student information system or school management platform, the first stage of that flow is a file of real student records leaving one company for another.

Is moving the records included in the quoted price?

Ask, and get the answer in writing before signing: a licence quoted per student per year may still bill the move separately. Five questions settle it. Is the import included or extra? Is it a fixed fee, per record group, or by the hour? Who pays if a check fails and it has to be run again? What re-typing is the school expected to do? Is training in the price?

The move is one row of the school software onboarding checklist, inside the platform evaluation guide; the step before it is running a pilot.

Working out what you would be moving, and what to ask about it? You can ask Easy Edu whether it does the import, and if so how it is checked and priced using the published enquiry email, without attaching any records.

Which school records should cross, and which should stay?

Decide group by group, and write the decision against every group, including the groups the school is leaving behind. Carry across what the new platform needs to run the school day it is being bought for, and leave what is kept only because the old system happened to hold it.

Buying more than a school will use is a documented pattern. For the United States, UNESCO's 2023 Global Education Monitoring Report records “an average of 67% of education software licences were unused and 98% were not used intensively” — about American schools, and about no single vendor. Decide what the school will actually work with, in licences and in records.

Use a grouping that already exists rather than inventing one. The Department for Education's Record keeping and management guidance asks schools to consider grouping their pupil data items into eleven areas — among them “admissions”, “attendance”, “identity management and authentication” and “safeguarding and special educational needs” — and says: “Document the decision you make against each data item.”

What does Malaysia's PDPA say about the records left behind?

Keeping less is a legal question as well as a practical one. The Personal Data Protection Act 2010 (Act 709), in its 2022 reprint, sets a Retention Principle at section 10: personal data “shall not be kept longer than is necessary for the fulfilment of that purpose”, with a duty to ensure it is “destroyed or permanently deleted” once no longer required.

Read that reprint as the wording of its date, not as today's position. It regulates personal data “in commercial transactions” and its section 3(1) excludes the Federal and State Governments, and the department's own published FAQ now uses different terminology and cites a later section the reprint does not carry. Check the current text, and whether it reaches the school's own arrangement, with the school's adviser.

On a move it changes the question asked of each group left behind: not only whether the new platform needs it, but how long the school needs it at all, and what happens to the copy in the old system. The questions to put to a vendor are in the data ownership, export and deletion guide and the PDPA privacy questions guide.

Which records should be cleaned before the migration export?

Take one untouched read-only export first and keep it as the master copy, then clean the records in the old system rather than in the new platform. De-duplicate students and guardians, settle one spelling of every name and address, close the records that should already be closed, and agree the single identifier that matches a person across both systems.

Search the export for four patterns before it leaves the school: siblings entered twice under one parent, a student who left and returned under a second profile, a parent recorded once per child, and the same name typed in two scripts or two orders. Fix what those four searches find, and record what was changed.

Agree the identifier at the same time, because every later check depends on it: pick the one number already unique to each student, write it on the migration map as the field both systems match on, and reconcile the test import against it. Where none exists, create it first.

Give the clean-up to people who know the records, and give them time for it rather than adding it to a teaching week. The UK Department for Education's Making data work (November 2018, the Teacher Workload Advisory Group chaired by Professor Becky Allen of UCL) records that “The Workload Challenge (2014) identified unnecessary tasks linked to assessment and data with 56% of respondents citing tasks around ‘recording, inputting, monitoring and analysing data’ as burdensome”. Keeping entry down afterwards is the duplicate record entry guide.

How should the migration map be agreed in writing?

Agree a mapping sheet before the first import: every field in the old system, the field it becomes in the new one, who converts it, and what happens to the fields that have no home. Both sides sign and date it, and that signed version is what the import is later checked against.

A migration map is the school's record of what it asked for, not the vendor's record of what it did. Keep it with the quotation and the contract, with a column for who checked each group after the import.

Then put the responsibilities where they can be enforced. The Department for Education's EdTech procurement guidance runs the point in three sentences: “Make sure responsibilities are clearly assigned in a contract or data processing agreement.”; “Before signing any contracts or agreements with the supplier, check all clauses to ensure they meet your requirements and challenge any that you are unhappy with.”; and “This should cover security measures, sub-processors, deletion and return of data, breach notification, and staff access control.” On a move, add the import itself.

Where Malaysian law applies to the arrangement, how the file travels is addressed too. The Act 709 2022 reprint's Security Principle, at section 9, requires a data user to protect personal data with regard, among other things, to “the measures taken for ensuring the secure transfer of the personal data”, and to ensure that a data processor acting on its behalf “provides sufficient guarantees in respect of the technical and organizational security measures governing the processing to be carried out”.

What happens to a field the new platform has no home for?

A field the new platform cannot hold is recorded as a decision rather than left to vanish. Against each unmatched field write one of three answers on the migration map: dropped, and why; moved to a notes field, and who reads it there; or kept in the school's own master export.

How should a school check the imported records?

Check a small import before the full one, and check it against the master export rather than against the new screen. Match the record count first, then open named students and compare every field side by side. Record who checked which group, on what date, and what was wrong. Only then import the rest.

An import that looks right on screen has not been checked: the screen shows what arrived, not what was sent. Give the check to someone who knows the records, not to whoever ran the export.

1. Counts. Students, staff, parent or guardian links, and classes, each against the master export taken on the cut-off date. Explain every difference before moving on.
2. Hard cases on purpose. Long names, names with punctuation or several parts, siblings in different years, a student who joined mid-year, and anyone held under two names.
3. Links, not just records. That each parent or guardian reaches the right child, and only that child: the role-by-role version of this check is the access evaluation guide.
4. Dates and codes. Dates of birth, enrolment dates, term start and end dates, and every attendance or grading code the migration map said would be converted.
5. What is now visible. Sign in as a teacher and as a parent: a correct import into the wrong permission is still a problem.

Accuracy carries a legal edge too, where the Act applies. The Act 709 2022 reprint's Data Integrity Principle, at section 11, requires a data user to “take reasonable steps to ensure that the personal data is accurate, complete, not misleading and kept up-to-date”, and its section 34 provides for a written correction request where data is “inaccurate, incomplete, misleading or not up-to-date”.

What happens at cut-over, and to the old system afterwards?

Freeze the old system on the cut-off date, switch the syncs and integrations off while records are moving, work in the new platform for one full cycle with the old one still readable, and only then end the old contract on written terms. Keep the master export as the school's own copy.

Turn the integrations back on one at a time, and check what each one wrote. Train the people who will use the platform in the week they start, on the school's own records rather than a demonstration set, and set a date two to four weeks after cut-over for whoever signed off the import to re-check a sample of records and the reports people use.

Those weeks are what recommendation 5 of Putting Evidence to Work: A School's Guide to Implementation, by Professor Jonathan Sharples, Bianca Albers, Stephen Fraser and Professor Stuart Kime for the Education Endowment Foundation, is aimed at: “Support staff, monitor progress, solve problems, and adapt strategies as the approach is used for the first time.”

Then close the old contract and deal with the copies the move created. The EdTech procurement guidance puts the handover in one sentence: “Confirm how data will be returned to the school and how any remaining data held by the supplier will be securely deleted.”

Export files, mapping spreadsheets and mailbox attachments are student records sitting outside both systems, and the same department's record-keeping guidance is plain: “If you identify any information you no longer need, you should dispose of it safely.” Decide which single copy the school keeps, where it lives and who may open it.