Migrating to Microsoft 365 is a major shift, whether you’re moving from on-premises infrastructure, transitioning from another cloud platform, or navigating a tenant-to-tenant migration.
Drawing on my experience as a Microsoft 365 migration consultant, this post shares practical, real-world insights to help you better plan for Microsoft 365 migration projects. I’ll cover considerations that can often be overlooked, but are essential for a smooth transition. My goal is to equip you with a deeper understanding of what it takes to navigate a successful Microsoft 365 migration.
Microsoft 365 migration project considerations
While different migration types present unique challenges, there are a handful of considerations that are important for effective planning and execution across all Microsoft 365 migration scenarios.
Choosing a migration partnerAttempting a Microsoft 365 migration without specific consulting experience is risky. Even if someone on your team has done one migration, it’s not enough. Hiring a specialized company or consultant ensures you’re working with experts who are up to date with the latest cloud technology changes. Each environment has its quirks, and experienced technologists can troubleshoot and resolve issues more effectively when things go wrong.
Administrative access to source and target environments
As a migration SME, I’ve seen how projects are negatively impacted when we do not have adequate administrative access to the source and target environments. It takes more time to perform the work, often doubling the efforts in cases where everything needs to be performed over screen share.
When working with cloud migration tools, you can provide admin consent to the tool itself and then give the migration SME access to the tool to perform the migration. This is better than doing everything over screen share, but it creates a frustrating experience for everyone post-migration as SMEs cannot directly troubleshoot issues or perform required tasks. A great way to provide temporary administrative access and audit administrative actions in Microsoft 365 is through Privileged Identity Management in Azure.
Finally, ensure that Conditional Access policies and network configurations align with migration needs by reviewing migration documentation. Avoid unexpected delays by confirming access requirements and tool permissions before starting.
Configure service accounts with display names such as “Microsoft 365 Migration,” to avoid confusing end users – these account names will show up in various places in Microsoft 365. Use the “.onmicrosoft.com” domain for service accounts to reduce post-migration reconfiguration.
Migration data and complexity
Volume of data and quantity of objects (e.g., # of users, # of SharePoint sites) should be accounted for in migration, but a common oversight is the complexity of the environment(s) to be migrated.
The complexity of an environment can significantly change the scope of a migration. Use tools to scan source and target environments for objective information; don’t rely on discovery discussions and manual review.
To be better prepared, consider the following points:
Scheduling and Approach:
- Decide between a “big bang” migration (i.e., all at once) or a phased approach (e.g., per department) based on user quantity and helpdesk capacity.
- Even when anticipating a straightforward migration, always plan for some after-hours work. At minimum, domain cutover should be performed after hours to ensure minimal disruption to business operations.
- Migrate data after hours if users to be migrated are active in both environments.
Tenant-to-Tenant Migration for Mergers and Acquisitions
- If guest users are invited to the source environment, confirm whether they need to be invited to the target tenant and whether the target tenant’s policies may prevent guest permissions from migrating properly (e.g., if SharePoint sites do not allow external users).
- Check if users from one tenant are guests in the other, and whether there is any data or permissions associated with the guest accounts that users may expect to be migrated to their internal accounts, as this is not part of typical migration efforts.
- Plan for communication with all involved companies; anticipate that communication may take additional time and effort.
Specialized Environments:
- DoD, GCC, EDU tenants, and multi-geo environments have unique functionality.
- Customers in these scenarios have additional compliance requirements. Migration may require specialized handling or additional tools to remain compliant.
End User Support and Migration Remediation:
- Ensure the helpdesk and support team can handle training, support tickets, and post-migration issues. Consider help desk augmentation for large migrations.
- Prepare documentation, FAQs, and self-serve support resources.
Migration piloting
Running a migration pilot helps you understand both the process and its potential impact on end users. Testing migration strategies on a smaller scale reveals potential challenges and provides insight into the time, resources, and support required for a full rollout.
Selecting the right pilot groups is key: Ideally, pilot users should represent a variety of user types and migration scenarios within the organization so you’ll get a clearer picture of how the migration might affect different parts of the business.
Limitations with IMAP/POP mail migration
Many traditional and cloud-based mail providers use IMAP and POP protocols. Be aware of the limitations when migrating from IMAP/POP to Exchange. A key limitation is that IMAP/POP migration does not support password migration; in other words, users will need to create new passwords in the target environment. Another consideration is that Microsoft 365 introduces more advanced authentication methods, such as multi-factor authentication, which may not have been in place in the source environment; this is another change to prepare users for.
Domain considerations
Keep in mind that a domain can only be verified in one tenant at a time.
If migrating a domain, consider where else it is used and removing references in advance where possible; during cutover, the domain can fail to disconnect from source tenant and may result in last-minute scavenger hunting when you are down to the wire. A proactive premier support ticket is recommended when performing a domain migration along with a large-event migration, especially if occurring over a weekend (when support may be more difficult to get).
If a domain fails to remove from the source and/or verify in the target, even though it appears to be disassociated with all identities, escalation may be required. In previous projects I have been told to expect a 48-hour resolution time (although it’s always happened sooner, plan for the worst and hope for the best).
For phased migrations, using a temporary domain can streamline the coexistence period by allowing uninterrupted access and communication flow across both tenants. Configure the temporary domain in the target environment to handle routing and forwarding during the migration. This setup helps avoid conflicts with the primary domain and reduces dependency on immediate domain verification, easing the pressure on cutover timing. Once the phased migration is complete, you can transition the primary domain from the source tenant to the target as the final step.
Cutover must happen outside of working hours or in the case of an organization with multiple working time zones, during a date and time that is least disruptive to the organization.
Migration batch planning
I like to identify VIP users (typically, leadership teams, users working on critical business processes – any users who require white glove support) so that they and the data they work with can be prioritized during and after migration. It is also helpful to identify which files, folders, and/or sites are most frequently accessed by the business in general to prioritize accordingly.
Keep in mind that data can’t just move in huge chunks at a time; there are limitations to how much can move at once, which are reinforced on Microsoft’s side by throttling:
- If possible, migrate only necessary file versions, as bringing all versions can slow migration. For example, 5 to 10 major versions is a practical limit. It may be the case where most sites and users can migrate 5 to 10 major versions, while VIPs and sites with sensitive information require full version history.
- For mail migration, migrate recent emails first (e.g., past three years), then transfer older mail later to ensure that, if migration timelines are not met, there is minimal disruption for users.
Keep in mind that Microsoft’s first-party migration tools are all or nothing and cannot support this approach.
Change freezes
Enforce a change freeze period to prevent data discrepancies or duplicates. While incremental syncs can support some updates, users should avoid significant structural changes until after migration cutover. Incremental syncs may support delete operations in Exchange but delete operations in SharePoint and OneDrive are not supported by major migration tools. If files and folders are moved or deleted in SharePoint or OneDrive between the initial sync and the migration cutover, this may result in unwanted files and folders in the target, including duplicate files and folders, where one version is out of date.
Visual branding
Incorporating theming into migration efforts makes the target environment feel more familiar/welcoming to users. I wrote a blog post about visual branding considerations for tenant-to-tenant migrations, but the items I talk about in the post are also applicable to other types of migration.
Migrating to Microsoft 365 is a big change for users, even in tenant-to-tenant migration projects; I try to minimize unnecessary changes that may add additional challenges for users, and instead plan those changes for later, when users are comfortable in the new environment.
This may be a controversial take, but sometimes this includes restructuring information to a more ideal architecture. This is more than a visual change, but it very much relates to how users navigate. If users are already going through a massive change in the technology they are using, changing the way the information is structured is only going to make things more difficult for everyone and increase time spent by users and the migration support team.
Migration tool documentation
Finally, I can’t stress this enough: Read the manual for the migration tooling that you use. Whether you’re scoping a migration or performing one, reading the manual is crucial, from planning to execution to troubleshooting.
I get that it’s a lot of text to read, but having a solid understanding of how your migration tools work will make the entire process smoother and save time in the long run.
If you prefer listening to learn, leverage your operating system’s text to speech capabilities to read the documentation out loud to you.
For quickly finding answers, putting together requirements, or trying to understand how something works, I find it helpful to have Copilot open in the Edge sidebar to prompt in the context of a page. For example:
- “Using the information on this page, what are the high-level steps for Teams chat migration?”
- “Using the information on this page, please list all service account requirements in a table.”
- “Can you explain the File Versions section on this page in simpler terms and also use an analogy to help me understand?”
To ensure you have the most accurate and up to date information, read the release history for migration tools as well. There have been a handful of times, with various migration tools (including Microsoft’s first-party tools), where I’ve looked through the update log and found crucial information that was not yet in the product’s documentation.
Even if you’ve recently worked on a migration project, tools and feature sets change often; staying on top of these changes and how they impact you will minimize surprises during migration.
On-premises to Microsoft 365 migration
Whenever you’re migrating from on-premises infrastructure to Microsoft 365, the migration requires decisions about identity and workstation configurations. Will identities be synchronized from on-prem Active Directory (AD) to Entra ID or will they migrate to the cloud? Account for any custom AD attributes early. It’s essential to map and retain key Exchange and AD attributes like email aliases, display names, and group memberships to maintain mail flow and access continuity. Consider where else identities may be used for authentication.
Endpoints will be affected when migrating from on-premises infrastructure to Microsoft 365. Note whether workstations they are domain-joined, hybrid-joined, or Entra-joined, as each can require a different approach, and plan for user profile migration. Watch for users running outdated or unsupported Office versions. Mobile devices are another important area to consider.
For Exchange migration, implementing only Exchange Online Protection (EOP) can leave gaps. Adding Defender for Office 365 or another third-party mail security solution enhances email protection by adding advanced threat detection and response, including safeguards against phishing, malicious links, and harmful attachments. Consider mail routing changes that may be required or whether you require centralized mail routing.
When migrating from on-premises file shares to OneDrive for Business and SharePoint Online, as a rule of thumb, home drives should migrate to OneDrive, and shared drives should migrate to SharePoint. Moving from file shares to cloud collaboration tools can be a big adjustment for end users, and I find it’s helpful to tell them that OneDrive is their “new home drive” and SharePoint is their “new file share”. A lot of users habitually save items to their desktop, documents, and downloads; enabling Known Folder Move as a policy backs up those folders to OneDrive.
When migrating from SharePoint on premises to SharePoint Online, take note of unsupported features and custom solutions, including workflows and automation.
Evaluate whether to rebuild, replace, or simplify each solution in the new world of SharePoint Online. For users who really struggle to get out of File Explorer, coaching them on how to sync SharePoint document libraries can be a game changer; if you do, make sure to teach them how Files on Demand works, too, so that they don’t end up running out of local storage.
Non-Microsoft to Microsoft 365 migration
Migrating from non-Microsoft platforms to Microsoft 365 brings additional considerations for data compatibility, user adaptation, and system functionality.
When migrating from non-Microsoft platforms (such as Google Workspace or Slack) to Microsoft 365, plan for extra effort in determining which items are supported for migration and how supported items are migrated to Microsoft 365, and make sure to plan for end user training.
Some items may be completely unsupported in Microsoft 365 and will not migrate properly. Thankfully, in cases where the data must be kept for legal/auditing purposes, I’ve found there is usually some way to export it even if it cannot be recreated in the target environment. Take note that with Slack migration, what is supported for migration depends on your service plan.
On the other hand, some product features, while technically “supported” for migration, function very differently in Microsoft 365. For example, labels in Gmail may convert to folders in Outlook during migration; for users who are unaware, this is a confusing experience and may even seem as though emails are missing from their inbox. It’s important to have a site architecture plan for Google shared drives; depending how they are used, a group of shared drives may function best as individual sites or instead as document libraries within the same site. I recommend trying to keep a consistent framework for how information is architected in the target Microsoft 365 environment to minimize confusion and disruption to productivity.
I also tend to advise users who have migrated from Google to Microsoft to use the web versions of Microsoft Office applications as the experience is closer to Google Workspace (they’re using a web app in both cases). This is especially important for Outlook. I’ve heard endless complaints about how awful Outlook search is compared to Gmail search. Many people don’t know that there is a difference between the way search functions in the classic Outlook desktop app compared to the Outlook Web App (OWA). Gmail and OWA both leverage server-based search, real-time syncing, and relevance-based ranking for results. On the other hand, the classic Outlook desktop app may use cached mode for search (limiting the scope of search to a subset of items that are locally stored, and excluding older and infrequently accessed items), syncs on a periodic basis, and doesn’t provide search results based on relevance. The New Outlook desktop app strikes a balance between the classic desktop app and OWA, but OWA is still the most similar to Gmail.
Microsoft 365 tenant-to-tenant migration
Microsoft 365 tenant-to-tenant migrations pose their own unique challenges; while the platform may be the same between source and target, this does not mean that migration will be seamless.
Different services in Microsoft 365 vary in migration support, with older services like Exchange having more robust migration hooks, while newer or specialized services may lack full migration support.
Many Microsoft 365 services aren’t fully supported for tenant-to-tenant migration, requiring extra planning or manual adjustments:
- Power Platform: Power Apps, Power Automate flows, and Power BI content may not transfer directly and may need recreating.
- Loop: As a newer service, Loop currently lacks migration options (and remember, Copilot Pages are Loop under the hood).
- Viva: Viva Engage (Yammer), Learning, and Connections don’t support migration.
- Purview: Sensitivity Labels, Retention Labels, and Retention Policies must be manually reconfigured in the new tenant.
While Microsoft Teams chat data can be migrated, the process is not straightforward. I wrote about what you need to know about Microsoft Teams chat migrations because I found that the migration process was often a surprise, even to people who are otherwise familiar with what migration entails.
Microsoft 365 Groups can also be misunderstood in migration planning. I worked on a migration project where we gave the customer a list of all their Microsoft 365 Groups and had them indicate which ones to migrate and which ones not to migrate. We did not remind them that Planner plans are associated with Microsoft 365 Groups. After migration, users complained that their Planner plans were missing, and we realized it was because those plans were associated with groups that we did not migrate.
Custom SharePoint apps and solutions aren’t packaged in a way that migration tools can capture and deploy across tenants, so manual redeployment is required.
One solution. Many workloads.
There are also objects and settings in Azure, in addition to users and groups, that may be part of migration efforts. Azure subscriptions and services tied to the tenant, including app registrations and managed identities, often require manual setup in the target environment to ensure smooth operation post-migration. Microsoft 365 applications linked to Azure AD or custom app registrations may need re-registration or permission adjustments to function correctly in the new tenant. If you’re using Azure DevOps, keep in mind that there is a more involved migration process there.
In addition to migration data and objects, consider migrating tenant level settings. Depending on the type of migration (acquisition, divestment, etc.) there may be different needs. Microsoft released an open-source Desired State Configuration (DSC) tool which helps with understanding the configuration of a source and/or target tenant.
Finally, make sure that licensing and storage limits are in alignment between the source and target tenant.
Conclusion
A successful migration to Microsoft 365 is built on strategic planning and careful attention to both technical and logistical details.By anticipating user needs, gathering detailed technical requirements, and reducing risks, you can streamline processes, minimize downtime, and create a smoother experience for everyone involved. Planning for these considerations will improve the outcome of your Microsoft 365 migration project.
