Dual running is not a risk that might materialize. It is a certainty that starts the day the first OCI environment is provisioned and ends the day the last source system is switched off and its contract closed. Everything between those dates is overlap, and overlap is paid for twice: once to the old platform, whether that is a data center lease, a hosting contract, or another cloud, and once to OCI. The question is never whether dual running costs money. The question is how long the overlap lasts, what runs inside it, and who is watching the clock. This article puts numbers and structure on all three, as part of our wider series on what an OCI migration really costs.
What actually runs twice
Teams budget the obvious overlap, production compute in two places, and miss the rest of the iceberg. A complete dual running ledger has five layers. Infrastructure is the visible one: the OCI consumption for the target estate from provisioning day onward, alongside whatever the source platform costs per month. Nonproduction is the forgotten one: development, test, and staging environments typically get rebuilt in OCI early, because the migration itself needs somewhere to rehearse, which means nonproduction often runs dual for longer than production does.
The third layer is replication and migration machinery: GoldenGate consumption, ZDM hosts, bastions, and the network path between the estates, FastConnect or VPN, all of which exist only because the overlap exists. The fourth is licensing, and it is the layer with teeth. Oracle licenses moved under BYOL into OCI may still be needed on the source until it is switched off, and whether one entitlement can lawfully cover both sides during a migration window is a contract question, not a technical one, which is why we send it to an independent licensing specialist rather than guessing. The fifth layer is people: every week of overlap is a week of operating two estates, two monitoring stacks, two backup regimes, and two on call rotas. At 24/7/365 coverage expectations, the human cost of overlap is frequently larger than the infrastructure cost.
The four phases of overlap
Dual running is not one period with one burn rate. It is four phases with very different economics, and budgeting them separately is what turns a vague contingency into a defensible number.
| Phase | Typical duration | What runs twice | Main cost lever |
|---|---|---|---|
| Build and sync | 4 to 12 weeks per wave | Target infrastructure plus replication, source untouched | Right size the target down during sync, scale up at cutover |
| Rehearsal | 1 to 3 weeks per wave | Full target stack under test load plus full source | Compress rehearsals into tight calendar blocks, then idle the target |
| Cutover and fallback | 1 to 2 weeks per wave | Everything, plus reverse replication for rollback | Cap the fallback window in advance and hold to it |
| Decommission tail | 4 weeks to 12 months | Source estate, contracts, licenses, and residual data | Decommission discipline, the lever most often left unpulled |
The first three phases repeat per wave, which is why wave sequencing is as much a finance decision as a technical one: every wave you run in parallel widens the overlap, and every wave you stretch lengthens it. The fourth phase happens once, at the end, and it is the budget killer, because nothing about it is technically interesting and nobody owns it once the migration team has celebrated and disbanded.
Pricing the overlap honestly
The arithmetic is simple enough to do on one page. Take the monthly run cost of the source estate, the lease, the hosting fee, the power, the support contracts, the licenses that cannot yet be released. Take the projected monthly OCI consumption for the target, phase by phase, remembering that the target can and should run smaller during sync than it will at go live. Add the migration machinery and the people premium. Multiply by the months of each phase. The result is usually 15 to 30 percent of the total migration budget, which is exactly why quotes that omit it look attractively cheap and end expensively.
Two refinements make the number robust. First, price the fallback tail explicitly: if a tier one system keeps reverse replication for ten days after cutover, those ten days carry GoldenGate consumption, source infrastructure at full readiness, and an on call rota covering both directions. The outage arithmetic that justifies the spend is covered in pricing downtime, and the tooling consumption side in migration tooling costs. Second, separate committed from elastic spend. The source side is usually committed, contracts that bill whether used or not, while the OCI side is elastic, which means the optimization lever during overlap lives almost entirely on the OCI side: smaller shapes during sync, stopped compute between rehearsals, storage tiers matched to the phase.
Where dual running budgets blow up
Three failure patterns account for most of the overruns we see in assessments. The first is the decommission lag: the migration finishes, the source estate keeps billing, and six months later someone in finance asks why the data center invoice still arrives. Decommissioning is unglamorous work, asset disposal, data retention extracts, contract termination notices with 90 day clauses, and it needs an owner, a deadline, and a line in the business case. The wider exit economics are the subject of the data center exit business case.
The second is the contract cliff mismatch. Hosting and colocation agreements end on fixed dates; migrations slip. A program planned to finish one month before the lease expires has no buffer, and the renewal penalty for overshooting can exceed the entire optimization saving of the move. The fix is sequencing the waves against the contract calendar from day one, with the expensive contracts driving the order.
The third is rehearsal sprawl. Rehearsals are essential, but a target environment left running at full production scale between rehearsal windows burns consumption for nothing. The pattern that works: provision, rehearse intensively, capture results, scale down or stop, repeat. On OCI, where stopped compute on most shapes stops billing for OCPUs, the discipline translates directly into money.
A worked example: the shape of the money
Abstract percentages persuade nobody, so consider a composite drawn from real assessments. A mid sized estate runs a hosting contract at 120 units per month, where a unit is whatever currency slice makes the numbers comfortable, covering compute, storage, facilities, and support. The OCI target, properly sized, will run at 70 units per month at steady state, which is the headline saving that sold the migration. The program plans three waves over nine months.
During the build and sync phase of each wave, the OCI side runs at roughly 40 percent of its steady state cost for the workloads in flight, smaller shapes, no production traffic, replication ticking along. Rehearsals spike the target to full size for two weeks per wave. Cutover and fallback hold both sides at full readiness for ten days per tier one wave. And the decommission tail, in this composite, releases the source contract in two steps: half at month seven when the first data hall empties, half at month eleven, because the contract's termination clause needs 90 days of notice someone sent late. Sum it honestly and the overlap adds roughly 25 percent to the migration budget, with the late termination notice alone costing more than every rehearsal combined. That is the typical anatomy: the engineering phases behave, the administrative tail does not.
The same worked numbers expose the levers in order of force. Sending the termination notice on time is worth more than any technical optimization in the program. Scaling the target down during sync is the second lever. Compressing rehearsal calendars is third. Everything else is rounding. Teams that have priced their outage windows through the discipline in pricing downtime will recognize the pattern: the boring administrative numbers dominate the dramatic technical ones.
Nonproduction: the overlap nobody schedules
Production overlap gets planned because production gets attention. Nonproduction overlap just happens, and it usually runs longer. The development and test estate lands on OCI early, often months before the first production wave, because rehearsals need it there, and the source nonproduction estate rarely gets switched off until late, because somebody is always mid release on it. The result is the longest dual running window in the program attached to the least scrutinized environments.
Three controls keep it bounded. First, give nonproduction its own line in the overlap budget with its own dates; what is measured separately gets managed separately. Second, move teams, not copies: when a team's pipeline points at OCI, its source environments get a switch off date in the same change, not an indefinite stay of execution. Third, apply the elastic levers immediately on the OCI side, schedules that stop nonproduction outside working hours, smaller shapes by default, because nonproduction discipline costs nothing to impose during a migration and proves the operating habits the estate will need after it. An assessment that inventories environments honestly surfaces the real nonproduction count before it surprises the budget, and it is reliably higher than anyone's first guess.
A framework for capping the overlap
- Inventory both burn rates first. Source monthly cost, fully loaded with contracts and licenses, and projected OCI monthly cost per phase. No overlap budget is credible without both numbers.
- Budget the four phases separately, per wave. Build and sync, rehearsal, cutover and fallback, decommission tail. One blended number hides the tail, and the tail is where the money goes.
- Right size the target during sync. Run smaller shapes and lower service tiers while replication catches up, and scale to production size only for rehearsal and cutover.
- Cap the fallback window in writing. Agree before cutover how many days reverse replication and source readiness will be maintained, and price those days into the quote.
- Sequence waves against contract end dates. Let the most expensive committed contracts drive wave order, and keep at least one renewal buffer month between planned completion and any cliff.
- Name a decommission owner with a deadline. Source switch off, data retention extracts, license release, and contract termination are project tasks with dates, not aftermath.
- Review the overlap burn monthly. One page, both estates, trending toward zero on the source side. The day that line stops falling is the day the program needs attention.
How the engagement model changes the math
Who carries the overlap risk depends on how the migration is bought. On a fixed project fee, the delivery partner has every incentive to compress the overlap, because their margin erodes as the program stretches; make sure the fee includes the decommission tail, or the incentive stops exactly where the money keeps flowing. On a managed monthly retainer, the operating burden of running two estates lands on the provider, which is the shape that suits estates with long, multi wave programs and a 24/7/365 coverage requirement they cannot staff twice. And where the migration is already done but the overlap never quite ended, source systems still humming, licenses still allocated, oversized shapes still running from cutover day, an optimization engagement paid as a percentage of verified savings turns the cleanup into a no savings, no fee exercise. Across 500+ OCI engagements, the post migration pass finds an average of 40 percent spend reduction, and lingering dual running is reliably one of its top three findings. Our OCI implementation practice builds the overlap budget into the migration plan from the first assessment, which is cheaper than discovering it month by month.
Dual running is the price of a safe migration, and it is worth paying, briefly. Budget it in phases, cap the fallback, sequence against the contracts, and put a name and a date on the switch off. The estates that do this treat overlap as a countdown. The estates that do not treat it as a surprise, and the surprise always arrives on an invoice.
Part of a series
This guide is part of OCI Migration — our complete pillar guide on the topic.
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.