Wave Planning Economics: Sequencing Workloads to OCI

When a migration business case goes wrong, the autopsy usually finds the damage in the middle of the plan, not at the edges. The assessment was sound, the target architecture was sensible, the team was capable, and yet the program ran six months long and twenty percent over. The culprit, more often than any technical failure, is the wave plan: workloads grouped by convenience instead of economics, integrated systems split across waves that then needed temporary interfaces to talk to each other, and the hardest cutovers scheduled first while the team was still finding its feet. Sequencing is where migration budgets are quietly won or lost.

This article is part of our series on what an OCI migration really costs, and it covers the cost behavior of the plan itself: how the order in which workloads move changes the total bill, and how to build a sequence that pays for the later waves with the savings from the earlier ones. The patterns here come from 500+ engagements across estates of every size, and they repeat with remarkable consistency.

Sequencing is an economic decision wearing a scheduling costume

A wave plan determines four numbers that never appear on it. First, the date savings start: every month a workload waits in the queue is a month it keeps paying data center or legacy hosting costs, so the order of the queue is literally the shape of the savings curve. Second, the length of dual running: from the day the first workload lands on OCI to the day the last one leaves the source environment, the organization pays for two estates at once, and the wave plan sets the length of that overlap almost by itself. Third, the cost of interim plumbing: every integrated pair of systems that ends up in different waves needs a temporary cross environment connection, and those connections cost real engineering and real network spend. Fourth, the team's position on the learning curve at each cutover: work done in wave one costs more per workload than the same work done in wave four, because wave one is where the runbooks, pipelines, and habits get built.

Treat the wave plan as a financial model with dates on it, and these four numbers become design inputs. Treat it as a calendar, and they become surprises.

What a wave actually is

A wave is a bounded group of workloads that moves together: assessed together, built for together, rehearsed together, and cut over inside the same window or a tight cluster of windows. A usable wave plan states, for each wave, the workloads in scope, the migration method per workload, the entry criteria that must be true before the wave starts, the exit criteria that define done, and the calendar slot it occupies. Waves of six to twelve workloads tend to work well for mixed estates; bigger waves concentrate too much risk into one window, and single workload waves stretch the program and the dual running bill with it. The inventory that feeds this grouping should already exist if the assessment was done properly, which is exactly what our 40 point migration assessment checklist is designed to produce.

Four ways to sequence an estate

Most wave plans follow one of four strategies, usually without anyone naming the choice. Each has a legitimate use and a characteristic failure mode, and the right answer for a real estate is almost always a blend.

The blend that works in practice: start with one genuinely forgiving wave to shake out the landing zone and the pipelines, then sequence the remaining waves by value, adjusted so that tight integration clusters stay together and any hard exit dates are honored. The blend is boring, and boring is what a migration calendar should be. For estates whose business case rests on closing a facility, the exit date logic dominates and the rest of the plan bends around it, a dynamic we cover in detail in the data center exit business case.

Why wave one costs the most

The first wave carries costs that no later wave pays. The landing zone takes its first production traffic and reveals what the design reviews missed. The migration pipelines, the imaging process, the database transfer method, the validation scripts, all get built and debugged on wave one's clock. The runbooks are written for the first time, the rollback gates are tested for the first time, and the team makes its first time mistakes. In our engagements, the cost per workload in wave one commonly runs two to three times the steady state cost achieved by wave three or four, and that ratio is healthy: it means the learning was front loaded where it belongs.

The planning consequence is simple and frequently ignored. Wave one should contain workloads that can absorb mistakes: development and test systems, internal tools, a modest standalone application with patient users. It should not contain the flagship ERP, the customer facing platform, or anything with a six figure downtime price. Equally, wave one should be representative: it needs at least one real database move, one real application cutover, and one real integration repoint, or it teaches nothing the later waves can use. A wave one of nothing but file servers proves only that file servers move.

The cost of splitting integrated systems

Affinity is the grouping rule with the most direct cash consequence. When two systems that talk constantly end up in different waves, the period between their moves is a period of cross environment traffic: application calls leaving OCI, crossing the interconnect or VPN, hitting the source data center, and coming back. That traffic pays three times. It pays in latency, which users feel and sometimes reject loudly enough to force schedule changes. It pays in engineering, because interim interfaces, DNS cutover staging, and firewall rules between environments are real work that exists only because of the split. And it pays in risk, because every temporary bridge is a thing that can fail during the months it was never designed to last.

The discipline is to map integration affinity during assessment, cluster systems that exchange high volumes or chatty synchronous calls, and either move clusters whole or consciously price the bridge. Sometimes the bridge is worth it: a cluster too large for one window must be split somewhere, and the cheapest seam is between systems that exchange nightly batches rather than constant calls. The mistake is not splitting, it is splitting blind.

Downtime price as a grouping rule

The second strong grouping signal is the cost of the outage window. Systems with similar downtime prices justify the same migration method and the same depth of rehearsal, which means they share pipeline work, rehearsal environments, and cutover staffing efficiently when they travel in the same wave. A wave that mixes a near zero downtime GoldenGate cutover with a casual weekend Data Pump move gets the worst of both: the expensive tooling and rehearsal cadence of the first, applied wastefully across the planning of the second. We cover how to put a defensible number on the outage hour in pricing downtime, and that number belongs on the wave plan next to every workload name.

Dual running is the meter the wave plan sets

From first landing to final exit, the organization runs two environments. OCI capacity spins up wave by wave while the source estate shrinks more slowly than anyone forecasts, because source environments rarely get decommissioned the week after cutover. The wave plan sets the length of this overlap, and the overlap is usually the largest single number the business case never itemized. A twelve month program with aggressive decommissioning discipline can keep the overlap tolerable; an eighteen month program that drifts to twenty four, with source servers lingering for just in case, can quietly consume the entire first year of projected savings. The mechanics of budgeting this line, including the decommissioning discipline that controls it, get their own treatment in budgeting dual running. For wave planning purposes the rule is: every month added to the plan adds a month of double estate, so schedule compression you can achieve safely is worth real money, and schedule slack you add for comfort has a price tag.

A framework for building the wave plan

The following sequence turns an assessed inventory into a costed wave plan. It assumes the assessment produced a workload inventory with sizing, dependencies, and business criticality; if it did not, fix that first.

What this means for budget and team

A wave plan built this way changes the commercial conversation. Instead of one large number and a distant finish line, the program becomes a series of funded stages, each with its own savings release, and the later waves are partly paid for by the run cost the earlier waves stopped burning. It also changes how you buy help. The expensive skills, landing zone design, pipeline construction, cutover leadership, concentrate in the early waves; the later waves need throughput more than invention. A fixed project fee covering the program makes overruns the provider's problem rather than a change request, which is how we price OCI implementation engagements, with 20+ years of combined Oracle estate experience applied where the learning curve is steepest and 24/7/365 coverage through every cutover window. Estates that stay with us after the final wave move onto a managed monthly retainer, and where the goal is recovering spend on an estate already in OCI, an optimization fee paid only on verified savings.

Sequencing will never appear as a line on a quote, which is exactly why it deserves a chapter in the business case. Group by affinity, schedule by value, protect wave one for learning, put a decommission date on every exit criterion, and read the whole plan as a cash flow before you commit to it. The estates that do this finish faster, spend less, and never have to explain to a steering committee why two data centers are still running eighteen months after the program started.