The Data Center Exit Business Case: OCI Edition

Most data center exit business cases fail in the same place, and it is not where people expect. They do not fail because the OCI numbers are wrong. They fail because the current state numbers are wrong, almost always in the same direction: too low. The data center has been there for years, its costs are spread across a dozen budget lines owned by different departments, and nobody has ever added them all up. So when the cloud estimate arrives as one clean monthly figure, it gets compared against a baseline that quietly omits a third of what the facility really costs, and the case looks weaker than it is. The honest version of the exercise usually points the other way: across our 500+ engagements, teams that build a complete baseline and a realistic OCI target typically find an average spend reduction of around 40%, before counting any of the softer benefits.

This article is part of our series on what an OCI migration really costs, and it focuses on the finance side of the decision: assembling a business case that survives scrutiny from a CFO, a procurement team, and an auditor, because a case that only convinces the people who already wanted to move is not a case at all.

The current state baseline: what the data center really costs

The baseline is the foundation of everything that follows, so it deserves the most effort. The goal is a complete annual cost of running the estate where it is today, projected over the same horizon you will use for the OCI numbers, usually three to five years. That projection matters: a data center is not a flat cost, it is a series of cliffs.

Hardware refresh cycles

Servers, storage arrays, and network gear age out on predictable cycles, typically four to six years for compute and five to seven for storage. If a refresh falls inside your planning horizon, its full capital cost belongs in the baseline, because staying put means paying it. This is the single largest line that incomplete business cases omit. A facility that looks cheap in year one often has a multimillion refresh sitting in year two, and the business case comparison changes completely once it is included. List every asset, its purchase date, its expected end of life, and the realistic replacement cost, then place those amounts in the years they will land.

Facility, power, and cooling

If you are in a colocation facility, the contract gives you the rack, space, and power numbers directly, though watch for escalation clauses and overage charges that inflate the steady state figure. If you own the facility, the work is harder: power draw, cooling, UPS maintenance, generator testing, physical security, insurance, and a share of the building cost all belong in the baseline. Power and cooling alone commonly run at a similar order of magnitude to the IT load itself once efficiency losses are counted, and they are almost never charged back to IT in a way that makes them visible.

Support contracts and software tied to the floor

Hardware maintenance contracts, operating system support, virtualization licensing, backup software licensed per terabyte or per socket, and monitoring tools licensed per node all scale with the physical estate and all go away, shrink, or transform when the estate does. Pull the actual renewal invoices rather than estimates, because support on aging hardware rises sharply after the standard support window ends, and that rise belongs in the out years of the baseline.

People time and the lines finance forgets

Someone racks the servers, swaps the failed disks, walks the floor, manages the colo vendor, plans the capacity, and drives to the facility at 2 a.m. when something fails. That time is real cost even when no role is dedicated to it, and the honest method is to estimate the fraction of each team member's time spent on activities that exist only because the physical estate exists. Then add the lines finance reliably forgets: network circuits into the facility, cross connects, hardware spares inventory, disposal and data destruction costs, travel to remote sites, the audit and compliance effort of certifying a physical facility, and the capacity buffer, all the hardware bought and powered for peaks that arrive twice a year.

The target OCI run cost

With the baseline built, model what the same workloads cost to run on OCI. The key discipline is to size the target on measured utilization, not on the inventory. A typical estate runs at 20 to 40% average utilization because hardware was bought for peaks and for growth that may or may not have arrived. Migrating the inventory one for one reproduces that waste at cloud prices; migrating the measured workload captures the saving. The target model should cover compute shapes matched to observed CPU and memory use, storage tiered by access pattern, network egress based on real traffic flows, and the platform foundation itself. That foundation is not free and should not be hidden: budget the landing zone explicitly, using the guidance in our article on what an OCI landing zone costs, and apply realistic Universal Credits discounting based on the committed volume rather than list prices.

The one time migration cost

Between today and the steady state sits the migration itself, and the business case must carry it honestly. The components are assessment and discovery, landing zone build, migration execution per wave, testing and cutover effort, data transfer, application remediation for anything that cannot move as it is, and project management across the whole program. The shape of the waves drives much of this cost, which is why wave planning deserves its own line of analysis: tightly grouped waves reduce the duration of double running, while poorly sequenced waves stretch it. Pricing models matter here too. A fixed project fee for the migration converts the largest unknown in the business case into a known number, which is exactly what a CFO wants to see, and it transfers delivery risk to the partner rather than leaving it on your budget.

The bridge period: paying for both

Every exit has a stretch where you pay for the data center and for OCI at the same time. The landing zone goes live before the first workload moves, and the last rack keeps drawing power until the final wave completes. Business cases that ignore the bridge get ambushed by it: a twelve month migration means up to twelve months of OCI spend ramping up while data center spend barely ramps down, because most facility costs are fixed until you actually leave. Model the bridge month by month, with OCI cost rising as waves land and the data center cost falling in steps as halls empty and contracts terminate. The bridge is also the strongest argument for migration speed. Compressing the program from eighteen months to ten does not just deliver benefits sooner, it removes eight months of double payment, which on a sizable estate can fund the entire migration project.

Lease and contract end dates as forcing functions

The calendar is the most underused asset in a data center exit. Colo contracts, facility leases, hardware support renewals, and software agreements all have end dates, and each one is a moment when staying put gets more expensive or requires a fresh commitment. Map every end date on a single timeline. A colo contract expiring in fourteen months is a deadline: complete the exit before it and you avoid a renewal entirely; miss it by a month and you may be forced into a year of extension. A looming hardware refresh works the same way, since every server you do not replace is capital avoided. The strongest business cases are built backwards from these dates, with the wave plan sequenced so workloads leave a hall before its costs renew. This is also where timing discipline connects to the broader question of when an OCI migration actually pays back, because the forcing functions determine which year the savings start landing in.

Soft benefits, treated honestly

Agility, DR posture, and patching currency are real benefits, and they are also where business cases lose credibility, because they are routinely inflated into vague millions. The honest treatment is to quantify what can be quantified and clearly label what cannot. Provisioning that drops from six weeks of procurement to thirty minutes of automation has a measurable value if your teams actually wait on infrastructure today; count the waiting, not a generic productivity claim. A DR posture that moves from an untested runbook to a second OCI region with regularly exercised failover is partly quantifiable, through the standby infrastructure you no longer own, and partly a risk reduction you should describe rather than price. Patching currency, running supported versions instead of nursing end of life platforms, shows up as reduced extended support fees and reduced audit exposure. Present these in a separate section of the case, never blended into the hard numbers, so the financial core stands on its own even if a skeptical reviewer strikes every soft line.

Risk adjustments and presenting payback

Before the case goes to the board, stress it. Add a contingency of 15 to 20% on the one time migration cost, extend the bridge period by a quarter in a downside scenario, and assume one wave needs rework. If the case still pays back under those assumptions, it is robust; if it only works in the best case, it is not ready. Then present payback simply: cumulative cost of staying versus cumulative cost of moving, plotted over five years, with the crossover point marked. Most well built exits cross over between months 18 and 30, driven by the avoided refresh, the eliminated facility cost, and the roughly 40% run rate reduction a properly sized OCI estate typically delivers. Be explicit about the commercial structure as well: a fixed project fee for the migration, a managed monthly retainer for operations after cutover with 24/7/365 coverage, and where the goal is squeezing an existing estate, an optimization fee paid only on verified savings, so the cost of finding the savings is funded by the savings themselves.

A framework for assembling the case

Getting the case built

None of this is conceptually hard, but it is genuinely laborious, and the baseline in particular requires pulling invoices and utilization data from corners of the organization that rarely talk to each other. This is exactly the work an independent assessment accelerates. Our OCI consulting practice builds these business cases as a standing discipline, with 20+ years of combined experience across data center exits of every size, and the deliverable is a board ready case with the baseline, target, bridge, and payback fully evidenced. The difference between a business case assembled in a spreadsheet over a weekend and one built from measured data is usually the difference between a project that gets approved and one that gets approved and then delivers.