Switching from ParentSquare
The data migration is the easy part and almost nobody warns you about the hard part. This is the sequence we would follow, the timing that makes it survivable, and an honest account of what does not come across.
| Data | Comes across | Notes |
|---|---|---|
| Students, staff, schools | Yes | Standard export bundle; re-keyed to your SIS identifiers |
| Guardians and contact points | Yes | Phones normalised to E.164, duplicates merged, junk records dropped and itemised |
| Guardian–student relationships | Yes | Referential integrity checked; orphans reported rather than silently dropped |
| Language preferences | Yes | Mapped from names to ISO codes |
| Classes and enrolments | Yes | Better re-derived from a fresh SIS sync than carried over |
| Message history | Archive only | Keep the export as your record; it is a FOIA and discovery asset |
| Form responses and signatures | Archive only | Signed documents should stay with the system that captured them |
| Family app logins | No | Families re-onboard. This is the real work — plan for it |
| Per-family notification preferences | No | Defaults apply until families set their own |
Cut over between school years, not during one
The single highest-impact decision is timing, and it is not close. A June or July cutover gives office staff the summer to learn the new tool and gives you an August re-onboarding campaign that rides the back-to-school attention spike, when families are already opening things from school.
A mid-year cutover asks families to re-onboard in the middle of a term, when nothing has their attention, and asks office staff to learn new software in the week they are chasing attendance. It is survivable, but it costs reach, and reach is the entire product.
If your renewal date forces a mid-year decision, the usual answer is a short bridging extension on the incumbent to land the cutover in the summer. That is a normal procurement conversation and most vendors will do it.
The sequence
- Request your export before you sign anything. You are entitled to your data; get it in hand early so the migration is a known quantity rather than a risk.
- Run the importer in validation mode. Ours is open source, MIT-licensed, and runs without a Kastr account. It reports counts, drops and integrity failures without writing anywhere.
- Read the drop ledger. This is the step people skip. Every dropped record is listed with a reason — junk guardian names, unparseable phone numbers, orphaned relationships. Some of those are genuine data-quality problems you will want to fix at source regardless of which vendor you pick.
- Take the signed receipt to procurement. A PDF with a per-file SHA-256 manifest and an HMAC signature over the bundle hash, showing source versus imported counts. That is a board-meeting document, not a log file.
- Connect the SIS. Classes and enrolments are better re-derived from a live roster sync than carried over. Our sync aborts if it would withdraw more than half your active records — the truncated-export failure that turns one bad CSV into a district-wide messaging outage.
- Re-onboard families. The actual work. Budget three touches across three weeks, in every language your families speak, and expect to be chasing the last 5% into September.
- Keep the old export. Message history and signed forms are records. Archive them somewhere you can retrieve them under a FOIA or discovery request.
What nobody tells you
Re-onboarding is the whole project. Every district that has done this badly did the data properly and the humans badly. Families do not care that you changed vendors; they care that the thing that used to tell them about early dismissal has stopped. Over-communicate on the old platform before you turn it off.
Your roster is dirtier than you think. Every long-lived contact database accumulates guardians named "mom", duplicate phone numbers across siblings, and relationships pointing at withdrawn students. A migration is the one moment you get a full inventory of it. Use the drop ledger as a data-quality worklist even if you stay put.
Front-office staff are the real users. Not administrators, not teachers. The people who send twenty messages a week decide whether a platform succeeded. Get them into the new composer in June, and take the "how many clicks to send" question seriously.
Questions people actually ask
Can I export my data from ParentSquare?
Yes — districts can obtain their data. Request it early rather than at the end of a notice period, and confirm which record classes are included, since message history and form responses are often handled separately from roster and contact data.
When is the best time to switch school communication platforms?
June or July. It gives staff the summer to learn the tool and lets family re-onboarding ride the back-to-school attention spike. Mid-year cutovers cost you reach because families do not re-onboard when nothing has their attention.
What is a migration receipt?
A signed PDF recording exactly what came across: a per-source-file SHA-256 manifest, an HMAC signature over the bundle hash, source-versus-imported counts, and a ledger of every dropped record with its reason. It exists so migration is an auditable event rather than a claim. As far as we know no other vendor in this category produces one.
How long does a migration take?
The data is a weekend. Family re-onboarding is three to six weeks of communication, and chasing the last few percent runs into September. Plan around the second number.
Switching is a weekend, and you get a receipt.
Our ParentSquare importer is MIT-licensed and runs without us. It validates your export, normalises phone numbers and languages, drops the junk guardian records, and emits a signed PDF receipt with a per-file SHA-256 manifest — a procurement artefact, not a developer log.