Assess, Discover, and Plan Migration Waves

Goal

The previous section established that migration is a sequence of decisions, not a mass copy exercise. This section shows how discovery, dependency mapping, and wave planning turn that idea into an executable program.

The Short Version

You do not migrate applications one by one in isolation. You migrate dependency groups in waves that match business risk and operational readiness.

Wave 0: Landing zone, identity, connectivity, logging
Wave 1: Low-risk internal apps
Wave 2: Shared services and dependent apps
Wave 3: Customer-facing critical systems
Wave 4: Hard-to-retire legacy or specialized systems

Migration waves are risk-management units. If the grouping is wrong, the schedule becomes fiction.

Why Discovery Still Matters

Many organizations say they already know their estate. Usually they know parts of it.

They may know:

Server names.
Environment labels.
Application owner guesses.
High-level business importance.

They often do not know, with enough confidence:

Which systems still exchange files or database calls.
Which jobs only run monthly and therefore escape casual observation.
Which applications depend on shared authentication, DNS, certificates, schedulers, or reporting stacks.
Which databases feed multiple downstream tools.
Which "retired soon" systems are still on a critical path.

Discovery is not an insult to the team's memory. It is how the migration program replaces assumptions with inventory, dependency evidence, and rollback reality.

What A Good Migration Wave Looks Like

A good wave is not just a batch of applications that fit on a spreadsheet tab. It is a group the organization can:

Prepare together.
Validate together.
Support together.
Roll back together if necessary.

Useful wave design usually weighs five factors:

Factor	Why It Matters
Business criticality	High-value workloads may need stronger rehearsal, controls, and executive visibility.
Dependency coupling	Tightly linked systems often need coordinated movement or temporary coexistence design.
Operational readiness	Monitoring, backup, access, and support ownership must exist before cutover.
Data and rollback complexity	Stateful systems and shared databases are harder to validate and reverse.
Team capacity	Waves fail when the organization cannot absorb testing, cutover, and stabilization work.

Wave planning is therefore part architecture and part delivery discipline.

Shared Dependencies Usually Move Earlier Than Expected

Application teams often want to sequence migrations around their own roadmaps. That is understandable, but shared dependencies often control the real order.

Examples include:

Identity and federation services.
Core DNS and certificate workflows.
Network connectivity and routing patterns.
Shared file transfer platforms.
Batch schedulers.
Central reporting and integration hubs.
Databases or message brokers used by many applications.

These dependencies do not always move first as production workloads, but they must be understood early because they shape coexistence, cutover sequencing, and validation criteria for later waves.

Example: 200 Applications That Were Not Independent

An enterprise begins with a list of 200 applications. On paper, several internal systems look independent and low-risk, so business leaders want them in the first wave.

Discovery shows a different picture.

Those "independent" systems all rely on:

A shared Active Directory and authentication path.
A central batch scheduler.
A common reporting database.
A file transfer platform that feeds both finance and customer operations.

Now the migration team has a more honest picture.

The first wave is no longer "random easy apps." It becomes:

Prepare identity, connectivity, logging, and access controls.
Move low-risk workloads that have clean boundaries.
Address shared services and the applications tightly bound to them.
Leave the most sensitive customer-facing systems until the operating model has already been proven.

That sequencing reduces surprise because the organization learns on lower-risk moves before it spends its credibility on critical systems.

A Practical Wave Model

Most large programs need an explicit Wave 0.

Wave 0 is where the organization prepares the migration platform:

Landing zone and account patterns.
Connectivity from existing environments.
Central audit and logging.
Identity and role patterns.
Backup and restore expectations.
Deployment and rollback standards.
Tagging and cost visibility.

Only after that foundation exists should the program move into workload waves.

Early workload waves usually favor systems that are:

Low criticality.
Well understood.
Lightly coupled.
Easy to validate.
Easy to roll back.

Later waves take on the applications with harder data, broader dependencies, stricter downtime limits, and more complicated business validation.

Common Mistakes

Letting application owners self-sequence migrations without shared dependency visibility.
Grouping waves by politics or org chart instead of coupling and risk.
Moving shared dependencies late because they are awkward to govern.
Ignoring the stabilization time needed after each wave.
Calling a wave complete when replication finishes instead of when validation and support ownership are stable.

If Someone Asks You

What makes a migration wave credible instead of arbitrary?

A good answer is:

A credible wave reflects dependency reality, business risk, operational readiness, and rollback complexity. It groups systems the organization can actually prepare, validate, and support together. If the grouping ignores shared services or assumes applications are independent when they are not, the wave is arbitrary.

What You Should Remember

Migration waves are risk-management units. They should reflect dependencies, readiness, and rollback reality.

Questions to Check Your Understanding

Why are discovery and dependency mapping still needed in familiar environments?
What characteristics make an application a poor candidate for an early wave?
Why do shared services often affect migration order more than application importance alone?

Further Study

AWS Cloud Adoption Framework: Introduction - Use this for program-level migration capability planning rather than tool-first thinking.