Migration Wave
A batch of applications migrated together, sequenced so that dependencies move in a workable order and each wave delivers learning for the next.
Migrating a large estate application by application in arbitrary order fails on dependencies: an application moved to the cloud while its database and three integration partners remain on-premises now runs every interaction across a slow, expensive link.
Waves group applications so that tightly coupled sets move together, and order the groups so dependencies are satisfied. The usual sequencing principles:
Foundation first — the landing zone, connectivity, identity federation and logging must exist before anything meaningful moves.
Then a pilot wave of low-risk, low-dependency applications, chosen deliberately to prove the process rather than to deliver the most value. What it produces is a tested runbook, real timings and a list of surprises.
Then by dependency cluster, with the highest-value clusters early once the process is proven.
Retire and repurchase candidates first of all, because switching an application off is cheaper than migrating it and is consistently under-applied.
The recurring failure is treating waves as a purely technical grouping. A wave also needs the business availability to test and accept, so wave planning is as much a scheduling negotiation as a dependency analysis — and waves that ignore month-end, year-end or peak trading periods do not happen.