How-to
How to migrate a small school from spreadsheets to a school system without losing records
Records almost never go missing during the import. They go missing in the weeks around it — in the binder nobody listed, in the month when two systems were both being written to, and in the one delete that had no undo. Here is the plan that guards those, sized for a school that does not have a project manager.
Written by the Pearspark team · updated · about 10 minutes
In short
A safe migration is a sequence: cut over at a term boundary, inventory what you keep — including the records that were never in a spreadsheet — freeze read-only copies of the originals, import one kind of record at a time behind a preview that writes nothing, reconcile by counting rather than scrolling, and from the cutover hour write in one system only. Keep the frozen originals for your state's retention period.
Records get lost around the import, not in it
The import itself is the best-guarded step of the whole migration. It has a file you can re-upload, a preview you can read, and a vendor whose reputation depends on it working. In practice the file goes in and the roster is fine.
The losses happen in four other places. First, the records that were never in a spreadsheet: immunization cards in a binder, signed enrollment agreements sitting in a Gmail thread, last year's grades in a teacher's own notebook, the list of who may collect which child living in one person's head. An import moves files. Nothing moves those but a person deciding they matter.
Second, the long overlap. The standard advice is to run the old and new systems side by side for a month, and for a school with one office person that is the single most dangerous thing on the list. Two live systems means every record exists in one of them and nobody is sure which. A week later a parent asks for a payment history that is half in each.
Third, the originals — either destroyed as soon as the new system looks right, or never frozen, so they keep drifting and stop being a reference you can trust.
Fourth, one wrong permanent delete inside the new system, on a row that looked like a duplicate and was not.
The plan below is mostly about those four. The import steps are the short part.
The plan, sized for a school of ten to sixty
In this order. Steps one to three are the ones that actually prevent loss; everything after them is process.
- Pick the cutover date and put it at a boundary. Summer is best, the start of a term is next best, and mid-term is the one to avoid — a grading period split across two systems has to be reassembled by hand at report-card time, and that is the reassembly people get wrong. Pick a date, not a month.
- Write the inventory on one page, starting with what is not a spreadsheet. List every place a record lives: the sheets, yes, but also the binder, the filing cabinet, the shared drive, the email thread with the signed forms, the teacher's own notebook, the fee schedule that only exists as a PDF, and whatever one person simply knows. Mark each one move, archive, or leave, and write who decides. This is the step that saves records, and it takes an hour.
- Freeze the originals before you touch anything. Make a read-only copy of every file, put a second copy somewhere the migration cannot reach, and open one of them to prove it opens — an untested backup is a belief, not a backup, which is the whole point of the restore-testing discipline in NIST's contingency planning guide. Then keep them. If your school is covered by FERPA, you may not destroy an education record while a parent's request to see it is outstanding, and your state sets how long the permanent record has to survive after that.
- Decide the student identifier before the first upload. Give every child a stable number that is not their name, not their email, and not their grade — all three of which change. If you already issue one, that column comes across. If you do not, Pearspark issues one when the column is blank, or hands the whole roster numbers in one action, and refuses any row whose number is already in use so two children can never share one.
- Rehearse with ten rows, not the whole file. Choose the ten deliberately: three siblings, a family with two households, a parent with no email address, a name spelled two ways, and a date of birth in the first twelve days of a month. If those ten land correctly the other fifty will. Nearly every importer worth using previews without writing anything; ours does, and so should any you are considering.
- Import one kind of record at a time, in the order things depend on each other: roster and contacts first, then classes and enrollment, then academic history, then health, then billing and aid. Check each one before starting the next. A mistake in the roster that is found before grades are attached is a re-upload; the same mistake found afterwards is an afternoon.
- Reconcile by counting, not by scrolling. Reading records until they look right stops working above about twenty students, and it is exactly where a missing family hides. The table below is what to count and how.
- From the cutover hour, one place to write. Set the spreadsheets read-only that morning — actually read-only, not "we'll be careful" — and keep them readable for as long as you like. Parallel reading is free. Parallel writing is the failure mode, and a week of it costs more than it buys.
- Prove the exit in the first week, while you still have the originals. Export your roster with the parents' emails, a class's grades, and an attendance summary back out of the new system, and open the files. A vendor that cannot hand you your own records as files you can read without them has told you something important, and the first week is a much better time to learn it than the third year.
- Then stop. Do not tidy up the old files, and do not delete anything for your retention period. The frozen copies cost nothing to keep and are the only thing that makes step nine's answer verifiable.
What to reconcile, and how to check it without opening records one by one
Run these after the roster import, and again after the last one. The middle column names the Pearspark report that answers each question in one click; every system has some version of these, and which ones a vendor has is a fair question to ask before you buy.
| What you're checking | How to check it |
|---|---|
| Everyone came across | Run the enrollment roster extract as of the cutover date and compare the count to the frozen spreadsheet. Two numbers, one comparison. |
| Every child has an adult, and every adult can be reached | The family contact gaps report: students with no guardian on file, guardians missing an email or phone, students with nobody authorized to collect them. |
| One adult is one record | The duplicate guardians report. A parent imported twice splits the family in the portal, doubles the invitations, and gives autopay two homes. |
| Nobody arrived twice | Student numbers do it for you if you set them in step four — a row whose number is taken is refused rather than merged. |
| Every student is actually in classes | Students in no classes. A child who imported but never got a schedule is invisible to attendance, the gradebook, and report cards. |
| Academic history landed | Report-card readiness lists classes with students but no grades. Then open one transcript and read it against the paper one. |
| Health records landed | Health record gaps: no health profile, no immunization record, expired medication authorizations. |
| Families can receive what you send | Portal adoption, after you invite: who was never invited, who never accepted, who muted notifications. |
| The money agrees | Invoice aging against your old billing sheet, and families without autopay before the first invoice run. |
None of these require reading a record. That is the point: a reconciliation you have to do by hand is one you will do once, in July, and never again.
What backing up means once the records are in someone else's software
You cannot back up a vendor's database, and a promise that they take regular backups protects them from a disk failure, not you from a bad decision. What you can hold is an export and a contract.
The export is the practical half. Decide now what you would need if the vendor vanished on a Tuesday: the roster with each child's guardians, emails and phone numbers; grades; an attendance summary; the transcript for every student who will ever ask for one; and the accounting history. In Pearspark those come out as the student CSV, a saved list of students or guardians with the contact columns, the per-class gradebook CSV, the attendance and enrollment extracts, printed records packets, and the bookkeeping export. Pull them once a term, keep them where the school keeps its own files, and you have converted a dependency into an inconvenience.
The contract is the other half, and it is the part the model terms of service published by the Department of Education were written for. Three questions decide most of it: what happens to your data if you cancel, whether the vendor deletes anything without being asked, and who else they hand it to. Our answers are on the privacy policy rather than only in a sales conversation: nothing is deleted unless a school asks, and when a school does ask we return its data first and then delete it. There is one deliberate exception and it belongs to families rather than to us — when a school offboards we keep a snapshot of each student's transcript and attendance summary, so a family can still get their child's records if the school later closes. Health records are not in that snapshot.
What to ask a vendor before the first real upload
Ask before you send a file with children's names in it, not after. Any vendor should answer all eight in writing, and the full set of questions worth asking is in the vendor-questions guide below.
- Does the importer preview without writing, and does it then commit exactly what the preview described?
- Can a committed import be undone, and for how long?
- Does creating a family email the family, or is inviting a separate step I control? (Some systems send the welcome mail on creation, and there is no recalling it.)
- Which records can I export, in what format, and can I do it myself without asking support?
- What happens to our data if we cancel — returned, deleted, kept, and on whose schedule?
- Who at the vendor can see our student records, and is that access logged where we can read it?
- Which subprocessors hold any part of our data?
- Show me the reconciliation reports: how would I find a family with no contact details, or a student in no classes, without opening records one at a time?
Where the records land
The parts of Pearspark that read from a migrated roster the moment it exists.
Watch the three imports
Roster, academic history, and what a finished record prints as. Sixty seconds each.
Common questions
What is the safest way to migrate a school from spreadsheets to a dedicated system?
Cut over at a term boundary; inventory what you keep, starting with the records that were never in a spreadsheet; freeze read-only copies of the originals and prove one opens; set a stable student number; rehearse with ten rows; import one kind of record at a time behind a preview; reconcile by counting; and write in one system from the cutover hour. Keep the frozen originals for your retention period.
How long should we run the spreadsheets and the new system side by side?
Read from both as long as you like. Write to both for zero days. A long overlap is standard advice for large institutions with staff to police it, and in a school with one office person it is how a payment or an absence ends up recorded in only one place with nobody sure which. Set the spreadsheets read-only on the cutover morning.
What should we back up before migrating?
Every file you are moving, as a read-only copy, plus a second copy somewhere the migration cannot reach — and open one to confirm it actually opens. Also photograph or scan what is not a file at all: the immunization cards, the signed agreements, the pickup list. Keep all of it for as long as your state requires, and never destroy a record while a parent's request to see it is outstanding.
In what order should we import our records?
Roster and family contacts first, then classes and enrollment, then academic history, then health, then billing and financial aid. Everything else in a school record hangs off the student and the adults attached to them, and checking each import before starting the next means a mistake never has to be untangled from three others.
How do we check that nothing was lost?
Count, do not scroll. Compare the enrollment roster count to the frozen spreadsheet, then run the exception reports: families with no contact details, duplicate parents, students in no classes, classes with no grades, health gaps. Reading records until they look right stops working above about twenty students, and a missing family is exactly what it hides.
When in the school year should we switch systems?
Summer, if you can wait. The start of a term if you cannot. Mid-term is the expensive one: a grading period split across two systems has to be reassembled by hand before report cards, and that reassembly is where grades go missing.
Can we undo an import if it goes wrong?
In Pearspark, yes, as one unit within 24 hours — it removes what the import created and restores what it overwrote. After that the imported students have attendance and grades of their own and correcting by hand is safer. Preview first regardless: a dry run costs nothing and shows exactly what committing would do. Ask any vendor both questions before uploading real families.
Do we have to keep the old spreadsheets after we migrate?
Yes, for a while, and longer than feels necessary. They are your only independent check that the migration was complete, and your state sets a minimum retention period for student records that does not care which system they are in now. Keep them read-only rather than tidying them up, and revisit after your first full year in the new system.
Sources
Every figure on this page is read from the source linked below. Where no source could be found for a claim, the claim is not made.
- 34 CFR 99.10(e) — a school may not destroy education records while a request to inspect them is outstanding (Cornell LII)
- NIST SP 800-34 Rev. 1, Contingency Planning Guide for Federal Information Systems (backup and restore testing)
- U.S. Department of Education, Protecting Student Privacy While Using Online Educational Services: Model Terms of Service
- National Microschooling Center, American Microschools 2025: A Sector Analysis (median enrollment and staffing)
- Google Docs Editors Help: Download a copy of a file (Sheets to CSV)
The full comparison behind each row
Each one is sourced feature by feature, last reviewed August 2026, and says plainly where the other system is the better choice.
See it before you decide
Every task is on video — one minute each — and your first 30 days are free. No sales call.