When OCI Migration ROI Turns Positive: Realistic Timelines

Migration ROI models fail in a consistent direction. The costs are underestimated because dual running and decommissioning lag get thin treatment, and the savings are overestimated because they are dated from go live rather than from when they actually start flowing. The result is a promised breakeven at month fourteen that arrives at month twenty two, a steering committee that remembers the promise, and a platform that gets blamed for an arithmetic error. None of this is necessary. Across 500+ engagements the spend curve of an OCI migration follows a shape regular enough to model honestly, and an honest model is the cheapest credibility a program can buy.

This article is part of our series on what an OCI migration really costs, and it covers the question every CFO asks last and should ask first: when does this pay back?

The shape of the curve

Cumulative cash flow on a migration follows a J curve. It dips first: assessment, landing zone, migration services, tooling, and the early months of OCI consumption all land before a single source server is switched off, and through the migration window the organization pays for two estates at once. The dip bottoms out around the final cutover wave, when dual running peaks. Then the climb begins: source infrastructure leaves the books, the OCI run rate settles, and the monthly savings gap starts repaying the investment. Breakeven is the month the cumulative line recrosses zero, and the two numbers that set it are the depth of the dip and the steepness of the climb.

The depth of the dip is mostly a discipline question. Migration services are a known quantity if scoped honestly, but the dual running tail is governed by how fast source environments actually get decommissioned, and decommissioning lag is the single most common reason real breakeven arrives later than modeled, a dynamic covered in detail in budgeting dual running. The steepness of the climb is mostly an architecture question: how much cheaper the OCI estate runs than what it replaced, which is decided by right sizing, BYOL, and environment scheduling choices made during the migration itself.

Typical breakeven ranges by scenario

The table below reflects the patterns we see across engagements. Ranges assume competent execution, BYOL where licenses exist, and savings measured against the genuine prior run rate including the refresh costs the old platform was about to incur.

Read the ranges as planning bands, not promises. An estate can beat the bottom of its band when a hard cost like a lease or a refresh disappears on schedule, and it can blow through the top when dual running drifts or when scope creeps mid program. The point of the table is calibration: a model promising breakeven at month eight on a single application move is not optimistic, it is wrong, and finance should be told which.

What accelerates the crossover

Avoided spend with a date on it. The strongest accelerants are costs that were coming anyway: a hardware refresh quote, a lease renewal, an extended support bill. These count as savings from the moment they are dodged, which is why refresh triggered migrations pay back fastest and why the business case should hunt for every dated avoidance in the estate, the same logic that anchors the data center exit business case.

BYOL. Carrying existing Oracle licenses to OCI rather than paying license included rates moves the monthly run rate materially for database heavy estates, and it costs nothing but contract literacy to claim.

The post migration optimization pass. Estates that land on OCI sized as they were on premises leave the climb flat for no reason. A deliberate optimization pass in the first two quarters, right sizing, storage tiering, scheduling non production, routinely finds the kind of reductions behind our 40% average figure, and the mechanics are covered in the post migration optimization pass. Modeled honestly, this pass is what turns a barely positive case into a comfortable one.

Decommissioning discipline. Every source server with a decommission date and an owner shortens the dual running tail. This is project governance converting directly into months of breakeven.

What delays it

The delays are mirror images. Dual running that drifts because nobody owns switch offs. Savings dated from go live in the model but starting at decommission in reality. Scope creep that folds upgrades and transformations into the migration budget while their benefits land in someone else's business case. Sizing carried over one to one from on premises, which defers the climb until someone runs the optimization pass that should have been in the plan. And the quiet one: contingency spent early on self inflicted discovery, because the assessment was thin, which is a failure the assessment checklist exists to prevent.

Building a model finance will sign

An illustrative crossover, with numbers

Abstract curves persuade nobody, so here is the shape with figures attached. Take a mid sized estate paying 95,000 per month on premises across infrastructure, facilities share, support contracts, and the amortized refresh that was due next year. The migration program costs 600,000 in services and tooling across eight months, and OCI consumption ramps to a steady 55,000 per month as waves land. During the eight month program, dual running means the organization pays a blended 120,000 to 140,000 per month at peak, source estate still largely alive, OCI growing underneath it.

By program end, cumulative net investment sits around 900,000: the services bill plus the dual running premium over the old baseline. From month nine, the monthly position flips to roughly 40,000 in favor, the 95,000 that stopped against the 55,000 that started. At that pace the 900,000 hole fills in about 22 months from program start, call it month 22 to 24 once decommissioning friction is priced honestly. Now apply the two big levers. If a 350,000 hardware refresh was genuinely avoided, the hole starts 350,000 shallower and breakeven pulls forward to around month 16. If a post migration optimization pass lands in the second quarter after go live and takes consumption from 55,000 to 42,000, the monthly gap widens by a third and the date moves again. Stack both and the crossover lands inside the first year, which is exactly the pattern behind the fastest cases in the table above.

The exercise is worth doing with your own numbers precisely because every estate weights differently. What it demonstrates either way is where sensitivity lives: the model barely notices a ten percent error in services cost, but it moves by quarters when decommission dates slip or when the optimization pass exists or does not. Spend review effort accordingly.

One more input deserves a line in the model: the Universal Credits commitment itself. Annual commit levels and their discounts set the unit prices the whole climb is computed from, and a commit sized to the post optimization estate beats one sized to the lift and shift footprint that lands on day one. Committing early to the bigger number locks in a flatter climb; the disciplined sequence is to commit conservatively, optimize, then resize the commit to the estate that actually exists.

The model also needs a verification habit, because claimed savings and verified savings drift apart the moment nobody is measuring. The discipline that works is unglamorous: a monthly savings ledger, owned by one named person, that reconciles the model's predicted position against the actual OCI invoice and the actual decommissioned spend, line by line. Savings count only when the old cost has demonstrably left the books and the new cost is on an invoice, not when a project plan says they should have. This is the same standard we apply when our own optimization fee depends on it, and it changes behavior on both sides: engineering teams stop claiming savings for changes that have not shipped, and finance stops discounting numbers it can audit. A breakeven date computed from a verified ledger is also the only one worth presenting twice, because it survives the second meeting.

The commercial lever most models ignore

How the migration is bought changes the risk shape of the entire curve. Time and materials pricing puts schedule risk on the buyer, which means the dip deepens whenever the project does. A fixed project fee caps the dip at a signed number and moves overrun risk to the provider, which is how we price migration work. On the climb side, an optimization engagement paid as a percentage of verified savings means the steepening of the curve costs nothing unless it actually steepens, no savings, no fee, which is as close as infrastructure economics gets to a free option. And the run rate that sustains the climb is protected by the operating discipline of a managed monthly retainer with 24/7/365 coverage, through our OCI optimization and managed services practices, backed by 20+ years of combined Oracle estate experience.

Breakeven on an OCI migration is not a mystery; it is the sum of dated decisions. Baseline honestly, date the savings from decommission, model dual running where everyone can see it, buy the work in structures that cap the dip and incentivize the climb, and reforecast quarterly. Do that, and the chart in the business case stops being a sales document and becomes the most useful page in the program.