Most migration horror stories share a root cause: content moved before the destination was governed. A nonprofit moves its mailboxes to Microsoft 365 in a weekend, declares victory, and then spends the next year discovering what came along for the ride — shared drives where everyone can see the finance folder, service accounts nobody remembers creating, and a security posture the cyber-insurance questionnaire politely calls 'in progress.'
It doesn't have to go that way. A migration is the single best security opportunity your organization will ever get, because it is the one moment when touching every account, every device, and every file is not disruption — it is the project plan. This checklist is how we structure that opportunity for the nonprofits and regulated teams we move: what to do before the first mailbox migrates, during the waves, and after cutover, so the tenant you land in is audit-ready from day one.
Before the migration: harden the empty tenant
The destination tenant should be your most secure environment before it holds a single file. Everything on this list is dramatically easier to do while the tenant is empty, because there are no users to disrupt and no workflows to break.
- ✓Stand up Entra ID conditional access first: require MFA for all users, block legacy authentication protocols, and define your named locations before anyone signs in.
- ✓Create a privileged access plan — separate admin accounts, no standing global admins beyond break-glass, and document who holds what as you create it, not after.
- ✓Configure Intune device compliance policies and enrollment so every device that touches migrated data is managed from its first sign-in.
- ✓Turn on Defender baselines for email and endpoints — anti-phishing, safe links, and attachment scanning should be waiting for the first migrated mailbox.
- ✓Review Microsoft nonprofit licensing eligibility now, because the plan you migrate onto determines which security features you own — many nonprofits qualify for granted or deeply discounted licensing that includes the security stack they assume they can't afford.
- ✓Inventory the source environment completely: every shared drive, every mailbox delegate, every third-party app with OAuth access. The things you don't inventory are the things that surprise you in week three.
The inventory step deserves emphasis. In Google Workspace environments especially, years of ad-hoc sharing accumulate into a permissions model nobody fully understands. The discovery pass that maps it is not overhead — it is the difference between a wave plan and a guess.
During the migration: move in waves, map permissions, keep rollback
The migration itself should be boring. If cutover weekend is exciting, something went wrong in planning. Three principles keep it boring:
- ✓Migrate in staged waves — a pilot group first, then departments in sequence — so a bad batch affects twenty people, not eight hundred.
- ✓Map permissions instead of flattening them. When a shared drive becomes a SharePoint site, access should translate one-to-one; migration is also the moment to revoke the access that should never have existed.
- ✓Keep rollback checkpoints for every wave, with the source system read-only but intact, so verification can compare against the original while it still exists.
- ✓Verify same-day: after each wave, confirm mailbox counts, spot-check folder access with real users, and test the workflows that matter — the board packet, the payroll export, the intake form.
- ✓Communicate per wave, not per project. Staff need to know what changes for them this week, in one short message, with one place to get help.
Security work continues during the waves: as each group lands, their devices enroll in Intune, their sign-ins come under conditional access, and their old direct-access paths to the file server are closed behind them. By the final wave, the legacy environment should have almost nothing left to protect.
After cutover: retire, document, and build the evidence folder
The weeks after cutover are where migrations quietly succeed or fail. The organization is functional, the pressure is off, and the temptation is to move on. Resist it — three tasks remain, and they are the ones your auditors will ask about:
- ✓Formally retire the legacy environment. A file server that is 'still there just in case' is an unpatched, unmonitored liability with a full copy of your data. Archive what retention requires, then decommission and document the date.
- ✓Close the access loop: review every permission the migration created, disable the migration service accounts, and confirm the privileged access documentation matches reality.
- ✓Build the evidence folder while the knowledge is fresh: conditional access policy exports, Intune compliance reports, the permissions mapping, the decommissioning record, and the incident-free cutover log.
That evidence folder is not bureaucracy — it is money. When the cyber-insurance renewal questionnaire asks whether MFA is enforced, whether devices are managed, and whether legacy systems are retired, you answer with exports instead of intentions. We have watched that single folder carry organizations through HIPAA audits and insurance renewals without a scramble, and it often pays for the migration by itself.
What this looks like in practice
When Volunteers of America Western Washington moved to Microsoft 365, staff and volunteers were spread across Google Workspace, on-prem file servers, and unmanaged laptops — while auditors were flagging access control gaps. The migration followed exactly this sequence: identity and device management first, then staged waves for accounts, devices, and files with rollback checkpoints, then formal retirement of the legacy estate. The result was 800+ people on a cloud-only tenant with conditional access enforced by default, onboarding time down from ten days to two, and every file share cut over inside four weeks — without downtime.
The pattern generalizes. Whether you are leaving Google Workspace, consolidating two tenants after a merger, or finally retiring the file server in the closet, the security checklist is the same: harden the destination before content moves, migrate in verifiable waves, and leave with the evidence in hand. Migration done this way isn't a risk to be survived — it is the fastest security upgrade a nonprofit can buy.