What an OCI Migration Really Costs: Assessment to Go Live

Every organization that starts pricing an OCI migration runs into the same uncomfortable discovery: nobody will give them a straight number. One firm quotes a figure that seems impossibly low, another quotes five times as much for what sounds like the same work, and the internal estimate sits somewhere in between, built on assumptions nobody has tested. The instinct is to assume someone is padding or someone is lowballing, and sometimes that is true. But the more common explanation is that the three quotes are pricing three different projects, because the scope of an Oracle migration is genuinely ambiguous until somebody does the work to pin it down.

This guide exists to remove that ambiguity. Across 500+ OCI engagements we have seen migrations priced well, priced badly, and priced in ways that were technically accurate but commercially misleading. The pattern that separates good outcomes from bad ones is not the size of the number. It is whether the number was built on a real assessment, whether it covered all the cost components rather than just the visible ones, and whether anyone planned for what happens after go live. We will take each of those in turn.

Why migration quotes vary so wildly

Start with the question that frustrates every buyer. Why does the same estate attract such different prices? There are four structural reasons, and understanding them is the fastest way to make competing quotes comparable.

First, the quotes assume different migration methods. A lift and shift of a database onto OCI compute is a fundamentally different project from a replatform onto a managed database service, which is different again from a modernization that touches application code. Each method carries a different effort profile, a different risk profile, and a different cost on the other side. A quote that does not state its method per workload is not a quote, it is a guess. Our breakdown of database migration cost on OCI shows how much the method choice alone moves the number for a single database.

Second, the quotes draw the boundary in different places. Some include the landing zone build, some assume it exists. Some include the period where old and new environments run side by side, some treat that as your problem. Some include a hypercare window after cutover, some end at the moment the workload boots. We wrote a full dissection of this problem in our guide to the anatomy of an OCI migration quote, and the short version is that the cheapest quote is usually the one with the most scope quietly left outside the boundary.

Third, the quotes price risk differently. A fixed project fee transfers delivery risk to the firm, so a responsible firm prices the unknowns it has not yet been allowed to investigate. A loosely scoped time and materials engagement transfers that risk to you, so it can open with a smaller number and grow. Neither model is wrong, but comparing a fixed fee against an open meter as if they were the same kind of number is how buyers get surprised.

Fourth, the estates themselves are unknown. Most organizations do not have an accurate inventory of what they run. Configuration databases are stale, dependencies are undocumented, and the application list maintained by the architecture team rarely matches what discovery tooling actually finds. Any quote produced before discovery is priced against an imaginary estate, and the correction always arrives later, as a change order.

The assessment phase: what it should cost and what it should produce

The assessment is the single highest leverage spend in the entire program, and it is also the part most often skipped or hollowed out. A proper OCI migration assessment for a midsize Oracle estate typically runs two to six weeks and costs somewhere between fifteen and seventy five thousand dollars depending on estate size and depth, which sounds like real money until you set it against what it prevents. A wrong sizing assumption on an Exadata workload, a missed interface that surfaces in week two of cutover, or a licensing position that does not survive contact with bring your own license rules can each cost more than the whole assessment did.

What should the assessment produce? Not a slide deck with a logo wall. The deliverables that actually matter are concrete: a verified inventory of every server, database, and application in scope with versions and sizes; a dependency map showing what talks to what; a target architecture on OCI with shapes and services named, not gestured at; a migration method assigned to every workload; a wave plan with sequencing logic; a cost model covering both the project and the first three years of run cost; and a risk register with owners. If you want the full checklist of what a credible assessment covers, we maintain a detailed OCI migration assessment checklist that you can hold any firm against, including us.

Discovery and dependency mapping

Inside the assessment, discovery is where the truth lives. Automated discovery tooling deployed against the estate for two to four weeks will find the servers nobody remembered, the database links nobody documented, and the batch jobs that connect systems the architecture diagram says are unrelated. Dependency mapping is the part that determines wave planning later: two applications that share a database, exchange files nightly, or sit behind the same integration layer generally need to move together or have the interface bridged, and finding that out during discovery costs a fraction of finding it out during cutover.

Discovery also produces the performance baseline. CPU, memory, storage, and IO profiles captured over a representative period, including at least one month end if the estate has financial workloads, are what let the target architecture be sized to reality rather than to nameplate capacity. Estates are routinely provisioned on premises at two or three times what they use, and carrying that overprovisioning into the cloud is the single most common way migrations destroy their own business case before they start.

The proof of concept question

For estates with unusual workloads, heavy customization, or a database platform decision that is genuinely open, a small proof of concept after the assessment is money well spent. The trick is scoping it so it answers a specific question, performance of a known workload on a specific shape, viability of a particular migration tool against your data volumes, rather than becoming a miniature migration with no end state. We cover how to keep that contained, and what a sensible one costs, in our guide to scoping an OCI proof of concept.

The cost components, one by one

With the assessment done, the real budget can be assembled. Every OCI migration budget is built from the same seven components, and a quote that is silent on any of them is incomplete.

Landing zone build

Before anything migrates, OCI itself has to be built: compartment structure, identity integration, network topology, connectivity back to your sites, security policy, logging, and the guardrails that stop the first project team from making decisions the whole organization has to live with. A landing zone for a straightforward estate is a few weeks of work; one for a regulated enterprise with multiple business units and strict segregation can be a project in its own right. Realistic figures and the factors that move them are in our breakdown of OCI landing zone cost. Skipping or rushing this step does not save the money, it defers it with interest, because retrofitting governance onto a populated tenancy is far more expensive than building it in.

Migration execution

Execution is the visible core of the budget: the per workload effort of replicating data, standing up the target, converting what needs converting, testing, and cutting over. Effort scales with method, data volume, and customization rather than with raw server count. A standard database moves in days; a heavily customized application platform takes months. The packaged application estates have their own well understood cost profiles, which is why we publish dedicated guides to EBS to OCI migration cost, PeopleSoft migration cost, and JD Edwards migration cost. Organizations running SAP on Oracle databases face a distinct set of choices that we cover separately in SAP to OCI cost.

Tooling

Migration tooling is a smaller line than people expect, partly because OCI includes capable native services for database and compute migration at no extra license cost, and partly because the expensive commercial tools earn their keep only on specific problems: minimal downtime replication for very large databases, mass discovery across thousands of servers, or complex transformation. Budget a real number for it, but be suspicious of quotes where tooling is a major profit line. Our guide to migration tooling costs maps which tools are worth paying for and which problems the included options already solve.

Dual running

Here is the component that most often blows the budget, because it appears on no purchase order. From the moment the first OCI environment is built until the last legacy system is switched off, you are paying for two estates. Cloud consumption ramps up while the data center, the hardware support contracts, and the software running on both sides keep costing what they always cost. A migration that slips by six months does not just cost six months of project fees, it costs six months of duplicated infrastructure. The discipline of compressing this window, and the realistic figures for what it consumes, are covered in our analysis of OCI dual running costs.

Downtime

Every cutover has a window, and the window has a price: lost transactions, idle staff, missed commitments, and the overtime of the people working the weekend. For some systems an eight hour outage is free because nobody is using them on a Sunday morning; for others, an hour of unavailability costs more than the entire migration of that workload. Pricing the window honestly per system is what justifies, or rules out, the more expensive near zero downtime methods. We walk through how to put a defensible number on it in the cost of migration downtime.

People

The people cost has two halves. The external half is the migration partner, whose pricing model matters as much as their rate, more on that below. The internal half is the one organizations forget to budget: your DBAs validating data, your application owners running test cycles, your network team standing up connectivity, your service desk handling the cutover weekend. A meaningful migration consumes twenty to forty percent of the time of the internal teams that own the affected systems, for months. That time is either backfilled, which costs money, or absorbed, which costs every other initiative those people were working on.

Licensing

Oracle licensing can make or break the economics of the whole move. Bring your own license versus license included pricing, processor counting on OCI shapes, support stream implications, and what happens to the licenses left behind in the data center are all decisions with six and seven figure consequences, and they need to be made before the architecture is fixed, not after. This is specialist territory, and it is where an independent licensing firm earns its place in the program alongside the infrastructure work.

Realistic ranges by estate size

With the components defined, here is what complete migrations actually cost. These ranges come from real engagements and include assessment, landing zone, execution, tooling, and partner fees; they exclude internal staff time and dual running, which vary too much by organization to generalize. Treat them as calibration, not as a quote.

Two notes on the table. First, the full exit tier has economics of its own, because the savings only land when the building actually empties: the business case stands or falls on the last ten percent of systems, not the first ninety. We built a complete model for that scenario in our data center exit business case guide. Second, the ranges describe the project cost, not the value. The question of when the spend pays itself back, typically through retired hardware, exited facilities, reduced support contracts, and a lower run rate, is modeled in our OCI migration ROI timeline analysis, and for most estates the answer is between eighteen and thirty six months from the start of the program.

Wave planning: where sequencing becomes money

Anything beyond a single application moves in waves, and the wave plan is where sequencing decisions turn directly into cost. The logic is straightforward to state and hard to do well: group workloads so that dependencies move together, start with a wave that is low risk but real enough to prove the pipeline, schedule the heaviest validation around the people who must do it, and order the waves so that legacy infrastructure can be switched off progressively rather than all at the end. A well built wave plan shortens the dual running window, smooths the load on internal teams, and gives the program early wins that keep sponsorship alive. A bad one keeps both estates running at full cost until a big bang finale that everyone dreads. The mechanics, and what wave planning itself should cost within the program, are detailed in our guide to migration wave planning cost.

The wave plan is also the honest schedule. When a firm shows you a wave plan with named systems, named dependencies, and named validation owners, you are looking at a plan. When the proposal shows four chevrons labeled discover, migrate, validate, optimize, you are looking at clip art.

The post go live optimization pass

Here is the part of the economics that almost every migration plan omits, and it is the part with the best return in the entire program. A migration sized from on premises baselines lands on OCI carrying the caution of the project: shapes provisioned for the peak that discovery measured plus a safety margin, storage tiers chosen conservatively, environments cloned at production scale, and Universal Credits committed before anyone knew the real consumption curve. That caution is correct during cutover. Ninety days after go live, it is pure waste.

The optimization pass that follows, right sizing shapes against observed utilization, tiering storage, scheduling nonproduction environments to switch off outside working hours, restructuring the credit commitment around real consumption, and revisiting the licensing mix, reduces OCI spend by 40% on average across the estates we have worked on. That is not a marketing round number; it is the average across engagements where the savings were measured against the bill before and after. The full method is documented in our guide to post migration optimization savings, and the existence of this pass should change how you read every migration business case: the run rate at go live is not the run rate you will live with, provided someone actually does the work.

This is also where ongoing operations enter the picture. An estate that is monitored 24/7/365 and reviewed on a cadence stays optimized; one that is migrated and abandoned drifts back toward waste within a year. Whether that operating layer is your team, a managed service, or a hybrid is a separate decision, but it belongs in the total cost of ownership math from the start.

How to judge a quote

Pull all of the above together and judging a migration quote becomes a checklist rather than a gut feel. Here is the framework we suggest buyers apply to every proposal, including ours.

How the work is priced, and what to prefer when

A word on commercial models, because the structure of the fee shapes the behavior of the firm. There are three models worth considering. A fixed project fee is right for assessed, well bounded work: the firm carries delivery risk, you get budget certainty, and the assessment that precedes it is what makes the fixed number honest rather than padded. A managed monthly retainer is right for the operating phase after go live, where the work is continuous, monitoring, patching, incident response, cost review, and a predictable monthly figure beats a meter. And for optimization specifically, the cleanest alignment available anywhere in this market is an optimization fee charged as a percentage of verified savings, with no savings, no fee: the firm only earns when your bill measurably drops, which removes every incentive to find theoretical savings that never reach the invoice.

Most full programs end up combining them: a fixed fee for assessment and migration through our OCI implementation practice, a retainer for managed operations afterward, and a contingent fee for the optimization pass. The combination matters less than the principle: each phase should be priced in the model that aligns the firm's incentive with your outcome for that phase.

Bringing it together

An OCI migration is not one number, it is a sequence of decisions, each with a price. The assessment turns an imaginary estate into a real one. The seven cost components turn a vague quote into a complete budget. The wave plan turns the schedule into money saved or money burned. And the optimization pass after go live, the step most plans omit, is where the 40% average reduction lives. If you take one action from this guide, make it this: do not accept a migration price from anyone, including us, until a real assessment has been done, and do not sign a contract that ends at cutover. For the deeper reference material, our OCI migration playbook covers the full method end to end, and the cluster of guides linked throughout this article goes deeper on every component named here.