About this article: AI-assisted writing, reviewed against the cited sources. This is source research, not lab validation. Check the stated versions and your own requirements before making changes.
Wave one is not “whatever is easiest to copy”. It is the first tranche of applications whose move teaches the organisation how the programme works, proves the hosting model, and does not take down revenue if the lesson is expensive. After you have a dependency map, wave selection is a prioritisation decision: which workloads earn a place in the first cut because they are ready, bounded, and worth the attention.
Wave one should be small enough to support a rehearsed recovery plan and staffed follow-up. NIST SP 800-37 Rev. 2 provides general lifecycle risk-management principles. Applying those principles to migration waves is an editorial recommendation here, not a NIST wave-selection rule.
Why it matters
A dependency map establishes which components must work together. Wave selection then balances readiness, business value and risk. AWS recommends low-risk, low-complexity workloads, often non-production systems, for pilots and early waves. Choose a non-production candidate that exercises representative dependencies and has named testers; do not dismiss it simply because it has no live users.
Wave one sets the programme’s credibility. Sponsors, app owners and support staff watch whether dates mean something, whether exceptions are controlled, and whether the first production cutover is boring. A boring first wave is a feature.
How it works
Separate readiness from importance
Readiness is technical and organisational: documented owners, a test plan, known integrations, a rollback story, and a freeze window the business will honour. Importance is business value and risk if the app is wrong for a week. Wave one needs high readiness; importance can be moderate.
Put “crown jewel, messy dependencies” in wave two or three even when the sponsor wants it first. Put “ready, well-owned, bounded blast radius” in wave one even when it is not the company’s favourite system.
Use four filters (all must pass for wave one)
- Bounded dependencies. Upstream and downstream links are named and testable. Silent batch jobs and file drops are the usual wave-one killers; if they are still “probably nothing”, the app is not wave one (mapping dependencies is discovery; this article is the next decision).
- Reversible window. The business accepts a defined cutover window and a stated maximum data loss or rework if you roll back. If rollback is “we have not thought about it”, wave one is the wrong place to learn.
- Representative hosting pattern. The move exercises the pattern you will repeat: identity, networking, backup, monitoring and support handover. A one-off snowflake teaches little.
- Owner capacity. Named app owner and IT owner can attend tests, sign acceptance, and stay reachable for hypercare. A system without owners moves when paperwork says so, not when operations can support it.
Sequence within the programme, not within one weekend
Azure assessment supplies readiness and sizing inputs. AWS prioritisation and wave planning explain selection and dependency grouping. Applications with hard dependencies may need to move together. Use assessed requirements and tested connectivity to decide whether a group can be split.
A practical pattern:
| Candidate | Often wave one? | Why |
|---|---|---|
| Internal tool, tens of users, clear owner | Yes | Teaches support and monitoring with limited revenue risk |
| Read-only reporting on a copy of data | Sometimes | Good pattern test if data refresh is understood |
| Core ERP or practice system | Rarely | High value but rarely high readiness on first pass |
| Integration hub many apps use | Depends on the dependency group | Move with dependent applications when latency or coupling requires it; split only with a tested supported connection path |
What wave one explicitly excludes
Leave these for later waves unless every filter passes with written evidence:
- Applications still receiving major functional changes during migration.
- Systems whose licence or support terms forbid the target environment until renegotiated.
- Dual-write or parallel-run candidates unless you have budgeted consistency testing.
What to choose and why
Choose wave one to prove the operating model, not to minimise total VM count. One well-instrumented application with a signed acceptance criterion teaches more than five lift-and-shifts that nobody validated.
Choose at least one workload that uses the same identity, DNS and backup pattern as wave two. If wave one skips corporate identity entirely, wave two discovers Entra or AD issues under pressure.
Choose a sponsor-visible success metric before the wave is named: for example, “payroll submits from the new environment on the first business morning” or “remote staff reach the hosted app without a VPN change”. Vague “go live” language hides disagreement until cutover night.
Risks and limits
False readiness. Green ticks on a spreadsheet without a restore test or a pilot login from real user profiles are readiness theatre.
Wave one as dump ground. Parking every awkward system into wave one avoids hard conversations early and concentrates risk into the first cutover.
Vendor minimums and measured capacity. A vendor minimum can establish a functional or support prerequisite. It does not demonstrate that the VM can handle your concurrency, data volume or storage latency requirements.
Use the cutover runbook for technical consistency and recovery gates. Discuss the selected wave and responsibility boundaries with the migration provider; how migration is delivered gives service context.
Sources
Developed with AI assistance. Source research only; no migration, recovery or infrastructure procedure was executed or lab validated.
Source research accessed 14 November 2026. These documents support the stated principles and tool-specific conditions; the planning templates are editorial recommendations.
- NIST SP 800-37 Rev. 2, December 2018.
- Microsoft: Azure Migrate assessment overview.
- AWS: prioritisation and migration strategy.
- AWS: migration wave planning.
Related future topics
- Pilot design that predicts production risk.
- Parallel run versus big-bang cutover for line-of-business apps.
- Acceptance criteria before decommissioning the old system.
Learning notes
- A dependency map tells you what is connected; wave selection tells you what moves first and why.
- Wave one should be ready, bounded and representative; not merely easy or strategically loud.
- Rollback and owner availability are wave-one gates, not afterthoughts.
- Tools group machines; people assign business risk and sign the wave.
- Proving the hosting pattern early saves pain when important apps move later.
This article was originally published on .