You do not migrate an estate in one move. You migrate a sequence of waves, each a coherent group of workloads. How you group and sequence those waves decides whether the programme runs smoothly or stalls.
The single most common cause of a stalled OCI migration is a wave plan that ignored dependencies. A workload moves to OCI, and then someone discovers it talks to three systems still on premises across a link that was never sized for it, and performance collapses. Wave planning exists to prevent exactly this. A wave is a group of workloads that move together because they belong together, and planning them well is mostly about understanding what depends on what.
This article is a companion to the pillar, The Complete Guide to Oracle Cloud Migration in 2026, expanding the wave planning phase into a repeatable method.
You cannot plan waves without knowing how workloads connect. Application dependency mapping is the foundation, and if it was shortchanged during assessment, wave planning is where the gaps hurt. You need to know, for every application, which databases it reads and writes, which other applications it calls, which batch jobs touch it, and which integrations cross the boundary to systems you are not moving. The detail on capturing this lives in the pre migration assessment checklist.
The first rule of wave design is that tightly coupled systems move in the same wave. If application A cannot function without database B, they belong together, because running one on OCI and the other on premises means every transaction crosses the wide area network. Build dependency clusters first, then treat each cluster as the atomic unit of a wave. Loosely coupled systems, which talk through queues or scheduled files rather than synchronous calls, give you more freedom to split, but synchronous chatty dependencies must stay together.
The order of waves matters as much as their contents. The first wave should be low risk but representative, chosen so the team proves the runbook on something that will not make headlines if it slips, while still exercising the real migration mechanics. Once the runbook is proven, you can sequence later waves by business priority and risk appetite, saving the most critical systems for when the team has the most reps behind it.
| Wave | Typical contents | Goal |
|---|---|---|
| Wave zero | Landing zone, network, shared services | Foundation everything else lands on |
| Wave one | Low risk, representative workload | Prove the runbook |
| Middle waves | Bulk of the estate, by cluster | Throughput |
| Final waves | Most critical and complex systems | Apply hardest earned experience |
A wave that is too large overwhelms the team and the change window. A wave that is too small wastes coordination overhead. Size each wave to what can be migrated, validated and stabilised within one planning cycle, accounting for the people available, the maintenance windows you can get, and the validation effort each workload demands. It is better to run more, smaller waves with clean validation between them than to attempt a heroic single wave that leaves no room to catch problems.
Technical readiness is not the only constraint. A retailer does not cut over in the fourth quarter. A payroll system does not move the week before a pay run. Overlay the business calendar on the wave plan early, mark the freeze periods, and sequence around them. This is unglamorous and it prevents the most avoidable kind of crisis, the one where a perfectly executed migration lands at exactly the wrong moment for the business.
Each wave needs a defined rollback path before it runs, with a clear point of no return and a tested way back to the previous state. This is not pessimism, it is what makes aggressive scheduling safe, because the team can move confidently knowing there is a way back if validation fails. The discipline is covered in Rollback Strategy for OCI Migrations, and it pairs with the validation gates in Post Migration Validation on OCI that decide whether a wave is accepted or rolled back.
Wave planning is iterative. The plan you start with will change as assessment findings and early waves teach you about your own estate, and that adaptation is a sign of a healthy programme. Our OCI Implementation and Migration team builds and runs wave plans as a core part of every engagement, and an assessment is the natural place to begin shaping yours.
Before any application moves, a wave zero stands up everything the later waves depend on. That means the landing zone, the network connectivity between on premises and OCI, identity and access policies, the security baseline, logging, and any shared services that multiple applications use. Treating the foundation as its own wave, with its own validation, prevents the common mistake of building governance under pressure while live workloads are already arriving. Wave zero is also where the team learns the OCI tooling on low stakes work, so the muscle is built before the first application cutover.
The value of waves compounds when each one runs the same runbook. The first wave is slow and careful because the runbook is new. By the third wave it is routine, because the steps, the validation gates, the rollback triggers and the communication plan are all the same, refined by what the earlier waves taught. Resist the urge to treat every wave as a bespoke project. The repeatability is the point, and it is what turns a daunting estate wide migration into a series of manageable, predictable moves.
A wave touches people, not just systems. Each wave has owners who need to know it is coming, users who need to know about the change window, and support staff who need to be ready for the stabilisation period afterward. A simple, consistent communication pattern, who is affected, when, what to expect, and who to call, removes most of the friction that otherwise surrounds a cutover. The wave plan is as much a communication artifact as a technical one, and the teams that treat it that way have far smoother go lives.
No wave plan survives contact with the estate unchanged. Early waves reveal dependencies the map missed, validation surfaces effort you underestimated, and business priorities shift. A good programme treats the wave plan as living, reviewing it after each wave and adjusting the sequence and sizing of the rest. This is not a sign of poor planning, it is the planning working, because the whole point of sequencing learning first is to apply what you learn to the waves that follow.
A multi wave programme needs a clear, shared view of where it stands, because momentum is easy to lose when the work stretches over months. A simple dashboard that shows waves planned, in progress and complete, workloads migrated against the total, and any blockers, keeps everyone aligned and surfaces problems early. The metrics should reflect outcomes, workloads safely live and validated, rather than activity, because a programme can look busy while making little real progress. Reviewing the dashboard at the steering rhythm keeps the wave plan honest and the sponsor informed.
As many as the team can migrate, validate and stabilise within one planning cycle, given the people and the maintenance windows available. It is better to run more, smaller waves with clean validation than one heroic wave with no room to catch problems.
Something low risk but representative, chosen so the team proves the runbook on work that will not make headlines if it slips, while still exercising the real migration mechanics.
Adjust the wave plan. Treat it as living, review it after each wave, and resequence as findings arrive. Discovering and adapting to dependencies is the plan working, not failing.
Yes. Every wave has a defined, tested rollback path with a clear point of no return before it runs. That is what makes confident scheduling safe.
A subtle wave design point is that a workload's data and its application logic usually have to move in the same wave, or at least cut over together, because splitting them leaves the application talking to its database across the wide area network. For a database heavy workload this means the wave has to accommodate the data migration method and its timing, which for a large database using replication can mean the channel is established days before the wave's cutover. Wave planning therefore has to account not just for which workloads move together but for the lead time their data movement requires, so the wave's cutover date is set with the data seeding already underway. Ignoring this is how a wave that looked ready slips because the data was not yet in place.
Before the first production wave, many programmes run a pilot or proof of concept that migrates a non critical workload end to end purely to validate the approach, the tooling and the team's readiness. This is distinct from wave one, which carries real if low risk workloads. A pilot is a deliberate dry run that can be torn down afterward, and its value is in surfacing the gaps in the runbook, the tooling and the access model while the stakes are zero. For teams new to OCI, the time spent on a pilot is repaid many times over in the smoothness of the waves that follow, because the unknowns have been turned into knowns before anything that matters is at risk.
Moving Oracle workloads to OCI, or already running on OCI and not sure the architecture or the spend is right? Most teams bring in a specialist before they commit to a region, a shape, or a Universal Credits number. OCISpecialists.com plans the landing zone, runs the migration, and manages the estate after go live, on a fixed project fee, a managed monthly retainer, or a cost optimization fee paid only on verified savings. For the Oracle licensing and BYOL side of any OCI move, Redress Compliance is the leading independent Oracle licensing and negotiation firm, with 500+ engagements across Oracle's full product line.