Microsoft 365 Migration Checklist for a Safer Move

A Microsoft 365 migration checklist should cover discovery, data cleanup, identity and domain preparation, licensing and security, pilot testing, communications, cutover, workload validation and post-migration support. Do not schedule the move until every critical dependency has an owner, completion evidence and a clear decision to proceed.

A migration is more than transferring email. It can change how people sign in, access files, use calendars, collaborate in Teams and connect business applications. Use six phases: assess, clean and prepare, choose the method, pilot, cut over, then validate and support.

For a small or medium business, this work may involve an owner, internal administrator, migration technician and representatives from critical teams. Microsoft 365 migration planning should include configuration, testing and user communication as well as the technical transfer itself.

Microsoft 365 migration checklist at a glance

Use this table as the project tracker. Record the owner, status, evidence and decision for every phase. A task is not complete because someone says it is done. Retain a report, export, test result, approval or screenshot that proves the relevant condition.

Assess the starting environment before choosing a method

Document the systems that exist today, not only the systems you want after migration. The source environment determines the migration method, testing required and whether users can work during the transition.

Build a complete inventory

• People and accounts: Employees, contractors, former users, service accounts, administrators and users with multiple addresses.
• Email: Mailboxes, aliases, shared mailboxes, groups, forwarding rules, calendars, contacts and archives.
• Files: File servers, network shares, personal folders, SharePoint sites, cloud storage and data that must not move.
• Devices: Desktops, laptops, phones, tablets, shared computers and printers.
• Applications: Accounting, payroll, CRM, line-of-business software, scanners, backup, email relay and devices that send mail.
• Identity and network: Directory, domains, DNS provider, internet connection, authentication, administrator access and remote access.
• Permissions and dependencies: Owners of mailboxes, file shares, teams, sites, applications and privileged accounts, including external sharing.

For every item, record its owner, business importance, source, destination, migration treatment and required test. Mark unknown information as a risk with a named person responsible for resolving it.

Classify the migration scope

• IMAP email: Messages may transfer, but calendars, contacts, rules and shared-mailbox behaviour need separate decisions and tests.
• Hosted Exchange: Map mail, calendars, contacts, aliases and permissions, with attention to coexistence and domains.
• On-premises Exchange: Include servers, connectors, directory synchronisation, certificates, mobile access, backup, firewalls and legacy applications.
• File shares: Decide whether content belongs in SharePoint, OneDrive or another approved location. Permissions, paths and ownership are central risks.
• Mixed environment: Plan each workload separately. Email may move first while a file server remains temporarily and devices are enrolled later.

Clean data and define ownership before the move

Cleaning data before migration reduces avoidable transfer work and prevents old permissions, accounts and files becoming permanent cloud problems. Do not delete material simply because it looks old. Assign an owner and record the decision.

• Disable or remove inactive accounts after an approved business decision.
• Identify duplicate, obsolete and oversized files, then obtain a data owner’s decision.
• Assign an owner to every shared mailbox, group, SharePoint site, Teams team and shared folder.
• Review aliases, forwarding rules, automatic replies and addresses used by applications or equipment.
• Remove unnecessary external sharing and record legitimate collaborators.
• Review inherited permissions, broad groups, anonymous links and excessive privileges.
• List legacy applications, operating systems, scanners, printers and devices dependent on the existing mail system.
• Document retention, archive and records requirements as business decisions.

Completion evidence should include an approved user and mailbox list, file ownership register, permissions exception list and systems that will not move. If a critical owner cannot be identified, the item is not ready.

Choose licensing, identity and security controls

Licensing should follow each user’s needs, not a one-size-fits-all purchase. Map users to email, desktop applications, mailbox size, collaboration, device management, security and compliance requirements, then document the reason for each assignment.

Identity and access readiness checklist

• Verify the business domain and who controls its DNS records.
• List required administrator roles and assign the minimum access needed.
• Create or verify user accounts, addresses, aliases, shared mailboxes and groups.
• Prepare recovery methods and a protected emergency administrator path. Test it independently of the ordinary account and device.
• Plan multifactor authentication, sign-in policies, device access and conditional access.
• Decide whether devices remain managed as they are or are enrolled in the new environment.
• Test sign-in from office, remote and mobile devices where applicable.
• Record DNS changes, propagation effects and the authorised change owner.

Do not enable a security policy for everyone before testing its effect on administrators, service accounts, shared devices and business applications. A secure design that blocks recovery is not migration-ready.

For larger organisations, preparation should also cover mailbox migrations, licence clean-up, tenant configuration and sign-in security.

Choose the migration approach for your source environment

The right approach depends on the source platform, number of workloads, need for coexistence, identity complexity and acceptable disruption. A cutover can suit a small, self-contained environment. Staged or hybrid planning is more useful when teams, sites or systems must operate across both environments.

Choose staged migration when departments can be separated, coexistence is needed or each change window should be smaller. Consider hybrid planning when on-premises identity or services must remain active. A single cutover can suit a well-understood small environment, but should not be chosen merely because it appears faster.

Document the source, destination, workloads, coexistence period, DNS sequence, user groups, freeze window and rollback point for every option.

Prepare users, devices and support before migration day

Technical readiness and user readiness are separate gates. A correctly configured tenant does not help users who do not know their new sign-in process, file locations, mobile access method or support route.

• Tell users what is changing, when it changes and what action they must take.
• Give clear sign-in instructions without sending passwords or recovery codes in ordinary email.
• Explain changes to Outlook, mobile mail, OneDrive, SharePoint, Teams, shared calendars and file paths.
• Identify remote, mobile and accessibility support needs.
• Explain suspicious sign-in prompts, unexpected MFA requests and lost-device reporting.
• Publish support hours, urgent escalation and ticket requirements.
• Prepare ticket categories for sign-in, mail flow, files, permissions, mobile access, Teams and applications.
• Set a change freeze for accounts, mailbox rules, file structures and applications.

A complete plan should include security awareness training so staff can identify suspicious sign-in prompts, protect accounts and report problems. Test the reporting route before migration day.

Run a pilot before the wider cutover

A useful pilot represents the difficult parts of the business, not only the easiest mailbox. Include ordinary, remote, mobile, shared-mailbox, calendar-sharing, administrator and critical-application users where possible.

Pilot acceptance tests

• Sign in with MFA from desktop, browser and mobile device.
• Send and receive internal and external email with replies and attachments.
• Open a shared mailbox, calendar and contacts with intended permissions.
• Create, share and edit a test file in the planned SharePoint or OneDrive location.
• Use Teams conversations, meetings, files and membership.
• Confirm mobile synchronisation, notifications and device access.
• Test applications, scanners, printers and automated mail processes.
• Confirm that users can report problems and support staff can assign and resolve tickets.
• Confirm administrator recovery access and security-policy operation.

Record the user, time, expected and actual result, evidence, defect owner and retest date. Scale only when critical tests pass, defects have an accepted workaround or decision, support instructions work and the migration lead approves the move.

Stop and investigate if administrators cannot recover access, mail flow fails, critical data is missing, permissions expose sensitive information, mobile access is unusable or a critical application cannot operate. A failed pilot is evidence to correct the design before expanding it.

Plan cutover, change control and rollback

A cutover runbook should let another competent person follow the sequence without guessing. Put times, owners, dependencies, actions, expected results and escalation contacts beside each task.

1. Confirm final user, mailbox, file, device and application scope.
2. Verify the latest backup or export and record restoration steps.
3. Open the approved change window and freeze changes.
4. Notify users, managers, application owners and support staff.
5. Complete final synchronisation or export and retain the report.
6. Apply domain, DNS, connector and authentication changes in order.
7. Smoke-test administrator access, internal and external mail, shared mailboxes and critical applications.
8. Obtain the business and technical go decision.
9. Send sign-in instructions, support details and known limitations.
10. Start the hypercare log and monitor tickets, authentication, mail flow and workload errors.

Define postponement and rollback triggers before the window: failed external mail flow, missing critical data, blocked administrator access, exposed restricted information or an unavailable critical application.

Rollback is not always a simple reversal after new mail or files are created. Document what can be reversed, what needs manual reconciliation, who authorises postponement and how users will be told.

Validate every workload after migration

A successful test email does not prove the migration worked. Validate each service users depend on and obtain sign-off from the relevant business owner.

Also check permissions, external sharing, aliases, forwarding, device enrolment, backup jobs and administrator access.

Run hypercare and optimise the new environment

Hypercare is the planned support period after cutover for access, synchronisation, permissions and workflow issues. Give it a coordinator, daily review point, escalation rules and exit criteria.

• Triage sign-in, missing-data, mail-flow, mobile and permission problems first.
• Separate training questions from technical defects and create answers for repeat questions.
• Track each issue by workload, severity, owner, workaround, fix and retest result.
• Review authentication alerts, backups, device enrolment and application errors.
• Recheck external sharing, administrator roles, shared accounts and unused access.
• Document configuration changes, unresolved risks and support decisions.
• Close hypercare when critical workloads have sign-off, high-severity issues are resolved or accepted and normal support can handle remaining requests.

Useful success measures include passed workload tests, resolved critical defects, confirmed access, completed device enrolment, functioning backups and a declining migration-ticket queue.

When should you use migration planning or hands-on support?

Internal staff may manage a straightforward email move when the source is documented, the workload is narrow, administrator access is secure and recovery has been tested. Specialist planning is sensible when several workloads or systems must change together.

• Multiple domains, sites, tenants or identity systems are involved.
• There is on-premises Exchange, directory synchronisation or legacy software.
• File permissions, external sharing or ownership are unclear.
• Devices need replacement, imaging or enrolment.
• No emergency administrator or tested recovery process exists.
• A failed cutover would interrupt payments, bookings, payroll or customer service.
• The internal administrator cannot run a controlled change window alongside daily support.

TechMate supports Melbourne businesses with Microsoft 365 configuration, device deployment, backup and cybersecurity work. Its on-site approach uses plain-English explanations.

Frequently asked questions

Do I need a cybersecurity assessment if we use Microsoft 365 only?

Yes. Accounts, administrator roles, MFA, devices, sharing, forwarding, applications and backups all affect risk. An assessment should examine tenant configuration and real usage, not assume cloud hosting removes the need for security controls.

Can a small business migrate to Microsoft 365 without an internal IT team?

Yes, if it has a clear inventory, accountable project owner, secure administrator access, tested recovery and time for user support. External planning becomes more valuable when files, devices, legacy applications or complex permissions are included.

What should happen if the pilot migration fails?

Pause the wider migration, preserve test results and classify the failure. Fix the underlying issue, retest the same user scenario and obtain a new written go decision.

How long should Microsoft 365 post-migration support last?

Continue until critical tests pass, high-severity defects are resolved or accepted, users can obtain help through the normal route and monitoring shows stability. Define exit criteria instead of choosing a fixed number of days.

Final next step

If your checklist exposes unknown owners, legacy dependencies, unclear permissions or an untested recovery path, resolve those risks before booking a cutover. TechMate IT Support provides business IT support for Microsoft 365-related work and can help you plan the appropriate next step.