Migrating your communications platform mid-year versus waiting for July
The honest answer is that July is easier and January is sometimes right anyway. What decides it is not the calendar, it is whether your current platform is failing families now and whether your 10DLC registration can start today.
| Week | Mid-year path (target: after February break) | Summer path (target: first day of school) |
|---|---|---|
| 1 | Start 10DLC registration. Nothing else matters until this is moving. | Start 10DLC registration in early June. |
| 2–3 | Export from the incumbent. Verify it contains consent and validation history, not just names and numbers. | Export after the last day, once the year's roster is final. |
| 4 | Roster feed to the new platform. Reconcile counts per school against the SIS. | Same, with more time and a stable roster. |
| 5 | Run both platforms. All sends still go from the incumbent. | Configure scopes, groups and templates without time pressure. |
| 6 | Staff training, one hour per building, compressed into a fortnight. | Training in the August in-service days, where it belongs. |
| 7 | Pilot: two buildings send real messages on the new platform. | Pilot with summer-school and athletics communications. |
| 8 | Go/no-go. If 10DLC is not approved, stop and wait. | Go/no-go with a month of margin. |
| 9 | Cut over between terms, never mid-week. | Cut over before back-to-school communications begin. |
| 10–12 | Keep the incumbent's read access for the rest of the contract. | Incumbent read-only until the contract ends. |
| Risk | Staff learn a new tool in their busiest term; families see a change mid-year | Change lands with the new year, when families expect change |
| When it wins | The incumbent is failing now, or a renewal deadline forces it | Almost every other case |
Eleven things that break during a comms migration
- Roster drift. The export is a snapshot; enrolment moves underneath it. Reconcile per school, not district-wide, because one building's discrepancy hides in a district total.
- Consent state. The field most often absent from an incumbent's export. Losing it means either re-collecting consent or sending without it, and only one of those is acceptable.
- Validation history. Which numbers have failed before. Losing it means re-learning it through failed sends, at cost.
- Guardian de-duplication. The same adult appears three times with three spellings. Merge deliberately, with a rule, or the new system inherits the mess plus new duplicates.
- Junk guardian records. Every long-lived roster contains guardians literally named "mom", "dad", "grandma" and "unknown". Filter them, and keep the list of what you dropped.
- In-flight scheduled messages. Anything scheduled in the incumbent past your cut-over date will still send. Inventory and cancel them explicitly.
- Saved lists and audiences. Rarely exportable. Rebuild the ten that matter and abandon the rest; most were built for one event in 2023.
- PTA and volunteer groups. Membership lives in the old platform and the volunteers are not district staff. Give them notice, not a surprise.
- Staff muscle memory. A term of slower sending and more mistakes. Real, unavoidable, and the strongest argument for a summer move.
- Audit continuity. Your record of what was sent splits across two systems. Export the old history before access ends, not after.
- Family confusion. Two apps, two sender numbers, two sets of notifications. Tell families once, clearly, before the cut-over, and give the new sender number in advance so it is not an unknown number.
What to demand from your outgoing vendor
Ask in writing, before you give notice, and ask specifically. Vague requests receive vague exports.
- Students and guardians with relationships, including guardian rank, in CSV or JSON — not PDF.
- All contact points with their validation state, consent state, source and date. This is the request most likely to be quietly declined, and the most important one.
- Message history with timestamps, recipients and delivery outcomes.
- Group and list memberships, including volunteer and PTA groups.
- Any automation rules you configured, as a readable document if not as data.
- The date after which access ends, in writing, with any read-only period stated.
The questions that reveal whether the export is real. "What format?" — PDF means it is a report, not an export. "Does it include consent state?" — if the answer is that consent is implied by the number being present, it does not. "How long does it take?" — six weeks means the process is manual and you should start now. Request a sample export while you are still a customer in good standing, not after you give notice.
Where Kastr's importer helps, and where it stops
Our ParentSquare importer is MIT-licensed and runs without a Kastr account. It parses the standard seven-file export bundle with a zip-slip guard and a 200 MB cap, normalises phone numbers to E.164, validates email addresses, maps language codes, de-duplicates contact points, and filters the junk guardian names that accumulate in every long-lived roster.
It then produces a signed migration receipt: a PDF carrying a per-source-file SHA-256 manifest, an HMAC-SHA256 signature over the bundle hash, a source-versus-imported count table, and a ledger of every record dropped with the reason. That is a procurement artefact rather than a log file — something you can hand to a board to answer "what did we bring across, and what did we lose". If no signing key is configured it prints, in red, that the receipt is unsigned rather than faking a signature.
The limit, stated plainly: the importer validates your export and produces the receipt. It does not write rows into a Kastr tenant. The row-load step is done with us during onboarding. Anyone describing this as a one-click migration, including anyone at Kastr, is over-claiming.
The go/no-go criteria that actually matter
Do not cut over unless all five are true. Each has caused a failed migration somewhere.
- 10DLC brand and campaign registration is approved, not submitted. Unregistered traffic is silently filtered, so your first district send would vanish without an error.
- Guardian coverage in the new system matches the old within one per cent, per school. Per school. District totals hide a single building's disaster.
- Consent state came across, or you have a plan for the families where it did not.
- Two pilot buildings have sent real messages and reported fewer than three "I never got it" calls between them.
- Families have been told, including the new sender number, at least a week ahead.
If any one fails, wait. A delayed migration costs a term of frustration; a migration that goes live with unregistered SMS and 8% missing guardians costs the district's trust, and that takes years rather than weeks to rebuild.
Questions people actually ask
Is it ever a good idea to switch platforms in January?
Yes, in two cases: the incumbent is actively failing families now, or a renewal deadline forces the decision and waiting means committing to another full year. Otherwise summer wins, because staff learn the tool during in-service rather than during their busiest term and families expect change with a new school year.
What does a district lose when it changes comms vendors?
Usually consent state and validation history, saved audiences, group memberships, and a term of staff fluency. Message history is recoverable only if you export it before access ends. Ask for consent state explicitly in writing before you give notice — it is the field most often missing from an export and the most expensive to reconstruct.
How long does a summer migration actually take?
About nine weeks of part-time work if 10DLC registration starts in early June, and the registration is the part that cannot be compressed. Roster reconciliation, scope configuration, training during August in-service and a summer-school pilot fill the rest. Districts that start in mid-July are usually still going live in week three of term.
How do we prove what data we brought across?
With a manifest, not a memory. Kastr's ParentSquare importer produces a signed receipt containing a per-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. Whatever platform you choose, ask for the equivalent artefact — a count comparison at minimum — before you decommission the old system.
What happens to consent records when we move?
They move only if the outgoing vendor exports them, and many do not. Where consent does not come across, the defensible options are to re-collect it or to restrict to channels where consent is not required. Sending on an assumption that a phone number implies SMS consent is the failure mode that turns a migration into a compliance problem.
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.