When your team outgrows scattered email accounts, a legacy file server, or a retiring file sync and share platform, a Microsoft 365 migration is rarely as simple as copy and paste. Mailboxes, shared files, permissions, identities, and licenses all have to land in the right place, in the right order, with proof that nothing was lost along the way. This post is a Microsoft 365 migration checklist you can actually work through. It walks each phase of a Microsoft 365 migration in the order it happens, from the inventory you take before touching anything to the verification you run after cutover. The goal is a move that your team barely notices on Monday morning, not a scramble of missing files and broken logins. NetSafe Solutions runs migrations like this for Charlotte businesses between five and one thousand users, and the steps below reflect how a careful Microsoft 365 migration is sequenced rather than a generic vendor wizard.
A Microsoft 365 migration is one of those projects where the work you do before you touch a single mailbox determines whether the move is smooth or painful. The phases below build on each other. Skipping ahead almost always means doubling back later, usually under time pressure, usually with a frustrated team waiting on you. Take them in order.
Before You Start: Build a Complete Inventory for Your Microsoft 365 Migration
You cannot move what you have not measured. The first phase of any Microsoft 365 migration is a complete inventory of what you have today, because every later decision depends on knowing the real scope rather than guessing at it. This is unglamorous work, and it is the part people most want to skip. Do not skip it.
Catalog every mailbox and mail object
Start with the mail. List every mailbox, every shared mailbox, every distribution list, and the approximate size of each. Size matters because volume drives timeline. A team with a handful of small mailboxes moves differently than a team with several users sitting on years of archived mail measured in tens of gigabytes. When you know the total volume up front, you can estimate how long the Microsoft 365 migration will take and whether you need to stage data anywhere along the way.
List the file repositories you are leaving behind
Files are usually the trickier half. Document every place files live today. That might be a local file server, individual OneDrive accounts, or a file sync and share platform such as Datto Workplace. Each of those sources behaves differently when you pull data out of it, and knowing exactly what you are migrating from tells you what tools and process your Microsoft 365 migration will need. A retiring platform with years of accumulated work inside it is a very different job than a tidy file server with a clear folder structure.
Document current identities
Write down how people sign in today and what identities exist. Identity is the foundation a Microsoft 365 environment is built on, and a Microsoft 365 migration that treats it as an afterthought tends to produce broken logins on cutover day. Knowing your current identity picture, including any accounts that no longer belong to active employees, lets you plan a clean sign-in experience instead of carrying old problems forward.
Note your line-of-business applications
Finally, hunt down the applications that quietly depend on your current setup. Any software that sends mail, connects to mailboxes, or relies on file paths that will change after the move needs to be on your list. A scanner that emails documents, a billing system that connects to a mailbox, a report that writes to a network path: these are the things that break silently after a Microsoft 365 migration if nobody flagged them in advance. Catch them now, while it costs you a note in a document rather than a help desk fire.
Choose the Right Microsoft 365 Migration Approach for Your Size
There is no single correct way to run a Microsoft 365 migration. The right approach depends on how many users you have, how much downtime you can tolerate, and how your data is structured. Picking the wrong one for your situation is how a move turns into a long weekend nobody enjoyed.
Cutover versus staged moves
The two broad approaches are a cutover style move, where everyone switches to the new environment at once, and a staged move that migrates groups of users over time. A cutover is simpler to coordinate and finishes faster, but it concentrates all the risk and all the change into a single window. A staged move spreads the work out, lets you learn as you go, and reduces the blast radius if something goes sideways, at the cost of running two environments in parallel for a while.
Match the approach to your size
Match the approach to your user count and your tolerance for downtime. Smaller teams often handle a single cutover well, because the volume is manageable and a short coordinated pause is easy to schedule. Larger teams usually benefit from staging, because moving hundreds of people in one shot leaves little room to recover if anything goes wrong. There is no prize for doing a Microsoft 365 migration the hard way.
Decide where data will be staged
Think carefully about where data lives during the move. A file migration usually leans on a large local drive to hold data in transit, but that is not always available or practical. When there is nowhere local to stage the data, secure cloud staging in Microsoft Azure can be the cleaner path for a Microsoft 365 migration. That approach moves the data from the old platform into secure cloud storage and on into SharePoint Online without needing room on a local disk, which matters when you are pulling years of files out of a platform you are retiring.
Plan for files no off-the-shelf tool fits
Some sources do not have a tidy off-the-shelf importer waiting for them. When a client needed to leave a file sync and share platform for SharePoint Online with no off-the-shelf tool that fit the job, the answer was a purpose-built Microsoft 365 migration process rather than a one-click wizard. If your source platform is unusual or your data is structured in a way the common tools do not handle, accept early that a careful, purpose-built process will serve you better than forcing the data through a tool that was never designed for it.
Get Licensing and the Tenant Ready
With your inventory in hand and an approach chosen, prepare the destination before any data starts moving. A clean target environment makes the whole Microsoft 365 migration smoother and saves you from cleanup work later.
Confirm the plan each role needs
Microsoft 365 comes in several plans, and it is easy to over-buy. Confirm the plan each role actually needs rather than purchasing licenses no one uses. Someone who only needs email and basic file access does not need the same plan as a power user who lives in the full application suite. Right-sizing licenses at the start of a Microsoft 365 migration keeps your ongoing cost honest and avoids paying for capabilities that sit idle.
Set up and verify the tenant
Stand up the tenant, verify your domain, and prepare the SharePoint Online and OneDrive structure before any data lands. Domain verification in particular needs to be done early because it touches mail routing, and you do not want to be sorting it out under pressure on cutover day. Getting the structure in place first means data arrives into a prepared home rather than a blank space you scramble to organize after the fact.
Map files into SharePoint Online thoughtfully
Decide how shared files map into SharePoint Online sites and libraries. This is your chance to improve on the old setup rather than recreate it. If you simply copy an old folder mess into a new home, you have moved the mess, not fixed it. A Microsoft 365 migration is the moment to think about how teams actually work, which groups need which content, and how sites and libraries should be organized to match. A little planning here pays off every day for years.
Establish admin accounts and roles
Set up admin accounts and roles so the people running the move have the access they need and nothing more. Over-broad admin access is a security risk, and a Microsoft 365 migration is exactly the wrong time to hand out more permission than necessary. Define who is doing what and give each person the access that matches their part of the job.
Make Identity and Security Decisions First in Your Microsoft 365 Migration
This is the section people most often push to the end, and that is a mistake. A Microsoft 365 migration is the natural moment to get identity and security right, because you are already touching how people sign in and what they can reach. Treat these decisions as part of the move, not a follow-up project that never quite happens.
Plan sign-in and enable MFA
Plan how users will sign in and enable multi-factor authentication (MFA) as part of the move. MFA is one of the single most effective protections you can put in front of an account, and rolling it out during a Microsoft 365 migration means your new environment is secure from day one rather than waiting for a separate initiative that keeps getting deferred. Build the expectation into your cutover communication so users know what to expect when they first sign in.
Decide what each user and application can access
Use the Microsoft 365 migration as a chance to tighten permissions. Decide what each user and each application is allowed to access, and resist the urge to carry every old permission forward just because it existed before. Years of accumulated access tends to drift well beyond what anyone actually needs. Migrating is a clean break that lets you grant access based on what people do today, not what they were given at some point in the past.
Review what should never be broadly shared
Once data sits in SharePoint Online, sharing becomes easy, sometimes too easy. Review which data should never be broadly shared and set your sharing defaults accordingly. Security starts with controlling what tools and people are allowed to see. Decide up front what stays tightly held and configure the environment so that broad sharing is a deliberate choice rather than the accidental default.
Map out conditional access and device expectations
Think about conditional access and what you expect from the devices people use. A new environment should not inherit the bad habits of the old one. Decide which conditions allow access and which do not, and set expectations for the devices that connect. Building these guardrails in from the start of a Microsoft 365 migration is far easier than retrofitting them onto an environment that has already settled into loose habits.
Run a Pilot Before the Full Microsoft 365 Migration
Never let the full cutover be the first time you actually run your Microsoft 365 migration process. A pilot is a small, controlled rehearsal that surfaces problems while they are cheap to fix and easy to contain.
Migrate a small test group
Choose a small test group of mailboxes and files and migrate them first. Pick people who represent the range of your environment, including a power user or two and someone whose work touches the trickier corners of your data. Moving this group first lets you watch the real Microsoft 365 migration process happen at small scale, where a problem affects a handful of people instead of the whole company.
Verify mail flow and shared resources
With the pilot users moved, confirm that mail flow, calendars, and shared resources behave as expected. Send mail in and out, check that calendar invitations work, and make sure shared mailboxes and resources are reachable. These are the everyday functions people notice immediately if they break, so prove they work before you scale up.
Confirm permissions and links survive
File permissions and shared links are a common casualty of a Microsoft 365 migration done carelessly. Confirm that they survive the move at pilot scale rather than discovering broken access across the whole company on cutover day. If a permission did not carry over correctly or a link points nowhere, you want to know it now, with a few files, not later with all of them.
Refine the runbook from what you learned
The pilot exists to teach you. Use what it shows you to refine the cutover runbook and timing. Maybe the transfer ran slower than expected and your window needs to grow. Maybe a particular file type needs special handling. Maybe a line-of-business application needed a reconnection step you had not anticipated. Every lesson from the pilot makes the full Microsoft 365 migration smoother and the timeline you commit to more accurate.
Execute the Cutover Without Surprises
The cutover is the moment everyone notices, so the goal is to make it boring. A well-run cutover is the natural result of all the preparation that came before it, executed in a clear order with communication and a fallback in place. This is the visible peak of the whole Microsoft 365 migration.
Communicate the window before the day
Tell every user about the cutover window and what to expect before the day arrives. Explain when it happens, what they should do, and whether there will be any short pause in access. Cover the new sign-in experience and the MFA prompt if you are enabling it. People tolerate a planned, communicated change far better than a surprise, and clear communication cuts down the wave of confused questions that otherwise hits on cutover day.
Migrate in the planned order
Execute the move in the order you planned and keep a record of what moved and when. Do not assume something migrated because you expected it to. A running log of completed steps means you always know where your Microsoft 365 migration stands, and if you need to pause or troubleshoot, you know exactly what is done and what is still pending. This record is also the start of the proof you will use during verification.
Update routing and reconnect applications
Update mail routing so messages flow to the new environment, and reconnect any application that depends on mailboxes or file paths. This is where the inventory you built at the start of the Microsoft 365 migration pays off. The scanner that emails documents, the system that connects to a mailbox, the report that writes to a path: each one gets reconnected to its new home. Working from your list means nothing gets forgotten and quietly broken.
Keep the old environment as a fallback
Do not cut the old environment loose the moment the new one is up. Keep it available, often read-only, until the new environment is confirmed working. A read-only fallback means that if something is missing or wrong, you can still get to the original data while you sort it out. Removing your safety net before you have confirmed the landing is how a manageable hiccup becomes a real problem.
Verify That Your Microsoft 365 Migration Arrived Intact
A Microsoft 365 migration is not finished when the data appears to have moved. It is finished when you can prove the data arrived intact. Verification is the difference between believing the move worked and knowing it did.
Confirm file counts and integrity against the source
Compare file counts and integrity against the source so you can certify that nothing was lost or corrupted. This is the standard a careful Microsoft 365 migration holds itself to: zero files lost, fully verified and certified, not a vague sense that everything probably came across. Checking the destination against the source, file by file where it matters, is how you turn a hopeful assumption into a documented fact.
Spot-check with real users
A progress bar reaching the end is not verification. Spot-check mailboxes, calendars, and shared libraries with real users opening real content. Have people from different roles open the files and folders they actually use and confirm everything is there and works. Real users notice things a status report never will, like a missing folder they rely on or a shared library that did not land where they expected.
Validate sign-in, MFA, and permissions across departments
Confirm that sign-in, MFA, and permissions work for a representative sample of people across departments. Different teams have different access needs, and a configuration that works perfectly for one group may have gaps for another. Test a cross-section so you know the new environment behaves correctly for the full range of how your organization actually works.
Document the verification results
Write down the verification results. Documented proof that file counts matched, that users confirmed their content, and that sign-in and permissions worked gives you a clear record that the Microsoft 365 migration is complete. This is not bureaucracy for its own sake. It is the evidence that lets you confidently decommission the old environment, and it is the answer if anyone ever asks whether something made it across.
Settle In: Training, Cleanup, and Ongoing Management
The Microsoft 365 migration is verified, but the work is not quite done. The last phase is helping your team adjust, retiring the old platform safely, and deciding how the new environment stays healthy over time.
Walk users through what changed
Take time to walk your team through what is different. Show them how to find files in SharePoint Online now that the old locations are gone, and how to search mail in Outlook effectively. A short, practical orientation prevents a flood of help desk questions and helps people get productive in the new environment quickly. The smoother the first week feels, the more the whole Microsoft 365 migration feels like a success.
Decommission the old platform only after sign-off
Retire the old platform only after verification is signed off and any retention requirements are met. Cutting it loose too early removes your fallback before you have confirmed the new environment is complete, and some data carries legal or regulatory retention obligations that you must satisfy before anything is deleted. When verification is documented and retention is handled, you can decommission the old platform with confidence.
Set a schedule to review the environment
A clean environment drifts over time if nobody tends it. Set a schedule to review licenses, sharing settings, and security configuration as your team changes. People come and go, projects start and end, and sharing settings that made sense at launch may not a year later. Regular reviews keep the environment matched to how the business actually operates rather than how it operated on cutover day.
Decide who owns ongoing management
Finally, decide who owns ongoing Microsoft 365 management after the Microsoft 365 migration. Without clear ownership, the environment slowly drifts: licenses go unreviewed, sharing loosens, and security settings fall behind. Whether that owner is someone inside your organization or a managed IT services partner who handles it for you, naming the responsibility is what keeps the environment clean instead of letting it slide back toward the same scattered state you just left.
Frequently Asked Questions
How long does a Microsoft 365 migration take?
It depends on the number of users, the volume of mail and files, and the approach. Smaller teams can finish a Microsoft 365 migration in days, while larger or staged moves run longer. A pilot helps you estimate the full timeline accurately before committing to a cutover date.
Will my team lose access during the Microsoft 365 migration?
A well-planned move keeps the old environment available, often read-only, until the new one is verified. Most disruption is limited to a short, communicated cutover window rather than a long outage.
How do I know no files were lost during the move?
Verification is the answer. By comparing file counts and integrity against the source and spot-checking with real users, you can certify that data arrived intact rather than assuming a progress bar told the truth.
Do I need to set up multi-factor authentication during a Microsoft 365 migration?
Yes, treat identity and multi-factor authentication (MFA) as part of the move, not a later project. A Microsoft 365 migration is the natural moment to tighten how people sign in and what each account can access.
What happens to my old file sync and share platform after the move?
You keep it until verification is signed off and any retention requirements are met, then decommission it. Cutting it loose too early removes your fallback before you have confirmed the new environment is complete.
Can a Charlotte MSP handle the whole Microsoft 365 migration for me?
Yes. NetSafe Solutions plans, executes, and verifies a Microsoft 365 migration for Charlotte businesses, including the identity, security, and cleanup work, so your team can keep working through the transition. Worked through in order, this Microsoft 365 migration checklist gives you a move your team barely notices and proof that every file arrived intact.