Microsoft 365 tenant migration: a planning checklist

A Microsoft 365 tenant-to-tenant migration is a collection of related changes. Moving a mailbox does not establish that files, Teams content, devices and connected applications have moved successfully.

Use this checklist to agree the scope with whoever will carry out the migration. It is a planning guide, not a command-by-command procedure for a production tenant.

Inventory what must move

List users, shared mailboxes, delegates, groups, domains, OneDrive accounts, SharePoint sites, Teams, devices and applications that depend on the existing tenant. Include scanners and other equipment that sends email, along with third-party integrations.

For each item, record an owner, business impact, chosen migration method and acceptance check. Verify current tool support for each workload. Do not assume a product called a migration tool transfers every setting, permission or application.

Have the administrator validate identity and licensing

For Microsoft’s native cross-tenant mailbox migration, target users must be prepared as MailUsers with the required attributes. The source ExchangeGUID and required X.500 addresses are part of that preparation. Licence assignment must follow Microsoft’s sequence; assigning an Exchange licence before the target is prepared can create an unwanted mailbox.

The native process requires cross-tenant migration licensing and appropriate Exchange subscriptions. Microsoft also states that mailboxes on hold cannot be migrated using this process. Resolve retention and preservation requirements with the authorised owners; removing a hold merely to make a migration proceed is not a routine workaround. See Microsoft’s current cross-tenant mailbox migration requirements.

Agree a cutover plan and stopping point

Ask for a written sequence covering identity preparation, data movement, domain dependencies, DNS changes and user sign-in. Identify the person authorised to approve the change and the person responsible for each step. Agree the point at which the team will stop if a prerequisite fails.

Record the existing DNS settings and who controls them. Plan domain removal and attachment with the administrators of both tenants, following the selected migration method. Do not cancel the old service before the agreed validation and retention work is complete.

Keep MFA and access protections in the plan throughout. Any necessary exception needs a specific reason, limited scope, an owner and a removal check; disabling security broadly is not a standard migration step.

Pilot representative work

Choose a small pilot that reflects actual dependencies, such as a user with delegated mailbox access or shared files. Agree the scope with the migration team; there is no universal pilot size or project duration based only on user count.

• Check internal and external email delivery and replies to older messages.
• Test calendar access and delegation used by the pilot group.
• Open shared files and verify permissions with the intended users.
• Check required Teams functions and application connections separately.
• Verify sign-in and device readiness without bypassing security controls.

Close out with business acceptance

Record outstanding issues, support contacts and the manual arrangements for any interrupted process. Verify backup and retention arrangements for the destination, review temporary migration access and hand over the updated system records. Agree when the old services can be retired, based on evidence rather than the migration tool’s completion percentage alone.

Discuss your Microsoft 365 migration with hostme.ie. We can review business email, DNS and user-support requirements and agree the appropriate scope of help.