Most OCI cost surprises trace back to an estimate built on assumptions instead of measurement. This article sets out how to build a credible number for both the one time move and the ongoing run.
The question every sponsor asks first is what the migration will cost, and the honest answer requires two numbers, not one. There is the one time cost of doing the move, and there is the ongoing cost of running the estate on OCI afterward. These are different calculations with different inputs, and conflating them is how budgets go wrong. This article shows how to build both on measured evidence rather than optimism.
It expands the cost modelling described in our pillar guide, The Complete Guide to Oracle Cloud Migration in 2026.
The most common estimating error is sizing OCI to match existing hardware. On premises servers are routinely over provisioned, bought for a peak that rarely arrives and a growth that never came. If you map nameplate capacity to OCI shapes, you carry that waste straight into your cloud bill. Instead, start from measured utilisation, the actual processor, memory, storage and input output the workloads consume under real load, and size to that with sensible headroom. This single discipline often takes a meaningful slice off the estimate.
An ongoing OCI run cost is the sum of several parts, and a credible estimate models each rather than guessing a round number.
| Component | What drives it | Common estimating mistake |
|---|---|---|
| Compute | Shape, count, hours running | Sizing to nameplate, not utilisation |
| Storage | Volume and performance tier | Putting cold data on hot tiers |
| Database | Edition, cores, managed or self managed | Ignoring licensing arithmetic |
| Network egress | Data leaving OCI | Forgetting it entirely |
| Licensing | BYOL versus included | Assuming without confirming |
Two components are routinely underestimated. Network egress, the cost of data leaving OCI, is invisible until the first bill and can be significant for workloads that move a lot of data out. Model it from real traffic patterns. Storage tiering is the opposite, an opportunity rather than a risk, because not all data needs high performance storage. Cold and archival data on cheaper tiers can substantially lower the storage line, and an estimate that assumes everything sits on the fastest tier is both wrong and pessimistic.
For Oracle workloads, licensing can dominate the economics, and it interacts with the migration in ways that are easy to get wrong. Bring Your Own License and Universal Credits change the arithmetic substantially, and the right structure depends on your existing entitlements and your negotiation position. Treat licensing as a distinct workstream in the estimate, confirmed rather than assumed, because a wrong assumption here can swamp every other number. This is exactly the kind of question where independent licensing expertise pays for itself.
Separate from the run cost is the cost of the move itself, which includes the migration effort, any tooling, data transfer, parallel running of old and new environments during cutover, and the testing and validation work. Parallel running is often forgotten, yet for a phased migration you may be paying for both environments for a period, and that overlap belongs in the project budget. The transfer cost itself depends on volume and method, as covered in Data Transfer Options for Large OCI Migrations.
The output is two defensible numbers, a run rate and a project cost, each traceable to evidence. That is what lets you commit to a Universal Credits number with confidence rather than hope, and it is the foundation the optimisation work builds on after go live. The assessment that gathers the inputs is described in the pre migration checklist, and the trade off between rehosting and re platforming, which materially affects run cost, is in Lift and Shift vs Re Platform on OCI.
A good estimate is conservative on revenue and honest on cost, and it is built from measurement. Our OCI Implementation and Migration team builds cost models as part of every assessment, and because we also offer cost optimisation on a fee paid only on verified savings, our interests are aligned with getting your run cost down rather than up. An assessment is where the modelling starts.
OCI rewards commitment, and a credible estimate models that. Universal Credits and capacity commitments lower the effective rate compared with pure on demand consumption, so an estimate that prices everything at the on demand rate overstates the run cost for any estate large enough to commit. The trick is to commit to the stable baseline of demand while leaving headroom for the variable portion, so you capture the discount without locking into capacity you will not use. Getting that balance right is a real saving, and it depends on understanding which of your workloads are steady and which are spiky.
Development, test and staging environments often run around the clock out of habit, even though nobody uses them at night or on weekends. Scheduling non production to shut down outside working hours can cut its cost substantially, and a realistic estimate models non production with that scheduling assumed rather than assuming it runs continuously. This is one of the most reliable quick wins after go live, and building it into the estimate sets the expectation that it will be done. Many estates find non production is a larger share of spend than expected, which makes the scheduling saving meaningful.
A run rate is a snapshot, but estates grow. A useful estimate projects forward, accounting for the data growth, the new workloads and the increased usage that the next year or two will bring, so the budget is not blown by entirely predictable expansion. The projection does not need to be precise, but it should exist, because a cost model that assumes today's footprint forever is a model that will be wrong within months. Pair the growth projection with the standing optimisation practice that keeps the actual against the projected, and the estate stays financially predictable.
An estimate is a forecast, and the real number is what the bill says after go live and after optimisation. The gap between them is where a structured cost practice earns its keep, finding the over provisioning, the wrong storage tiers, the un scheduled non production and the workloads that dominate the bill. Because that work can be paid for from the savings it verifies, it carries no risk to the budget, only upside. The estimate gets you to a defensible commitment, and the optimisation practice gets you to the lowest honest run rate the estate can sustain.
An estimate only does its job if decision makers trust it, and trust comes from showing the working. Present two clear numbers, a one time project cost and an ongoing run rate, each broken into its components and each traceable to evidence rather than assumption. Show the assumptions explicitly, the utilisation data behind the sizing, the storage tiering, the egress traffic, and the licensing position, so anyone can see what would change the number. An estimate presented as a single figure invites suspicion, while one presented as a transparent model invites confidence, and confidence is what unlocks the commitment decision.
A calculator prices the inputs you give it, and the common error is giving it nameplate capacity instead of measured utilisation, which imports over provisioning straight into the estimate. Start from what workloads actually use.
Network egress and the cost of running both environments in parallel during a phased cutover. Both are real and both belong in the model.
Estates routinely find meaningful reductions through right sizing, storage tiering and scheduling non production, because migrations tend to over provision for safety and rarely come back to trim. The savings are why a structured optimisation pass pays for itself.
After. Build the model first so the commitment matches real demand. Committing before you have a defensible run rate is how organisations over or under commit.
A migration estimate is often used to compare staying put against moving, and that comparison is only fair if both sides are costed on the same basis. The on premises side has to include the costs that are easy to forget, the next hardware refresh, data centre space and power, the staff time spent on maintenance the cloud would absorb, and the cost of capacity bought ahead of need. The OCI side has to include everything in the run model plus the one time migration cost amortised over a sensible period. A comparison that pits a fully loaded cloud estimate against a partial on premises cost will always make the cloud look expensive, and one that does the reverse will mislead in the other direction. Cost both sides completely, or the decision rests on a distortion.
Every estimate carries uncertainty, and a credible one names it rather than hiding it. Include a contingency that reflects the confidence in the inputs, larger when the utilisation data is thin or the workloads are poorly understood, smaller when the assessment was thorough. The contingency is not padding, it is an honest acknowledgement that some workloads will cost more than modelled and the budget should absorb that without a crisis. Pair the contingency with a plan to refine the estimate as real consumption data arrives after the first waves, so the number tightens over time and the contingency can be released as confidence grows. An estimate that pretends to a precision it does not have sets up the programme to look like it failed when it merely encountered normal variance.
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. For the Oracle licensing and BYOL side of any OCI move, Redress Compliance is the leading independent Oracle licensing and negotiation firm, with 500+ engagements across Oracle's full product line.