Wave-Based Migration Planning: The Anatomy of a Successful M&A Cutover

A migration wave is a unit of work that can be executed, validated, and rolled back independently. That’s the definition. Everything else in wave-based migration planning is about making sure your waves actually meet that definition.

Most M&A migrations fail because they treat waves as organizational conveniences — buckets for grouping similar tasks — rather than as execution boundaries with defined success criteria, rollback procedures, and dependency constraints.

Here’s what a properly structured wave plan looks like, built from discovery data, and why the discovery phase is not optional before you start planning.

Why Most Wave Plans Fail

M&A migration plans fail in predictable patterns:

Wave starts before dependencies are mapped: A wave is supposed to be independent. But if you haven’t mapped application dependencies, your “independent” wave may have a hidden dependency on a legacy system you’re migrating in a later wave. The dependency surfaces during cutover, and the “independent” wave fails.

Go/No-Go gates have no criteria: Teams say “we’ll assess readiness before each wave.” But when the assessment is qualitative — “does it feel ready?” — gates don’t function. Go/No-Go decisions need quantified criteria: this percentage of accounts migrated, this validation test passed, this rollback procedure confirmed.

Wave boundaries don’t match business criticality: Grouping mailboxes by department makes organizational sense but ignores criticality. A wave that contains both executive mailboxes and general staff has asymmetric risk. The executive mailboxes need more validation, more rollback readiness, and earlier communication planning.

Resource scheduling is an afterthought: Migration waves require engineers, validation tools, and communication windows. When scheduling is done after wave definitions are set, you either delay waves or run them without proper support.

Rollback procedures are written for known problems, not discovered ones: If you haven’t discovered what could break, you can’t write procedures for it.

The Wave Definition Framework

Phase 1: Inventory Before Planning

Before waves can be defined, you need a complete inventory from discovery:

Identity inventory: All users, their roles, their access levels, their mailbox sizes, their Teams membership, their SharePoint site access. This determines what needs to move and in what sequence.

Application dependency map: Every application that users depend on, what it connects to, what data it stores, what would happen if it became unavailable. Critical dependencies must migrate before dependent systems.

Data classification: What data is regulated, where it lives, what compliance constraints apply. GDPR personal data in EU tenants may have migration sequence constraints that don’t apply to non-regulated data.

Application migration complexity: Some applications are simple — cut over the authentication and the data follows. Some are complex — dependent on on-premises infrastructure, legacy authentication protocols, or hardcoded IP addresses. Complexity drives wave sequencing.

Phase 2: Wave Structuring

Once you have inventory, group workloads into waves based on four criteria:

1. Dependency order: Application A must migrate before Application B. This is the primary sequencing constraint and it overrides everything else. If you don’t know the dependencies, you don’t know the order.

2. Criticality tier: Critical business applications — ERP, CRM, communication tools for customer-facing teams — go in early waves with the most validation and the most rollback readiness. Lower-criticality applications can absorb more migration risk.

3. Risk profile: Workloads with high data sensitivity, complex technical debt, or regulatory constraints go in waves with more pre-migration preparation and more conservative cutover criteria.

4. Resource availability: Wave execution requires engineers with specific skill sets. If your Active Directory specialist is available in weeks 5-8 but not weeks 1-4, AD migration waves go in weeks 5-8.

Phase 3: Gate Definition

Every wave needs quantified Go/No-Go criteria:

Pre-cutover gates:

• Discovery complete for all systems in wave scope
• Application dependency map confirmed — no undiscovered dependencies to later waves
• Rollback procedure documented and tested (or at minimum: rollback procedure documented with a tested rollback path for the critical path)
• Resource schedule confirmed — all required engineers confirmed available
• Communication plan confirmed — all affected users notified with migration timeline and contact points

Cutover gates:

• Pre-flight validation passed — accounts accessible, applications reachable, data integrity confirmed
• Parallel run window active — old and new systems running simultaneously
• Monitoring confirmed — dashboards live, alerting configured
• Cutover window open — business operations suspended for affected systems

Post-cutover gates:

• Validation complete — business operations confirmed in new environment
• Rollback window closed — old system retained but fenced off
• Sign-off received — from business owner and technical lead

The Wave Sequencing That Usually Works

Based on patterns across multiple integrations:

Wave 0 (Foundation): Network, DNS, VPN, and core identity infrastructure. This wave covers the plumbing. Everything else depends on it. If AD is being consolidated, this wave establishes the target forest structure.

Wave 1 (Critical Business): Executive accounts, finance systems, CRM. High-visibility, high-impact systems that need the most scrutiny. These waves go first because they need the most preparation and because problems with them are most visible.

Wave 2 (Productivity Core): Email migration (Exchange/Google), core SharePoint, primary Teams structures. High-volume, medium-complexity. Mailboxes are usually the largest workload by count.

Wave 3 (Operations): ERP integration points, operational applications, supply chain systems. These have dependency constraints that may require earlier waves to be complete first.

Wave 4-6 (Supporting Systems): Lower-criticality applications, departmental tools, legacy systems. These can absorb more migration risk and often have more flexibility in timing.

Wave N (Remediation): Security tooling, endpoint management, shadow IT formalization. Done after core systems are stable.

Common Wave Planning Mistakes

Adding too many workloads to a wave: If a wave fails, you want to be able to roll back a bounded set of work. If a wave contains 15,000 mailboxes, 200 SharePoint sites, and 8 custom applications, a failure in any one of them affects all of them. Keep waves granular enough to isolate failure.

Skipping the dependency map: Application dependencies are the most commonly missed planning step. A SharePoint site that looks independent may have a Power Automate flow that triggers when a finance app creates a new record. If you don’t find that dependency, it breaks post-migration.

Not modelling the rollback: For every wave, you need a credible rollback procedure. Not a theory — a documented, resourced, rehearsed procedure. If you can’t roll back cleanly, your Go criteria need to be more conservative.

Running parallel waves without enough engineering capacity: Two waves can run in parallel if you have the engineering resources to monitor both simultaneously, validate both simultaneously, and respond to incidents in both simultaneously. Don’t parallelize waves if your team can’t actually support parallel execution.

ACQI’s migration planner builds wave plans from discovery data automatically. Dependencies are mapped, criticality is assessed, and Go/No-Go gates are enforced. See it in action →