English | EN 
Overview
I recently led a Microsoft 365 (M365) tenant-to-tenant migration as part of a high-security Merger & Acquisition (M&A) initiative. This project challenged every stage of cloud transformation—Discovery, Assessment, Design, Planning, Execution, and Hypercare.
In this blog series, I’ll share how we approached each phase, the critical challenges we faced, and the best practices that proved essential—particularly around stakeholder alignment and tooling. These insights aim to reinforce strategies that drive success in enterprise-scale cloud integrations.
Let’s dive into how each phase unfolded, the obstacles we overcame, and the lessons learned along the way.
Discovery Phase: Laying the Groundwork
Objective: Understand the source and target environments and enumerate in-scope data and constraints. In an M&A context, this phase is critical to unearth unknowns in the acquired environment.
Approach: We kicked off with structured discovery workshops and data collection. The team gathered system inventories (users, mailboxes, sites, teams, etc.) provided by the acquired entity and supplemented that by interviewing them as well as the acquirer’s IT SMEs. Because our access to acquired entity’s tenant was extremely limited – we relied heavily on stakeholder collaboration to get information. This meant building trust and lines of communication with the acquired IT team from day one.
We also used tooling in a limited capacity during discovery. But given access constraints, stakeholder interviews and workshops were the primary “tool”. We established recurring discovery calls to review findings with both entities’ stakeholders, ensuring we interpreted the data correctly and didn’t any miss tribal knowledge (e.g. special sites, security constraints, ongoing decommissioning efforts).
Stakeholder Management: During discovery, transparency and patience were key. We had to ask the acquired entity’s admins for a lot of data dumps and clarifications. Maintaining a collaborative tone, we positioned ourselves as helpers: for instance, when anomalies appeared in the inventory, we flagged them to the acquired entity and jointly problem-solve which helped us build credibility. Regular touchpoints also helped the acquirer leadership stay confident that the acquired data was being accounted for.
Outcome: By end of discovery, we compiled a Discovery Report capturing the current-state inventory and key findings. We identified quirky details – e.g. some users had multiple email aliases, which would need mapping and Power Platform components that existed in the source. We began logging potential risks (like the discovery that external users were present in some SharePoint sites). These findings would directly inform us of our next phase.
Lesson: Engage the acquired organization’s experts early. In an M&A migration, your team often won’t have full visibility. Bridging that gap through stakeholder trust is invaluable. Also, centralize all discovered data – it becomes the single source of truth for planning.
Assessment Phase: Gauging Readiness and Risks
Objective: Analyze the discovered information to identify gaps, risks, and remediation needs before migration. Essentially, “what issues might prevent a smooth migration, and how do we address them?”
Approach: Our team conducted a thorough environment assessment focusing on both technical and process readiness. From the discovery data, we performed a gap analysis – comparing the source and target configurations and checking against Microsoft best practices for tenant migration. We asked questions like: Are there unsupported features or large items that need special handling? Are both tenants configured to allow migration throughput? What compliance steps are mandatory before moving data?
We documented dozens of findings and recommendations in an Assessment/ Remediation Report. For example, we noted that the acquired entity had an email retention policy (automatically deleting items after 60 days in some folders) while the acquirer tenant had none. This raised a data availability risk – emails that had been purged in the source would obviously not migrate. Our recommendation was primarily communicative: ensure users understood that “what isn’t in your mailbox at cutover can’t be migrated”. Another example: the acquired entity required users to complete an Exit Certification (reviewing and purging sensitive files) before their data could be migrated. We flagged this as a schedule risk – any delay in a user completing that would delay their migration – and we planned mitigation by closely tracking completions and having a contingency to move someone to a later wave if needed.
We conducted a thorough assessment of tooling constraints to understand its limitations within a GCC High environment and identify any potential security concerns. For issues raised, we collaborated with the software vendor to obtain detailed documentation on how they secure the account and communicated those controls to all security teams. Additionally, testing and a small pilot allowed us to validate the tool’s functionality.
Stakeholder Management: During assessment, managing stakeholder expectations was as important as the technical analysis. We held regular review meetings to go over the identified risks and our proposed remediations. This included business stakeholders because some gaps needed business decisions (for instance, whether to migrate certain legacy SharePoint content or leave it behind). We made sure to phrase findings in plain language and highlight the impact if unaddressed. This helped executive sponsors prioritize remediation efforts. By involving all parties’ information security and IT teams in these discussions, we got early buy-in for steps like granting the migration tool account the needed (minimal) privileges and scheduling user actions (like that Exit Certification) well ahead of cutover.
Outcome: The Assessment/Remediation Report gave us a clear checklist of pre-migration to-dos. Among these were: increase OneDrive storage quotas in target (to accommodate a few users exceeding 1TB), ensure target environment has enabled certain features (like allowing use of “classic” SharePoint mode temporarily, which the tool might need), and coordinate with the acquired entity on any content that needed to be restructured. We categorized issues by severity so we could tackle critical blockers first. Overall, this phase allowed us to de-risk the upcoming design and migration plan, and it gave stakeholders confidence that no “stone was left unturned” before we proceeded.
Lesson: Do the homework and be candid about risks. A rigorous assessment prevents nasty surprises later. Involve both IT and business stakeholders in reviewing risks – their early input can resolve ambiguities (e.g. confirming if certain data can be left or must be migrated) and garner support for necessary interventions (like policy changes or user prep tasks).
In the upcoming parts of this series, I’ll cover the Design Phase, where we architected the tenant‑to‑tenant migration strategy, the Planning Phase, focused on orchestrating schedules, dependencies, and communications, the Execution Phase, detailing how the migration played out in practice, and the Hypercare Phase, highlighting stabilization, support, and final lessons learned—concluding with key takeaways for driving successful M&A cloud integrations. Stay tuned!