Best practices for Microsoft 365 migration planning

What’s the secret to a migration that doesn’t turn into a total time suck? You guessed it—solid pre-migration planning. Keep reading to learn the best practices that set you up for success.

What's the difference between a chaotic migration and a smooth one? Well, it often comes down to what happens before any data is moved.  

Pre-migration planning is all about building a solid foundation for success. As the saying goes, “measure twice, cut once” – the more thoroughly you plan, the fewer surprises and setbacks you’ll encounter during the migration.  

Last time, I discussed M365 migration challenges and how to solve them. In this article, we’ll look at how to properly prepare for migration, covering the key planning steps that will save you time, reduce risk, and set your organization up for a successful transition. From aligning stakeholders on a clear vision to getting your target environment ready, careful planning ensures you hit the ground running when migration day arrives.

Watch the full session on-demand: Conquer the biggest Microsoft 365 migration challenges.

‍Define your vision and scope

Start by clearly defining why you're migrating to Microsoft 365 and what you hope to achieve.  

Maybe you want to enable better remote collaboration, retire aging on-premises servers, improve security, or consolidate disparate tools into one unified platform. Establishing the vision will help communicate the project’s importance to stakeholders and end users.  

Alongside the vision, determine the scope of the migration. Are you migrating just files and SharePoint sites? Email and calendars?  What about departmental apps or workflows tied to SharePoint or Teams that are critical to daily operations? Document which systems, workloads, and business units are in scope, and which are out of scope (for now). This will prevent scope creep later on. It’s also wise to set success criteria upfront. For example, a success criterion might be “All employees have access to the new environment and core content on day one, and legacy systems are decommissioned by Date X.” Such criteria give you concrete goals to plan toward.

As part of defining scope, assemble a project team and governance structure. Identify an executive sponsor who can champion the project and help resolve high-level issues or resource needs. Assign a project manager or migration lead who will coordinate all the moving parts. You’ll also want representation from various areas: IT operations (for infrastructure and identity planning), security/compliance (to ensure those requirements are met), and business unit representatives or power users (to speak for user needs and help with content decisions). Clearly define roles and responsibilities on the team – who will handle communication? Who manages the technical migration tool? Who will validate that content migrated correctly? Establishing this governance and team structure early ensures everyone knows their part in the plan.

Assess your current environment

With scope in mind, take a comprehensive inventory of your current environment. This means auditing what content and systems you have, and how they’re structured.

Key questions to answer at this stage include:

• What content do we have, and where is it? List out all repositories: file shares, SharePoint sites, Exchange mailboxes, PST files, and other SharePoint-related content maybe content in Google Drive or other platforms if you’re consolidating. Don’t forget less obvious data sources like Outlook public folders, or data stored in team collaboration tools that might be replaced by Teams.
• How much data is there? Estimate the volume (e.g., terabytes of files, number of sites, mailboxes and their sizes, etc.). This will influence the timeline and choice of migration method.
• Who owns or uses this content? Identify the departments or groups that “own” various sets of content. Knowing the owner helps later when deciding what to migrate and getting approvals to discard or archive things. Also, figure out user counts and if you have any inactive user data (files or mailboxes belonging to former employees) that might not need migration.
• What are the dependencies? Document any dependencies or integrations. For instance, do you have an intranet on SharePoint that links to specific file shares, or workflows that connect a legacy system to your documents? Understanding these dependencies aids in mapping existing functionalities to Microsoft 365 equivalents, ensuring continuity and user satisfaction.
• What are the customizations and special cases? Perhaps you have custom SharePoint web parts or InfoPath forms, or macro-enabled Excel sheets that rely on on-premises paths. List these out. Some on-premises features might not have direct cloud equivalents, so you’ll need a plan (maybe redesign a process, or use a third-party solution, or accept some changes in functionality).

Conducting this assessment can be a big task, but migration tools can help. For example, ShareGate’s inventory and analysis features (as part of its migration toolset) can scan your environment and produce reports of sites, size of content, unused or orphaned data, and more. (If you don’t have a tool yet, even a manual spreadsheet tracking these elements is better than nothing!) The outcome of this assessment is essentially your “migration inventory” and a clearer picture of the project’s magnitude.

Plan your information architecture in Microsoft 365

Now, shift focus to the destination: Microsoft 365. A critical planning step is to design the target information architecture and settings in Microsoft 365 before migrating anything. This means deciding how you will structure SharePoint sites, Microsoft Teams, OneDrive, and any other components relevant to your organization. For example:

• SharePoint structure: Determine if you will use a single intranet-style hub with multiple sites, or a more distributed model. Perhaps create a modern hub site for each department. Plan document libraries and how content will be organized (by project, by function, etc.). A well-thought-out SharePoint architecture will make content easier to find for users once they’re in the new system.
• Microsoft Teams vs. SharePoint vs. OneDrive: Clarify what content goes where. A common approach is: personal work documents go to OneDrive, ensuring efficient storage and access. team/project collaboration documents go into Teams (which behind the scenes use SharePoint team sites), and organization-wide or archival content might live in dedicated SharePoint communication sites. Decide if you’ll create Teams for certain groups as part of the migration (e.g., replacing old email distribution lists or network drive folders with a Team).
• Permissions and governance in the new environment: Planning your architecture goes hand-in-hand with planning governance. Determine who should have access to what in the new setup, leveraging Azure Active Directory for streamlined identity management. This is a chance to rethink permissions – maybe simplify overly complex permission schemes that existed in the old system. Identify if there are any sensitive sites or data that require special handling (e.g., HR or finance data that only a few should access). Microsoft 365 offers robust permission management; plan to use Azure AD groups, SharePoint permission levels, and Teams membership appropriately to mirror (or improve upon) the access controls from your current system.
• Configure tenant settings in advance: There are numerous settings in the Microsoft 365 admin center that could impact your migration or how users will experience the new environment. For instance, ensure you have all the necessary licenses provisioned for users who will migrate. Configure SharePoint Online settings like site storage limits, and check that sharing settings align with your security policies (e.g., will you allow external sharing of content by default or restrict it?). If you’re migrating email, decide on Exchange Online settings (like mailbox size limits, spam filtering, etc.) beforehand. Essentially, you want your Microsoft 365 tenant prepped and ready to receive content and users.

It’s also recommended to perform a test setup or proof of concept at this stage. If possible, create a small test Microsoft 365 environment (or just use a subset of your tenant if you’re migrating into a live tenant) to validate your planned architecture. For example, create a test SharePoint site and try moving a few sample documents, or set up a trial Microsoft Team and explore how files and permissions behave. This can validate your assumptions and uncover any adjustments needed in your plan.

Develop a detailed migration plan and timeline

With your inventory known and target design outlined, it’s time to craft the actual migration plan.  This plan outlines the step-by-step blueprint of how and when the migration process will occur. Key components of the plan include:

• Migration approach: Decide on the approach that best fits your situation. Will it be a big bang migration where everything switches over in one go (perhaps over a weekend)? Or a phased migration where you migrate in waves (by department or content type) over a period of time? Perhaps a hybrid approach if you need to run on-prem and cloud in parallel for a while. For instance, some organizations migrate email first, then files, then other services. There’s no one-size-fits-all—choose what minimizes risk for you. (If unsure, a phased approach with a pilot first is often safer)
• Timeline and schedule: Create a timeline that includes all major activities: content clean-up (I'll cover this in part 3 of this series), user communication milestones, pilot testing, the primary migration events, and post-migration follow-ups. Be realistic—account for the fact that data transfers can take significant time. It’s better to pad the schedule a bit for unexpected delays than to promise a switch-over date and miss it. If you have hard deadlines (like a contract end date for a legacy system or a company event that dictates timing), highlight those and plan backwards to ensure you’ll be ready. For each phase of migration, schedule the specific windows when data copy will happen and when the cut-over (when users start using Microsoft 365) will occur.
• Communication plan: As part of your timeline, include communications to users. For example, you might announce the migration project organization-wide 60 days in advance, then send periodic reminders or tips leading up to it. Plan for any downtime notifications (“The system will be read-only on X date from Y to Z time”), instructions for logging into Microsoft 365 for the first time, and who to contact for help. Good communication is so important that it should be considered a workstream in your plan, with its own schedule and owner.
• Training plan: Similarly, plan out how you will train users and prepare them. Maybe you’ll hold training sessions a week before cutover, or publish how-to guides on the intranet. Perhaps identify those power users and give them early access so they can become local experts. Include these activities in your plan so they aren’t afterthoughts.
• Risk management: Think through potential risks and have mitigation plans. What if the internet bandwidth during migration is lower than expected? What if a key team member leaves mid-project? What if certain files fail to migrate? For each major risk, have at least a basic mitigation or contingency plan. For example, if migration runs long, can you extend it to a second weekend? If files fail due to name length issues, have a script or tool ready to flag and fix those. Also, consider creating a rollback plan (even if you hope not to use it): if the migration has to be aborted, how will you ensure users can keep working on the old system until issues are resolved?

Document all these details in a Migration Runbook. This is a document that anyone on the team can reference. It lists each step, who is responsible, and the exact timing. For example: “Friday 5:00 PM – Disable editing on SharePoint on-prem (John) and start migration tool for SharePoint site collections (Alice). Monitor progress… Saturday 8:00 AM – Validate sample content in SharePoint Online (Team members X, Y).”  This level of detail, combined with automation, prevents confusion when the pressure is on during the migration weekend or phases.

Align stakeholders and finalize the plan

Before execution, review the migration plan with all key stakeholders (both IT and business). Getting a green light from department heads or leadership on the timeline and approach will ensure everyone is on the same page.

This is also a good time to set expectations. For example, clarify that some less-used services might not be migrated, or remind them that certain older features might work differently in Microsoft 365. Ensure that support staff or IT helpdesk are aware of the plan and ready for the increase in queries. Basically, no one should be caught off guard when you start executing. It can help to do a walkthrough or tabletop exercise with the project team: simulate the migration day steps and make sure every person knows their role and that all prerequisites are in place.

One more critical aspect: verify the technical prerequisites. By the time you’re done planning, you should have answers to questions like:

• Are all user accounts created in Microsoft 365 and licensed appropriately?
• Do we have the necessary hardware or VM to run the migration tool? Is the network path clear (firewalls, etc., allow data transfer to Microsoft 365)?
• If you plan to use a third-party migration tool, is it installed, updated, and have you done a trial run with it?

Addressing these before “go time” will save you from last-minute scrambles.

‍

Let’s wrap this up. Pre-migration planning might seem like a lot of work up front, but it truly builds the foundation for everything that follows. A detailed plan gives your team confidence and clarity, reduces the likelihood of errors, and increases the chances that your migration will come in on time and under budget. As the old project management adage goes, “failing to plan is planning to fail.” By investing in a solid plan, you’re actively planning for success.

‍