Pricing Downtime: What an Outage Window Really Costs

Ask a business owner how much downtime their system can tolerate during a migration and you will almost always get one of two answers: none, or a shrug. Neither is useful, and both are expensive. The team that hears none buys the most elaborate replication tooling available for a reporting database that nobody touches on a Sunday. The team that gets the shrug books a casual twelve hour window for an order system and discovers at two in the morning what an hour of lost orders actually costs. The fix for both failures is the same: price the outage hour before you choose the migration method, so that downtime tolerance becomes a budget input with a number attached rather than an opinion offered in a meeting.

This article is part of our series on what an OCI migration really costs, and it covers the cost line that is hardest to see on any quote because it never appears on one: the price of the system being unavailable while you move it. Across 500+ engagements we have found that the downtime number, once it is honestly calculated, changes more migration decisions than any other single figure in the business case.

What an hour of downtime is actually made of

The reason downtime gets guessed at instead of priced is that the cost hides in several places at once, and no single team owns all of them. A credible hourly figure adds up at least six components, and most organizations are surprised by which ones dominate.

Lost revenue is the obvious line. If the system takes orders, processes payments, or serves customers directly, every hour of outage is an hour of transactions that either vanish or defer. The honest calculation distinguishes between the two: a retail customer who finds the site down often buys elsewhere and the revenue is gone, while a B2B order placed Monday morning instead of Sunday night is mostly deferred. The split matters because deferred revenue costs you cash flow and the permanently lost portion costs you the margin outright.

Idle labor is the line everyone forgets. If a warehouse system is down, the warehouse staff are still being paid. If a claims platform is offline, the claims handlers sit and wait. For systems that large workforces depend on, the fully loaded hourly cost of the people who cannot work often exceeds the lost revenue, especially for internal systems that earn no revenue directly but keep hundreds of people productive.

SLA penalties apply when the system serves external customers under contract. Service credits, penalty clauses, and contractual uptime commitments turn outage hours directly into invoiced losses. These are usually the easiest component to quantify because the contract states the number, and the most embarrassing to discover after the window has been booked.

Batch backlog and catch up is the hidden tail. A system that is down for eight hours does not return to normal when it comes back up. Interfaces queue, batch jobs stack, and the first day after cutover is spent processing the backlog at degraded performance while users pile on. For integration heavy estates, the catch up period can stretch the effective business disruption to two or three times the nominal outage window, and it should be priced as part of the outage, not treated as a free epilogue.

Reputation and customer churn resist precise measurement but should not be priced at zero. A visible outage on a customer facing platform generates support tickets, social noise, and a measurable uptick in churn among customers who were already wavering. A conservative approach assigns a small percentage of at risk customer lifetime value rather than ignoring the effect entirely.

Regulatory exposure applies to a minority of systems but dominates where it applies. Payment platforms, trading systems, healthcare records, and anything with statutory reporting deadlines can convert an outage into regulatory findings, mandatory disclosures, or fines. Where this applies, the downtime price per hour can be an order of magnitude above everything else combined, and it usually settles the method question on its own.

Downtime price varies wildly by system class

Once you run this calculation across an estate, the spread is dramatic, and the spread is the whole point. A tier one revenue system might cost six figures per hour of outage when you stack revenue, labor, penalties, and catch up. A development database costs effectively nothing. A back office system used by forty people costs the loaded hourly rate of forty people plus some batch catch up. Pricing each system class separately is what allows you to spend migration money where the downtime is expensive and save it where the downtime is cheap, which is the same logic that drives grouping decisions in wave planning: systems with similar downtime prices tend to belong in the same wave, because they justify the same method and the same level of rehearsal.

How the downtime price chooses the migration method

Migration methods exist on a spectrum that trades outage length against tooling and effort cost. At one end, a straightforward export and import with Data Pump is cheap to set up, simple to execute, and requires the source system to be quiet for the entire transfer, which for a large database can mean many hours or a full weekend. At the other end, Zero Downtime Migration and GoldenGate replication keep the source running while data synchronizes continuously, shrinking the cutover to minutes, at the price of licensing, infrastructure, configuration effort, and a longer period of running both environments, the economics of which we cover in the cost of dual running.

The table only becomes useful when you attach your own downtime price to it. A system whose outage costs two thousand per hour does not justify GoldenGate: a weekend window with Data Pump costs the business a modest amount and the tooling almost nothing. A system whose outage costs eighty thousand per hour justifies almost any tooling spend that takes the window from twelve hours to twelve minutes. The mistake we see most often in assessments is uniformity: one method chosen for the entire estate, which means either tier one systems exposed to long windows they cannot afford or trivial systems carrying replication costs they will never repay. The full tooling side of this equation, including what the licensed options actually cost, is covered in our companion piece on migration tooling costs.

The break even logic

The decision reduces to a simple comparison. Take the cheap method and the expensive method for a given system. The cheap method costs little to execute but imposes a long outage; multiply the outage hours by your downtime price per hour. The expensive method imposes almost no outage but adds tooling, licensing, dual running, and effort; total those costs. Whichever sum is smaller wins. For a database where the cheap method means a ten hour window and the downtime price is three thousand per hour, the outage costs thirty thousand; if the near zero downtime approach adds fifty thousand in tooling and effort, the long window is the rational choice, however uncomfortable it feels. Reverse the numbers and the conclusion reverses with them. The arithmetic is trivial. The discipline is doing it per system instead of deciding by instinct, and being honest about the downtime price rather than inflating it to justify tooling someone already wants to buy.

Planning the cutover window itself

Whatever method the arithmetic selects, the window itself is a project artifact that deserves engineering. Three practices separate clean cutovers from expensive ones.

Rehearsals. Every production cutover should be rehearsed at least once against a realistic copy, with the clock running. The rehearsal tells you the real duration of the window, not the optimistic estimate, and it surfaces the surprises, the slow step, the missing grant, the interface that will not start, while they are free to fix. Rehearsal time costs engineering hours; an overrun on the night costs the downtime price per hour for every hour past the plan, plus the credibility you need for the next window. For high downtime price systems, two or three rehearsals are cheap insurance.

Rollback points. A well designed window has explicit decision gates: by this hour the data must be transferred, by this hour validation must pass, and if a gate is missed, the team rolls back to the source system rather than pressing on into the business day. The rollback path must itself be tested, because an untested rollback is a hope, not a plan. Defining the gates in advance removes the worst failure mode of cutover nights, which is a tired team improvising at four in the morning with the downtime meter running.

Freeze periods. Around the window, changes to the source system, its interfaces, and the surrounding infrastructure should be frozen. Every change made in the days before cutover is a variable that rehearsals did not cover. Freezes have a real business cost, deferred releases and delayed fixes, and that cost belongs in the migration business case too, particularly for long replication based migrations where a partial freeze can persist for weeks while environments synchronize.

A framework for pricing an outage window

To turn all of this into a number the business can sign, work through the following sequence for each system before any method is chosen.

Negotiating the window with the business

The final step is the conversation, and the downtime price transforms it. Without a number, the negotiation is positional: the business says the system can never be down, the migration team says it has to be, and the result is decided by whoever escalates harder. With a number, the conversation becomes commercial. Asking a business owner whether they will accept a ten hour Sunday window is an invitation to say no. Showing them that the Sunday window costs the business eighteen thousand and the near zero alternative costs ninety thousand in tooling and dual running is an invitation to make a sensible decision, and in our experience they almost always do. The same number also buys flexibility in the other direction: when a genuinely critical system shows a six figure hourly price, the tooling budget that once looked extravagant approves itself.

It helps to bring options rather than a single proposal: two or three window and method combinations with the total cost of each, including the outage priced honestly. It also helps to bring evidence, which is where rehearsal results earn their keep, because a business owner who has seen the rehearsal complete in four hours will sign a six hour window with confidence. This is the working method our team applies in every OCI implementation engagement, with 20+ years of combined Oracle estate experience behind the estimates and 24/7/365 coverage through the cutover windows themselves, on a fixed project fee so an overrun in effort is our problem rather than a change request. For estates that stay with us after go live, the same discipline continues under a managed monthly retainer, and where the goal is reclaiming spend, an optimization fee paid only on verified savings.

Downtime is the migration cost that never appears on a quote and frequently exceeds everything that does. Price it per system, per hour, and per window timing, let the break even arithmetic choose the method, engineer the window with rehearsals and rollback gates, and put the signed number in front of the business before anyone books a weekend. The teams that do this spend less on tooling than the cautious and lose less to outages than the casual, which is the entire game.