Migration guide

Switching from Remind: rebuild from the roster, not the app

The instinct when leaving a messaging tool is to export the contacts and import them somewhere else. For Remind specifically, that instinct produces a worse contact set than the one you already have in your student information system, and this page explains why and what to do instead.

Last reviewed 2026-08-04 · Kastr is pre-launch; we publish dated status rather than logos.

What leaves Remind, by record class and who owns it
Record classCreated byPractically retrievableWorth taking
Class and group membershipIndividual teachersPer-class, by the teacher who owns itNo — rebuild from enrolment
Parent phone numbers and emailsFamilies, self-enteredPer-class exportOnly as a reconciliation check
Message historyStaff and familiesPer-class, varies by planYes — retention and records obligations
Opt-out and stop recordsCarrier and platformNot portable between platformsYes, but must be re-collected
10DLC brand and campaign registrationThe sending platformTied to the outgoing vendorCannot transfer — re-register
Student and guardian relationshipsYour SIS, not RemindAlready yoursThis is your real source

The last row is the point of the table. Everything a district actually needs to message families already exists in the SIS with better provenance than any messaging tool's export.

Why the export is the wrong starting point

A Remind contact list is a record of who chose to join a class channel. A student information system is a record of who is enrolled and who is legally responsible for them. Those are different populations and only one of them is authoritative.

Importing the messaging tool's list carries four defects into your new platform:

  • Selection bias. Families who never joined are absent, and they correlate heavily with the families you most need to reach.
  • No custody information. A self-joined number is not marked as the custodial guardian, the emergency contact, or someone with no educational rights at all.
  • Staleness with no expiry. Nothing in a self-service join flow ever removes a number when a household changes.
  • Unusable consent. Consent given to one sender under one 10DLC campaign does not carry to another. You will be collecting it again regardless, so importing a list of unverified numbers buys you nothing but confidence you have not earned.

Take the message history, because retention and public-records obligations may attach to it. Leave the contact list.

The rebuild sequence

The order matters more than the tooling. Roughly eight weeks, most of it waiting rather than working.

  1. Weeks 1–2 — establish the roster feed. Get student, guardian and enrolment data flowing from your SIS. Be aware of our current limit here: Kastr has no native PowerSchool, Infinite Campus, Skyward, Aeries or Synergy connector. Real roster data is POSTed to /api/v1/roster/sync, which your team or ours scripts against your SIS's export. If you want a vendor-supplied native connector, we do not have one and you should weigh that.
  2. Week 2 — start 10DLC registration. Brand and campaign registration runs two to six weeks and it is the only genuinely immovable item on the plan. Everything else can compress; this cannot.
  3. Weeks 3–4 — reconcile, then discard. Compare the Remind export against the roster purely to find families in the app who are not in the SIS. Every one of those is a data-quality finding worth fixing at source. Then discard the export.
  4. Weeks 4–6 — validate and collect consent. Contact points enter with a validationState and a consentState recorded separately, plus source and rank, so an unconfirmed number is visibly different from a confirmed one rather than quietly identical.
  5. Weeks 6–8 — run both, then close the old one. Send the same low-stakes message on both platforms for two weeks and compare who was reached. Then turn Remind off on a stated date, because a channel that is still technically alive will be used.

The guardrail that exists because this goes wrong. A truncated roster export — a job that failed halfway, a file that got cut at a line boundary — looks to a sync engine exactly like a district that withdrew most of its students. Kastr's roster diff aborts with aborted_guardrail if more than 50% of active records would be withdrawn in a single run. It is a small piece of code and it is the difference between a bad Tuesday and a district with no reachable families.

Two questions that decide the timeline

Who owns the classes your teachers created?

Practically, the teacher does. If a teacher created a class on a free account with a personal email, the district has no administrative route to it and no ability to export it. This is worth establishing early because it determines whether your migration is a data exercise or a change-management exercise. In most districts we have talked to it is the latter, and the honest plan involves department heads and a stated cutover date rather than a script.

Do families have to opt in again?

For SMS, effectively yes. Consent and carrier-level opt-out records are tied to the registered sender, and a new platform means a new 10DLC campaign. Plan a consent campaign as part of the switch rather than an afterthought, and run it in the languages your families actually read. Kastr's composer will render the draft in several languages before you send it, and send-test-to-me delivers a [TEST]-prefixed copy to you alone, which is the cheapest way to catch a broken merge before 12,000 households see it.

One thing we will not overstate: our migration importer, which is MIT-licensed and runs without a Kastr account, validates an export bundle and produces a cryptographically signed receipt — a PDF with a per-file SHA-256 manifest, an HMAC signature over the bundle hash, and a ledger of every dropped record with its reason. It does not yet write those rows into a live tenant. That step is done with us during onboarding. It is built for the ParentSquare bundle format specifically; for Remind the reconciliation is a scripted comparison rather than a packaged import.

Questions people actually ask

Can we export our data from Remind?

Partially, and mostly at the class level rather than the district level. Message history and per-class contact lists can generally be retrieved by the account that owns the class, which for free-tier classes is the individual teacher, not the district. There is no district-wide export of teacher-created channels.

Who owns the classes teachers created in Remind, the district or the teacher?

In practice, whoever created the account. A class made on a free personal account is administered by that teacher, and the district has no route into it. That is the core governance problem with teacher-led adoption and it is why the switch is usually a change-management project rather than a data migration.

How long does it take to switch a district off Remind?

Plan eight weeks, driven almost entirely by A2P 10DLC brand and campaign registration, which takes two to six weeks and cannot be compressed. The roster work is a week or two. The teacher-adoption work is as long as your district's change process takes.

Will parents have to re-opt-in to text messages when we switch?

For SMS, yes. Consent and carrier opt-out records attach to the registered sender and do not transfer between platforms. Build a consent campaign into the plan, run it in your families' languages, and record consent per contact point rather than per person so a household with two numbers is represented accurately.

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.