Fixed Price OCI Migrations: What Should Be in Scope

Every disputed migration we have ever been asked to rescue had the same artifact at its center: a fixed price contract whose scope section was two pages long, optimistic, and silent on the questions that actually decide success. The buyer believed they had bought a finished migration. The provider believed they had sold a defined set of activities. Both were holding the same document, and the gap between those two readings cost months of delay and a change order pile that ate the supposed price certainty alive. The fixed price model was not the problem. The scope was.

This article is part of our complete guide to hiring an OCI partner, and it deals with one document: the scope of a fixed price OCI migration. What must be inside it, what providers routinely leave outside it, how contingency and change control really work, and what acceptance criteria look like when they are written by someone who has been through a cutover weekend.

Why fixed price suits migrations

Of all the work an OCI partner can sell you, a migration is the best candidate for a fixed price, because it has the one property the model requires: a definable end state. Either the workloads run on OCI to an agreed standard or they do not. Compare that with advisory work or ongoing operations, where the end state is fuzzy and time based models fit better, a tradeoff our guide to OCI consulting rates in 2026 covers across all five commercial models.

A fixed project fee moves delivery risk from you to the provider. If the database migration takes three attempts instead of one, the provider absorbs the cost. In exchange, the provider prices in contingency and polices the scope boundary, which is fair and predictable. The trouble starts when buyers treat the fixed number as a guarantee of an outcome the scope never actually described. Price certainty on a fixed price migration is not produced by the price. It is produced by the scope, and that is where your attention belongs before signature.

What a complete migration scope includes

A defensible OCI migration scope covers eight layers, and a proposal that skips any of them is not cheaper, it is incomplete. Discovery and dependency mapping comes first: an inventory of servers, databases, applications, integrations, and the dependencies between them, because the migrations that fail in wave three fail on a dependency nobody mapped in week one. The landing zone is the OCI foundation, compartments, policies, tagging, logging, and guardrails, and it must be in scope explicitly because some providers assume it exists and price as if it does. Network and identity covers connectivity to your sites and clouds, DNS, federation with your identity provider, and the firewall and routing design that everything else sits on.

The database migration method deserves its own named section: which databases move with Data Pump, which with Data Guard, which with GoldenGate or Zero Downtime Migration, what downtime each method implies, and who validates the result. A scope that says databases will be migrated without naming methods is a scope that has not been engineered. Application migration waves define what moves, in what groups, in what order, with entry and exit criteria per wave. Testing layers must distinguish infrastructure validation, application functional testing, integration testing, and performance comparison, and must say who executes each, because the single most common dispute in fixed price migrations is a provider who tested that servers boot and a buyer who expected tested applications. The cutover plan and rollback describes the run sheet, the go and no go decision points, and the tested path back if cutover fails. And the hypercare window defines how long the migration team stays on heightened support after go live, typically two to four weeks, with what response times, before handover to steady state operations.

One layer above all of these sits the scope of the scope: which workloads are in the migration at all. A complete scope names the applications and databases it covers, by list, with counts and sizes, and states the treatment for each, whether lift and shift, replatform onto a managed OCI service, or rearchitect. It also names what stays behind and why. Migrations grow in the dark; a scope that says approximately forty servers will be migrated is an invitation for the count to become sixty by wave two, with both sides convinced the other agreed to it. The named workload list is the single cheapest piece of dispute insurance in the whole contract, and it costs nothing but the discipline of writing it down.

The exclusions that cause disputes

Exclusions are not dishonest. A provider cannot sensibly fix a price for work whose size they cannot measure, so certain items are excluded by almost everyone. The dishonesty, where it exists, is in the font size. The table below shows where the common items usually land and what an informed buyer negotiates.

Two of these deserve special emphasis. Data cleanup is the exclusion most likely to detonate, because nobody knows how dirty the data is until discovery, and a fixed price cannot absorb an unknown. The mature answer is to keep cleanup on your side of the line and resource it properly, not to pretend the provider will quietly handle it. And source decommissioning is the exclusion most likely to be forgotten, which is how organisations end up paying for two estates a year after a successful migration. If the business case assumed the old data center goes away, someone must be contractually responsible for making it go away.

How providers price contingency, and why you should not squeeze it to zero

Providers price fixed migrations by estimating effort, then adding contingency of roughly 15 to 30 percent depending on how much is unknown. That margin is not padding to negotiate away. It is the insurance premium you are choosing to pay when you choose the model, and a provider squeezed to zero contingency does not absorb surprises, they litigate the scope boundary on every one. The cheapest sustainable fixed price comes not from squeezing margin but from shrinking the unknowns: a paid discovery phase before the fixed price is set, so both sides commit to a number after the estate is understood rather than before. Experience compresses the premium too, which is one reason engagement history matters when you compare bids; a team drawing on 500+ OCI engagements and 20+ years of combined Oracle experience has seen most surprises before and prices them tighter than a team guessing. Structuring competing bids so contingency and assumptions are visible and comparable is exactly what a disciplined tender achieves, and our guide to writing an OCI services RFP shows how to force that visibility.

Change control that works

Every fixed price migration meets reality, and reality produces changes. The difference between a healthy engagement and a hostage situation is whether the change mechanism was designed before it was needed. Working change control has four properties. Changes are written, never verbal, with effort and price quoted before work starts. Pricing for changes is pre agreed in the contract, with rate cards or unit prices, so each change order is arithmetic rather than a fresh negotiation. There is a materiality threshold, so trivial variances are absorbed and only genuine scope movement triggers paperwork. And there is a named decision maker on your side with a service level on decisions, because a provider waiting two weeks for a change approval is a provider with a legitimate delay claim. Evaluating how a consultancy behaves around change, before you hire them, is one of the strongest selection signals there is, and we cover how to test for it in choosing an OCI consultancy.

Acceptance criteria that protect both sides

Acceptance criteria are where scope stops being prose and becomes testable. Weak criteria say the system will function correctly on OCI, which means whatever the louder party says it means. Strong criteria are measurable, sampled, and agreed before signing. Examples worth adapting: every migrated database passes a row count and checksum validation against the source at cutover. The five named critical transactions complete within 110 percent of their measured source baseline under the agreed test load. A full backup and a timed restore of each production database completes successfully in OCI before go live. Failover to the standby region for the two designated critical systems is demonstrated, not described. All compartments, budgets, alarms, and logging defined in the landing zone design are live and evidenced. And hypercare exit requires a defined period, say ten business days, with no open severity one or severity two incidents attributable to the migration.

Notice what good criteria do for the provider as well as for you. They define done, which means they define the moment the provider gets paid and released. Providers with real delivery confidence welcome sharp acceptance criteria for exactly that reason, and a provider who pushes back on measurable acceptance is telling you something about their estimate.

The eight point scope checklist before signing

Before any fixed price migration contract gets a signature, walk it through this checklist. Every no is a negotiation you should have now rather than a dispute you will have later.

Getting from signature to a clean cutover

A well scoped fixed price migration is one of the most predictable purchases in enterprise IT, which is why it remains the model we recommend for most moves to OCI and the way our own OCI implementation engagements are structured: a fixed project fee against a scope built the way this article describes. The fixed fee also pairs naturally with what comes after. Steady state operations fit a managed monthly retainer rather than a project price, and a post migration optimization pass works best on a percentage of verified savings, where no savings means no fee; across our optimization work the average OCI spend reduction is 40 percent, often because migration sizing decisions were never revisited.

The scope document earns its keep twice. Once at signature, when it sets the price, and again in the first weeks of delivery, when it becomes the working agenda for the team. What those first weeks should look like, from kickoff through the first wave, is covered in our companion piece on the first 30 days of an OCI engagement. Get the scope right and the rest of the migration is execution. Get it wrong and no price, fixed or otherwise, will save you.