Every implementation team has seen the same pattern. A school exports student records from the old system, imports them into the new one, and within a week the registrar is filing the same support tickets she had last year — duplicate siblings, mismatched grade levels, parents whose phone numbers point to a disconnected line. Migration day looked clean. The data was not.
The fix is to treat cleanup as its own phase, not a side effect of export. Below is the 10-step pre-migration checklist we walk through with every school before turning on Borderset. It is opinionated on purpose; skipping a step is fine if you can defend the decision in writing.
Before you export anything (steps 1–3)
1. Freeze the source system
Pick a cut-off timestamp and tell every registrar, counselor, and teacher that edits after that point will not be carried over. Without a freeze, you will spend the launch week reconciling phantom changes that exist in one system but not the other. Communicate the freeze in writing, post it in the staff room, and put a banner on the legacy login screen so nobody can claim they did not know.
2. Decide archive vs delete
Withdrawn students, retired staff, and discontinued programs do not need to live in the new student information system. Move them to a read-only archive export and import only active records. Most schools cut their row count by 30–50% at this step, which also makes every downstream report faster and easier to interpret.
3. Find and merge duplicates
Match on student ID, then full name, then date of birth. Siblings sharing a phone number are not duplicates; the same child entered twice under two spellings is. Resolve these in the source — never in the destination — so the next migration after this one inherits a clean record.
Normalize the fields that break reports (steps 4–6)
4. Standardize names, dates, and codes
Pick one date format, one phone format, and one set of grade-level codes. "Grade 1", "1", and "1st" should not coexist. The same applies to country codes on phone numbers, capitalization on family names, and the way you record middle names. For more on why one source of truth matters, see why a single SIS beats spreadsheets.
5. Validate guardian relationships and backups
Every active student needs at least one contactable guardian. Flag rows where the relationship type is blank, the email bounces, or custody fields conflict. Borderset will accept the row, but your first parent message will not reach anyone. Then export the cleaned source twice: once as your migration payload, once as an untouched snapshot. Store the snapshot somewhere your migration scripts cannot reach, and confirm you can restore from it before you delete anything.
Step 6 maps every legacy code to its new home. Old systems accumulate codes that nobody remembers creating — discipline categories, course catalog entries, room types. Build a one-page mapping document that shows where every code from the legacy export will land in Borderset. Codes with no destination should be archived, not silently dropped, so an auditor asking about a historical record next year still has a paper trail.
Test before you trust (steps 7–10)
Steps 7 through 10 are about catching what the spreadsheet hid. Step 7 is the sandbox import: bring a single grade or campus into a Borderset sandbox first. Have the registrar pull her three most painful reports and compare them line for line against the source. If totals differ, stop and trace the gap before scaling up. Step 8 is the reconciliation pass — run the full import, then re-run the same three reports in production and check that the counts match the sandbox.
Step 9 locks down access. Decide who can touch the imported tables and review role-based access before you hand the keys to anyone. Step 10 is the post-go-live audit two weeks in: pull a random sample of fifty students and verify every field. The Enverson migration case study walks through what that reconciliation looked like in practice, and the SIS integration overview covers the sequencing alongside cleanup.
Cleanup is not glamorous, but it is the cheapest hour your team will spend on the project. Every issue you fix in the source costs minutes. The same issue caught after go-live in Borderset costs days, because now teachers are also asking why their class lists look wrong and parents are emailing the front office.