Migrate to M365 with Confidence

As M365 migration specialists, my team and I have guided small and global organizations through the complexities of various M365 migration types, including on-prem to M365, transitioning from other productivity suites to M365, and tenant-to-tenant migrations. Regardless of the migration size and complexity, we always follow a defined approach to ensure a smooth and successful migration. This blog post condenses our experience into a clear roadmap, outlining the key phases involved in a successful migration project.

Phase 1: Discovery, Assessment, Planning

• Goal Setting & Stakeholder Alignment: Collaborate with key stakeholders to finalize project goals, drivers, scope, and prerequisites. Is the migration necessary as part of a M&A, to enhance operational efficiency and management, to consolidate tooling, to enable other capabilities (such as Copilot for M365), etc.? Having a good understanding of the project goal will help in making decisions about what is included in the scope and prioritizing decisions. Equally important, often, the data/content migration will not be the only workstream in the initiative. There may be user device migrations, complex and often slow-moving data governance projects (in the case of rolling out copilot for M365) associated with the M365 data migration. Conducting the M365 migration work within a well-defined program structure will ensure that all workstreams are aligned, dependencies are understood, and stakeholders and users have a clear and optimal migration experience.
• Inventory Review: Some initial content analysis should have already been conducted by using admin tools available in the current toolset when budgeting for the project. However, a thorough assessment of the source and target M365 tenant configurations is crucial during project execution. In addition to understanding the commonly known data sources including mailboxes, SharePoint sites, Home Drive, File Shares, reviewing and analyzing related and/or companion services like Stream, Planner, Whiteboard, Power Platform, SSRS reports, InfoPath forms, and other custom solutions/applications developed on top of or making use of M365 services is also essential. This is particularly important for companies making a large investment to enhance the on-premises SharePoint implementation. For understanding the on-prem SharePoint environment, a simple but effective tool to leverage includes SharePoint Migration Assessment Tool: Scan Reports: (https://learn.microsoft.com/en-us/sharepointmigration/sharepoint-migration-assessment-toolscan-reports-roadmap). For online, there are features on the M365 admin centers, or migration tools such as ShareGate, BitTitan, etc.
• Content Analysis and Rationalization: This is not a favorite project activity, but migration presents a great opportunity for data clean-up, and in the case of the Copilot for M365 roll-out, it is an opportunity to contribute to the success of the Copilot outputs. Always, the message needs to come from leadership for users to take the time to review content for freshness, relevancy, compliance/retention requirements. In some cases, there is a need to exclude specific file types. The migration tools and M365 capabilities offer the ability to filter out content during content migration or once it’s there in the target environment. However, having the migration team do this (rather than the users helping to analyze the content) may result in confusion or difficulty during UAT as source vs. target content will be different.
• Environment Configuration Gap Analysis: Evaluate both the source and target tenant configurations (settings for each service, compliance policies, allowed Teams apps…) and document any discrepancies for resolution before the migration. For highly customized SharePoint sites, the evaluation should include a comprehensive assessment of branding requirements, deployed templates, and any other custom solutions deployed on both source and target to understand and arrive at the final experience.
• Test Migrations: To establish migration metrics, identify and address potential issues, and validate the migration playbook steps, it is important to run test migrations. We are highly focused on optimizing the data migration/sync process, as this is often the reason for the prolonged duration of a project, leading to additional work. In a tenant-to-tenant migration, cutover activities typically do not occur until all data is synced. The extended duration often results in additional incremental sync jobs, source, and target data discrepancies, and ultimately a less optimal end user experience.
  
  Microsoft offers general performance insights and best practices guidance at https://learn.microsoft.com/en-us/exchange/mailbox-migration/office-365-migration-best-practices. However, running actual migrations is the best way to identify and address all bottlenecks, from network to migration machine issues and beyond. On the M365 side, throttling may occur if the migration exceeds a certain amount of data size per day. For large migrations, one may be able to request Microsoft’s help with a Throttling exception. SaaS-based third-party tools generally provide better migration throughput.
  
  Microsoft recently offers cross-tenant migration capabilities (https://learn.microsoft.com/en-us/microsoft-365/enterprise/cross-tenant-mailbox-migration?view=o365-worldwide), but as always, it is important to read the fine print for supportability (as of this writing, the feature is not supported for users in GCC). There is also a licensing cost to consider.
• User Readiness: While M365 is now a standard tool and end users often don’t need much guidance, it is still crucial to have a well-thought-out plan to support user adoption activities and reduce Helpdesk calls during and after migration cutover. Investing time in crafting a Communication Plan, content, and user guides with actual screenshots (from the Test or Pilot Migrations) offers familiarity and intuitiveness for users. We often set up a SharePoint migration site as a one-stop shop to provide transparency and all the details users would need, including migration timeline, inventory, user guides, etc. A FAQ list and Issues tracker can also be provisioned for users to leverage, especially during the UAT period.
• Migration Plan Finalization: Use the discovery and assessment findings to refine the migration plan. Analyze the data to identify any differences between initial assumptions and current realities. Perform the re-baselining exercise and refine the plan, which includes adjusting scheduling, cost estimates, or deliverables as required.

Phase 2: Pilot Migration

• Verification and Pre-provisioning: Validate prerequisites for the migration, such as the existence of necessary O365 groups in the target tenant. Pre-provision mailboxes, OneDrive site collections, SharePoint Online sites, and Teams workplaces in the target tenant. Some tools do require this pre-provisioning before the migration.
• Pilot Migration Execution, Feedback, and Refinement: The pilot migration serves as a crucial test run. During this phase, the migration team will configure and schedule migration jobs, support User Acceptance Testing (UAT) activities, and address any post-migration issues. For UAT, we recommend hosting a daily 30-minute to one-hour session for the first week to walk users through the migration flow, expectations, and provide pointers for a successful UAT. While the communication content sent to users up to this point should have addressed most of the information, it is still a good practice to cover those topics during UAT. Address any post-migration issues as needed. Gather feedback from the pilot and make necessary adjustments to the migration environments, plan, playbooks, communication templates, and other relevant documents to prepare for the full migration.
  
  It should be noted that in some cases, such as a tenant-to-tenant migration, a gradual cutover during the pilot phase is often impractical and creates a subpar experience. Users will have to log into two different tenants to access the various content (email, OneDrive, SharePoint, and Teams sites, in case not all their services are migrated). Shared resources in SharePoint and Teams further complicate a gradual cutover compared to a Big Bang approach.

Phase 3: Velocity Migration & Cutover

This phase focuses on executing the migration plan, whether a batched migration with cutover or continuous content migration followed by a final big bang cutover. A few key activities include:

• Pre-provisioning targets: Prepare target environments like SharePoint sites in the new tenant.
• Migration job execution: Configure, run, and monitor migration jobs.
• Inventory management: Continuously monitor and update the source inventory to account for newly added content or users.
• Target URL preservation: Maintain SharePoint URLs in the target tenant, if required.
• Documentation & update: Regularly update playbooks, communication templates, and documentation as the migration progresses.
• Migration machine maintenance: Monitor migration machines for necessary patches, updates, or adjustments to maintain optimal throughput.

During this phase, if Power Platform solutions exist, support solution owners in exporting/importing their solutions and testing them in the target environment Power Platform solutions are often tied to SharePoint assets (such as a SharePoint list). In this case, it would be important to migrate the site first. Redevelop any other assets (such as on-prem workflows to Power Automate flow or InfoPath forms into Power Apps).

Cutover Activities: The Big Bang cutover is a demanding process that requires the full commitment of all supporting teams, including the Helpdesk. Some clients may prefer the users to be supported by the migration team, while others may prefer their Helpdesk to be the first point of contact for users. In any case, some best practices for a smooth cutover include:

• Strategic Timing: Initiate the cutover on a Friday evening, after business hours, to minimize user disruption.
  • Incremental Sync Management:
    • Perform a final incremental sync before cutover, knowing that some content (particularly large OneDrive or SharePoint/Teams sites) may continue syncing into the following week(s).
    • Prioritize critical content for immediate sync.
  • Network Monitoring: Closely monitor network activity during cutover, especially if users are in the office syncing DOWN large amounts of data. This can help identify and address potential network bottlenecks.
  • Communication Channels:
    • Establish a dedicated communication bridge for all technical teams involved in the cutover activities.
    • Set up a separate bridge for end-user support over the next week, or 2 if needed. This may include breakout rooms for handling business-critical users or sites.

Phase 4: Post-Migration and Closeout

• Documentation Updates: Ensure all project documentation reflects the final migration state. This may include generating migration reports for stakeholders. Fortunately, most migration tools offer pre-built reports for this purpose.
• Knowledge Transfer Sessions: If you partnered with a vendor for the migration, actively participate in their knowledge transfer sessions. These sessions typically provide walkthroughs of the migration environments, job configurations, and any scripts used. As tenant migrations become increasingly common, in-house execution may be a future possibility for your organization.

Following this structured approach will increase your M365 tenant-to-tenant migration success rate and minimize disruption for your end users. Remember, this is a high-level overview, and the specific steps may vary depending on your unique project requirements.

Happy migrating!