English | EN 
Following the (1) discovery and assessment outcomes, we shifted focus to designing a migration strategy grounded in real‑world constraints.
Design Phase: Architecting the Migration Strategy
Objective: Formulate the migration strategy and technical design based on discovery and assessment insights. This includes the overall approach (big bang vs waves, tooling setup, cutover method), target configuration requirements, and any detailed design for supporting components (identity, devices, etc.).
Approach: Given the findings, we designed a phased migration to align with the acquiring organization’s operational needs. One key design decision was to use a wave-based cutover approach instead of a single “big bang” migration. We split the users into a Pilot and multiple waves, primarily grouping users by business unit/program. This phased approach was chosen because the acquiring organization planned to issue new laptops to all migrated users as part of integration – a significant logistical dependency. By staging migrations in waves, we ensured each group had their GCC High-compliant devices delivered and set up in time for their cutover.
From a tooling perspective, we designed workflows to perform an initial sync of data (pre-staging most content) and later perform a delta sync and cutover on a scheduled weekend for each wave. This minimized downtime – users would stop using the old account at 6:00 PM Friday, and by Monday morning they would resume in the new tenant with their data updated. We documented these steps in a Migration Runbook (playbook) per workload.
Security and compliance considerations heavily influenced the design. For example, our design included controls such as limiting the migration account’s roles to only what the migration tool required.
Importantly, we also crafted the change management and communications plan as part of the design. This included planning user notifications, training, and support structure (more on that in the Planning phase). The design stipulated that each wave would have a User Acceptance Testing (UAT) period of about five days before cutover, where users could log into their new accounts (on their new laptops) and verify that email and files were appearing as expected. This influenced technical steps (like establishing mail forwarding between tenants during UAT).
Stakeholder Management: During design, achieving sign-off on approach and architecture was crucial. We held a Design Review session with IT architects. In that meeting, we presented the proposed migration plan (phases, timeline, tool use) and the target tenant readiness steps. Stakeholders appreciated that our design was structured and phased. We obtained agreement on key decisions such as wave composition and freeze periods. We also documented roles and responsibilities within the design (who does what during cutover, escalation paths, etc.).
Outcome: We produced a High-Level Design (HLD) and a detailed migration plan that served as the blueprint. Key elements of the design included:
- Phased approach, scheduled approximately three weeks apart.
- Tool Configuration: Tenants set up with minimal permission and tested; prepared to migrate Exchange, OneDrive, SharePoint sites, Teams (teams plus associated channels and chats).
- Cutover Method: Run initial sync for a wave 2 weeks before cutover; run delta sync. OneDrive and Teams access over a weekend; enforce a “freeze” on source usage during cutover window.
- Target Prep: Verified target tenant had all necessary licenses, increased OneDrive quotas to 5 TB max for users as needed, and ensured guest access was turned off per policy (with a plan to address external-sharing content separately).
- Risk Mitigation Plans: Documented how each identified risk would be handled (e.g., if a user didn’t complete Exit Certification, defer their migration.)
With design finalized, we moved into detailed planning and execution knowing what we were planned to do and how it would meet both technical and stakeholder requirements.
Lesson: Design for your constraints and stakeholders. In M&A scenarios, one size does not fit all – tailor the migration approach (waves vs big bang, tool config, support model) to the specific context. Get explicit buy-in on the design from all parties (acquirer, acquired), which builds confidence going into execution. Also, plan the user experience as part of the design – a technically sound migration can still fail if end-user impact isn’t carefully managed.
With the design locked, we were ready to move into detailed planning—turning architecture into an executable, day‑by‑day migration plan. Stay tuned!