Microsoft 365 Migration Checklist for Beginners

A Microsoft 365 migration checklist helps you move email, files, SharePoint sites, Teams, users, and permissions with fewer surprises. For beginners, the checklist is not about doing everything perfectly on day one. It is about following a clear order so you do not miss the basics.

If you are new to migration, start with the broader guide: What Is Microsoft 365 Migration?. This article is the practical checklist version you can use while planning the project.

1. Define the migration scope

Before choosing tools or dates, decide exactly what is moving. A migration project can include many workloads, and each one has different risks.

• Email — mailboxes, calendars, contacts, shared mailboxes, and archives.
• OneDrive — personal files and user home drives.
• SharePoint — sites, libraries, lists, metadata, versions, and permissions.
• Teams — teams, channels, memberships, files, tabs, and related Microsoft 365 groups.
• Identity — users, groups, domains, guest accounts, and authentication rules.

Write down what is in scope, what is out of scope, and what will be handled later. This avoids confusion during migration.

2. Identify owners and stakeholders

Every important mailbox, site, file share, or team should have an owner. Owners help confirm whether content is still needed, who should access it, and whether it can be archived.

• Assign a business owner for each department or workload.
• Assign technical owners for identity, Exchange, SharePoint, Teams, and security.
• Confirm who signs off after each migration wave.
• Create a support contact list for migration issues.

3. Run a full inventory

Inventory tells you what exists before you move it. Without inventory, you cannot estimate effort, risk, timing, or storage needs.

• List users, shared mailboxes, distribution lists, Microsoft 365 groups, and guest accounts.
• Capture mailbox sizes, archive sizes, and inactive mailboxes.
• Scan file shares for file count, folder depth, large files, old content, and unsupported characters.
• List SharePoint sites, owners, storage, permissions, custom lists, and business-critical libraries.
• List Teams, channels, owners, members, guests, apps, tabs, and connected SharePoint sites.

4. Clean up before migration

Do not migrate unnecessary clutter. Old files, duplicate folders, inactive users, and unused sites increase cost and complexity. Cleanup is one of the easiest ways to reduce migration risk.

• Archive or delete obsolete data based on retention rules.
• Remove duplicate content where possible.
• Fix deeply nested folders and very long file paths.
• Remove unsupported file names or blocked file types.
• Confirm whether old permissions should be preserved or simplified.

5. Prepare the Microsoft 365 tenant

The destination must be ready before data moves. If licensing, identity, sites, and groups are not prepared, migration waves will fail or create user confusion.

• Confirm Microsoft 365 licenses for users.
• Verify domains and DNS planning.
• Configure identity, MFA, and conditional access requirements.
• Create target SharePoint sites, Teams, libraries, and OneDrive readiness.
• Review retention, sensitivity labels, DLP, sharing, and external access settings.

6. Plan permissions carefully

Permissions are one of the most common migration pain points. A file can migrate successfully but still be unusable if users cannot access it or if access is too broad.

• Map source groups to Microsoft 365 groups, security groups, or SharePoint groups.
• Identify broken inheritance and unique permissions.
• Decide where permissions should be simplified.
• Review external sharing and guest access.
• Validate permissions with business owners before go-live.

7. Choose migration tools

Choose tools after you understand your source, workload, and requirements. Common options include Microsoft native migration tools, SharePoint Migration Tool, Migration Manager, Exchange migration options, and third-party tools for advanced scenarios.

Tool selection should consider data volume, speed, permissions, versions, metadata, Teams support, reporting, retry behavior, and support requirements.

8. Run a pilot migration

A pilot migration tests your plan with a small group before you scale. Choose users who represent real scenarios but can tolerate a controlled test.

• Test a small batch of mailboxes, files, sites, or Teams.
• Validate data integrity, permissions, search, sync, and user access.
• Record errors and fix the process before production waves.
• Ask pilot users for feedback on communication and usability.

9. Communicate with users

Migration is also a user experience project. People need to know what is changing, when it is happening, and what they should do.

• Send a migration schedule before each wave.
• Explain what will move and what will not move.
• Tell users where to find files, email, Teams, and SharePoint content after migration.
• Provide support contacts and known issue guidance.
• Share short training links or quick-start instructions.

10. Migrate in waves

Do not move everyone at once unless the environment is very small and low risk. Migration waves make support easier and reduce business disruption.

• Group users by department, location, workload, or business priority.
• Avoid migrating critical teams during busy business periods.
• Track each wave with start time, end time, errors, owner sign-off, and open issues.
• Keep rollback or remediation steps documented.

11. Validate after each wave

Validation confirms that the migration worked. Do not rely only on a tool report. Check the user experience too.

• Confirm migrated item counts and data size.
• Check mailbox access, mail flow, calendars, and shared mailboxes.
• Check OneDrive sync, file access, sharing links, and ownership.
• Check SharePoint libraries, metadata, permissions, and search.
• Check Teams membership, channel files, tabs, and access.

12. Support users after migration

Post-migration support is where adoption succeeds or fails. Users may need help finding files, reconnecting sync, understanding new Teams structure, or using SharePoint properly.

• Keep a support window open after each wave.
• Track common issues and publish quick fixes.
• Offer short training sessions for Teams, OneDrive, and SharePoint.
• Review unresolved tickets before closing the project.

13. Decommission the old environment safely

Do not shut down the old system immediately. Keep it available for a defined validation period, then archive or decommission based on business and compliance requirements.

• Confirm business owner sign-off.
• Export or archive required legacy data.
• Remove old access paths after users have moved.
• Update documentation and support processes.
• Retire old servers, licenses, or third-party services only after validation.

Quick beginner checklist

• Scope confirmed
• Owners assigned
• Inventory completed
• Cleanup completed
• Licenses and identity ready
• Target sites, Teams, and libraries prepared
• Permissions reviewed
• Migration tool selected
• Pilot migration completed
• User communication sent
• Production waves scheduled
• Validation checklist completed
• Post-migration support ready
• Old environment decommission plan approved

The bottom line

A Microsoft 365 migration checklist keeps the project controlled. Start with scope and inventory, clean up what you can, prepare the destination, test with a pilot, migrate in waves, validate everything, and support users after go-live.

Successful migration is not just moving data. It is moving people, permissions, processes, and confidence into Microsoft 365.

---