School District Email Migration: A K-12 IT Playbook

K-12 districts have one of the strangest migration profiles in IT. You have thousands of identities, a hard cut-over window dictated by the academic calendar, regulatory exposure on every student record, and a user base that will not read your change-management emails because half of them are on a beach. This guide is the playbook for getting it done before the bell rings on day one.

Why district migrations break differently than corporate ones#

You can run a 5,000-mailbox migration at a finance firm and the only people you bother are the IT team, a couple of compliance leads, and the helpdesk. The same migration at a district touches every teacher's classroom workflow, every parent's notification preferences, every coach's scheduling tool, and the food-service portal. Email at a district is not a productivity tool. It is identity.

That identity reaches into the SIS, the LMS, the rostering platform, Google Classroom, Canvas, Schoology, the substitute-teacher booking system, the bus tracker, and probably ten more vendor portals that nobody told you about. When you migrate the mailbox you also touch every one of those integrations. Plan for that or plan to firefight on day one.

The second wrinkle is the calendar. A corporate migration that slips two weeks is annoying. A district migration that slips into August is a board meeting.

FERPA, COPPA, and what they mean during a move#

FERPA — the Family Educational Rights and Privacy Act — protects education records that identify a student. Mailbox contents almost always qualify because they include grades, behaviour notes, IEP correspondence, and other records the parent has a right to access. When you migrate a student or staff mailbox, you are touching FERPA-protected records.

The practical FERPA controls during a migration are simple: only authorised personnel may handle the data, the data may not be disclosed to a third party without a permitted exception, and you must be able to evidence both. A migration vendor that processes mail on its own cloud needs to qualify as a "school official" under FERPA, which means you need a written agreement that pins down the scope, the retention, and the destruction.

COPPA adds a layer for students under 13. It limits what personal information online services may collect from those students and what notice you must give parents. If your migration tool sends telemetry, that telemetry must not include identifying student data. If the tool stores student mail on a vendor cloud, that storage must be covered by the same parental consent that authorised the original platform.

The compliance-driven migration guide walks through the cross-framework mapping for the controls you will reuse.

The summer-break cut-over window#

Treat summer like a manufacturing shutdown. You have a fixed window, a fixed deliverable, and a fixed re-opening date. Work backwards from the first day of staff in-service training, not from the first day of classes.

Most districts can use this template for a single-domain migration:

• Last week of school: lock new mailbox provisioning, freeze distribution-list changes, snapshot the source.
• Week 1 of summer: pilot batch with 20 IT and curriculum staff. Validate SSO, signatures, sending behaviour.
• Weeks 2 and 3: bulk staff batches by school, ten at a time. Run delta syncs nightly.
• Week 4: principals, counsellors, district office, special-ed coordinators. These are your sensitive mailboxes.
• Week 5: student mailboxes if in scope. Different team, different batch list.
• Week 6: final delta, decommission planning, documentation refresh.
• Week 7: buffer. You will need it.
• Week 8: back to school.

The migration project plan template gives you a starting Gantt for that breakdown.

Why batches go by school, not by department#

District staff identify with their building first. When a teacher returns to find their email not working, the question is "is Lincoln Elementary down?" not "is the social-studies department down?" Batching by school makes triage on day one obvious and lets you put a clear "Lincoln is migrating tonight, Roosevelt next week" message in front of the people affected.

Student mailboxes versus staff mailboxes#

Run them as two separate projects with two separate tools, even if the underlying mechanics are the same.

Staff mail is mission-critical, business-hours intensive, and full of FERPA-protected correspondence with parents. It needs full mailbox parity: folders, rules, signatures, calendars, contacts, shared mailbox membership.

Student mail is a different beast. It is often filtered heavily for inbound, restricted for outbound, attached to a managed Chromebook or Windows device, and reset every academic year. Many districts do not migrate student mail at all; they let the new platform create fresh accounts and archive the source mail in cold storage with a clear retention policy.

If you do migrate students, separate by grade band. Elementary students rarely need historical mail. Middle school students sometimes do. High school students, especially juniors and seniors mid-college-application, definitely do. Build batches to match.

Single sign-on with the rest of the classroom stack#

The first thing that breaks on day one is rostering. The mailbox migrated, the identity migrated, but Clever or ClassLink is still pointing at the old IdP and Canvas is rejecting logins. Plan the SSO swap as carefully as the mail swap.

Most districts already federate with one IdP that owns identity for everything. If that IdP is Google, your migration to Workspace for Education is essentially a re-roof job — the identity is already there. If you are moving from Workspace to Microsoft 365, you are also moving the IdP, which doubles the integration work.

The integrations to test before you cut over:

• Rostering platform: Clever or ClassLink push to LMS and other apps.
• LMS: Canvas, Schoology, Google Classroom, Seesaw — each consumes the rostering feed and the SSO assertion.
• SIS: PowerSchool, Infinite Campus, Skyward — usually the source of truth for student data.
• Substitute system: Frontline, AESOP — keyed off staff email.
• Library, food-service, transportation portals: usually keyed off email as the unique ID.

If you can keep the email address constant across the migration, most of these integrations re-bind automatically when the SSO swap happens. If you are changing the address, treat each integration as its own work item.

Workspace for Education versus Microsoft 365 Education#

Both platforms qualify for free or heavily discounted education plans. Both are mature, both have BAAs available, both have audit logs. The decision usually comes down to existing investment.

Workspace for Education Fundamentals is the no-cost tier, free for qualifying institutions, and includes Gmail, Drive (with shared storage caps), Calendar, Meet, Classroom, and Vault. Standard, Teaching and Learning Upgrade, and Plus tiers layer on advanced security, attendance, and originality reports. Districts already on Chromebooks default here because the device management is one console.

Microsoft 365 Education A1 is the no-cost tier and includes Exchange Online, Teams, OneDrive (with caps), and the web Office apps. A3 and A5 add desktop Office, deeper security, and Intune. Districts standardised on Windows imaging, with strong Active Directory or Entra ID investment, default here.

Walk through the Workspace migration guide or the Office 365 migration guide for the destination-specific mechanics. The K-12 layer in this post stays the same.

What the platforms charge for at scale#

The free tiers cover most districts. Where the cost shows up is storage. Workspace for Education has shifted to a pooled-storage model where the district gets a base allocation plus per-staff and per-student top-ups. Microsoft has the equivalent under A1's reduced OneDrive caps. If your district has been running Workspace for ten years and every staff member has 80GB of mail, that storage budget is not theoretical.

A migration is the right moment to right-size. Decommission inactive accounts, archive leavers to PSTs or MBOX files, and reduce the active mail footprint before you cut over. The destination will thank you.

Identity hygiene before, during, and after#

Districts accumulate accounts faster than they retire them. A migration is the cleanup moment.

Before the migration: pull a list of every active mailbox from the source. Cross-reference it with the HR system and the SIS. Anything that is not on either list is a candidate for deletion or archival. Anyone with multiple mailboxes (a teacher who also coaches and has a coach.smith@ alias) should be consolidated.

During the migration: do not silently fix identities. Document every change you make so the audit trail is clean. If j.smith@district.org becomes john.smith@district.org as part of a domain rename, write it down with a timestamp.

After the migration: run a 30-day reconciliation. Compare the destination tenant against HR and SIS again. Inactive accounts should be disabled, not deleted, for the rest of the academic year. Anything that is genuinely orphaned moves to archive.

Communication that actually reaches teachers#

Teachers do not read all-staff emails in July. They do read text messages from the district. They do read posts in their building's Facebook group. They do listen when their principal mentions it in the back-to-school meeting.

Run a three-channel communication plan:

• Email for the formal record and the link to documentation.
• SMS or push notification for the day-of and day-before reminders.
• Building-level in-person briefings during in-service week for anyone who needs hands-on help.

A short video, recorded by the technology director on a phone, beats a 20-page PDF every time. Keep it under three minutes. Show the new login page. Show what the new inbox looks like. Show where the old mail went.

The complete migration guide has the generic comms template; the K-12 spin is to add building-level deployment.

Decommissioning the old environment#

The old server stays up until you have cleared three things: the final retention requirement, the final eDiscovery request, and the final integration that quietly depended on it. Plan for at least one full academic year of read-only access. Some districts keep it three years because student records sometimes need to be produced after the fact.

For the on-prem decommission, archive the database files to encrypted cold storage. For a SaaS-to-SaaS migration, downgrade the source tenant to a single-mailbox plan and keep one admin account that can re-open it for an eDiscovery search.

A realistic district timeline#

A 2,000-staff, 15,000-student district can be migrated in a single summer if you have the team and the planning done by April. A 10,000-staff district needs two summers, with a phase break for any building that opted into a pilot mid-year.

Build the project plan in March. Run the pilot in May. Cut over in June and July. Use August for stabilisation. The migration timeline article describes the same shape for non-education projects; the K-12 specifics are above.

FAQ#