Microsoft Cloud ebook · 5-page PDF

Microsoft 365 Migration Playbook

March 2025 · Big Sky Dynamics

Step-by-step playbook for migrating to Microsoft 365 with zero downtime and minimal disruption.

Phase 0: assess and decide

Inventory mailboxes, data volumes, file shares, line-of-business apps, devices and identity sources. Decide the target tenant model, the identity model (cloud-only, hybrid, federated) and the migration method per workload before signing anything.

Agree the success criteria: no lost mail or files, no unplanned downtime for a business day, and a named rollback for each wave. Write them down; they become the acceptance test.

Phase 1: identity first

Everything depends on identity. Build the user and group model, clean up stale accounts, and decide how authentication works before you move a single mailbox. If you are going hybrid, validate directory sync and password policy in a pilot group; if cloud-only, plan the cutover of authentication carefully because it is the one step users notice instantly.

Enable multi-factor authentication for administrators before migration and for users during it. It slows the cutover slightly and prevents the most common compromise afterwards.

Phase 2: mail migration

Prefer a coexistence window with mail flow both ways over a big-bang switch. Migrate pilot users, then waves grouped by department and mail volume. Keep the same primary addresses, and decide how long the old system stays authoritative for calendar and free/busy.

Test the edge cases deliberately: shared mailboxes, distribution lists, resource rooms, delegation, public folders and the applications that send mail through the old server.

Phase 3: files and collaboration

File migrations fail on permissions, not on data volume. Export the permission tree, simplify it before migration, and map it to SharePoint or Teams structure. Remove duplicate and stale data rather than copying it into the new estate.

Train on the workflows that change: sharing instead of attachments, version history, and co-authoring. A file migration with old habits just relocates the problem.

Phase 4: devices, security and operations

Enroll devices into management before mail cutover so users get the new apps and the security baseline together. Apply conditional access, device compliance and data loss prevention as part of the rollout, not as a later project.

Land the operational basics: backup and retention, licence assignment, help-desk routing, and an owner for each Microsoft service you turn on.

Phase 5: decommission and improve

Retire the old platform on a dated plan with a short read-only window, then remove connectors and legacy DNS records. Publish a short post-migration review: what broke, what users complained about, and which licences are actually used.

The migration is the beginning of the operating model, not the end. Review licence usage and adoption quarterly, and keep the security baseline current as Microsoft changes defaults.