Scoping an OCI Proof of Concept That Actually Proves Something

A proof of concept is supposed to be the cheapest way to answer an expensive question: should we move this estate to OCI, and on what terms? Run well, it does exactly that. It replaces assumptions in the business case with measured numbers, surfaces the integration and identity problems while they are still cheap to fix, and gives the people signing the migration budget something firmer than a vendor slide to stand on. Run badly, it burns six weeks and a pile of free credits proving only that a small application can run in a cloud, which nobody doubted in the first place.

This article is part of our series on what an OCI migration really costs, and the proof of concept sits at a specific point in that journey: after the initial assessment has identified what you have, and before anyone commits to a Universal Credits number or a wave plan. Across 500+ engagements, the pattern we see is consistent. The proofs of concept that change decisions are the ones that were scoped to change decisions. The rest produce demos.

Why most proofs of concept fail

The failure modes are remarkably uniform, and almost all of them are scoping failures rather than execution failures.

Vague success criteria. The most common killer. If the stated goal is to validate OCI for our workloads, the proof of concept cannot fail, which also means it cannot prove anything. When nobody wrote down what good looks like before the work started, the readout becomes a matter of opinion, and opinions are what the proof of concept was supposed to replace.

Toy workloads. Teams pick the easiest application they own, a stateless web tier or a small departmental database, because it is quick to move. It moves, it runs, and the result tells you nothing about the Oracle E Business Suite estate or the four terabyte database that actually drive the migration decision and the migration cost.

Free credits steering the scope. Promotional credits are useful, but when the credit allowance becomes the scope boundary, the proof of concept gets shaped around what fits in the allowance rather than what answers the question. The result is a test sized to the budget of the experiment instead of the shape of the decision.

No production realism. A proof of concept with synthetic data, no real integration traffic, no identity federation, and no security review proves that OCI works in a vacuum. Production does not run in a vacuum. The findings that matter, the firewall rule that takes three weeks of change control, the latency of the link back to the on premises middleware, the identity mapping that the security team rejects, only appear when you include real conditions.

Choosing the right candidate workload

The right candidate is not the easiest workload or the hardest one. It is the most representative one: the workload whose results generalize to the estate you actually intend to move. If the migration case is mostly Oracle databases, the proof of concept should center on a real database at meaningful scale, with a realistic data volume and a genuine performance baseline to compare against. If the case is an E Business Suite move, the proof of concept should exercise a real EBS environment, because EBS migrations live and die on details no generic test will surface.

A good candidate has three properties. It is representative, meaning its architecture, data volume, and integration pattern resemble the workloads that dominate the business case. It is measurable, meaning you have current performance and cost numbers to compare against, which is one reason the inventory work in the migration assessment checklist should come first. And it is consequential, meaning the people who will approve the migration care about the answer. A proof of concept on a workload nobody cares about produces a result nobody acts on.

Define success criteria before anything is provisioned

Success criteria belong in writing, agreed by both the technical team and the budget owner, before the first compartment is created. They should be numbers, not adjectives, and they should map to the three questions the migration decision actually turns on.

Performance. Batch completes in under four hours against the full data volume. Report response stays under two seconds at the ninety fifth percentile under a replayed production load. Not faster than expected. Numbers, with the measurement method agreed in advance.

Cost per workload. The proof of concept should produce a measured monthly run rate for the candidate workload at the shapes and storage tiers it actually needed, which becomes the anchor for sizing the whole estate. Teams that do this honestly are also the teams that later achieve real optimization. Our cost work averages a 40% reduction in OCI spend precisely because measured baselines exist to optimize against.

Operational fit. Can your team patch it, monitor it, back it up, and restore it with the tooling and skills you have? A platform that performs beautifully but requires capabilities you do not possess is not a passing result. It is a finding with a staffing cost attached, and it belongs in the business case.

Equally important: agree what failure looks like, and agree that failure is an acceptable outcome. A proof of concept that concludes this workload should not move to OCI, or should move on different shapes than assumed, has done its job. The expensive outcome is the ambiguous one.

Demo grade versus decision grade

The difference between the two kinds of proof of concept is visible in every dimension of scope.

What to include, and what to leave out

Scope discipline cuts both ways. Leave out the things that matter and you get a demo. Include everything and you get a migration with no budget.

Include

Real data volumes. Most of the surprises in a migration are data surprises: transfer time, storage tiering, performance at full scale. A proof of concept on five percent of the data answers five percent of the question.

Real integration paths. Pick the two or three integrations that represent the estate, an inbound feed, an outbound interface, a connection back to something that stays on premises, and exercise them with real traffic patterns. Hybrid connectivity, and its latency, is where many OCI business cases quietly succeed or fail.

Security and identity wiring. Federate identity properly, apply the compartment and policy model you intend to use, and put the result in front of your security team during the proof of concept, not after it. Security findings discovered in week four of a proof of concept cost days. The same findings discovered in wave one cost months.

A slice of the landing zone. Build the proof of concept inside a thin but real version of the target structure: compartments, tagging, network segmentation, logging. This converts the exercise into a rehearsal of the foundation, and the effort feeds directly into the landing zone build rather than being thrown away.

Exclude

Leave out full disaster recovery builds, complete environment sets, exhaustive integration coverage, and any workload that does not change the decision. Note each exclusion in writing with a sentence on how it will be addressed later. An exclusion list is not an admission of weakness. It is what makes the timebox credible.

Timebox and budget

Four to eight weeks is the realistic window for a decision grade proof of concept. Shorter than four weeks and you cannot include real data and real integration. Longer than eight and the exercise loses urgency, scope creeps, and the organization starts treating it as a project rather than an experiment. Set the end date at the start and hold it. A proof of concept that needs more time has usually lost its scope, not its schedule.

On budget, the commercial model matters more than teams expect. A proof of concept is a bounded piece of work with a defined output, which makes a fixed project fee the natural fit: you know the cost of the answer before you start, and the incentive sits on finishing, not on extending. This is how we run them. The later phases attract different models. Ongoing operation suits a managed monthly retainer, and cost optimization work suits a fee paid only on verified savings, but the proof of concept itself should be a fixed price question with a fixed date answer. Cloud consumption during the exercise is usually modest, and free credits can offset it, as long as the credits pay for the scope rather than define it.

Who staffs it

A decision grade proof of concept needs a small team with real authority. From your side: an application owner who knows the candidate workload, an infrastructure or platform engineer who will live with the result, someone from security and identity, and a sponsor senior enough to accept a negative finding. From the specialist side, you want people who have done this before, because the value of experience in a six week window is enormous. Our delivery teams bring 20+ years of combined Oracle infrastructure experience to engagements like this, and the practical effect is fewer weeks lost to problems someone has already solved elsewhere. The structure of that involvement is described in our OCI consulting service. What you should not do is staff the proof of concept entirely with external people. If your own engineers never touch it, the operational fit question goes unanswered, and that question is a third of the point.

A framework for scoping the proof of concept

Feeding the business case and the sizing

The proof of concept earns its keep when its numbers flow into the migration business case. The measured run rate for the candidate workload becomes the anchor for sizing the rest of the estate: if the workload needed half the compute the on premises footprint suggested, that ratio, applied carefully, reshapes the Universal Credits estimate for everything similar. The measured migration effort, hours spent, problems hit, change windows needed, calibrates the services cost for the full program. The operational findings either confirm the existing staffing plan or add a line for training and managed support. Every one of those numbers replaces an assumption, and assumptions are where migration budgets go to die. A business case built on a decision grade proof of concept routinely differs from the original estimate by 30% or more in one direction or the other, and finding that out before the commitment is the entire return on the exercise.

Converting the proof of concept into wave one

The final scoping decision is the one most teams skip: plan from the start for the proof of concept environment to survive. If you built it inside a slice of the real landing zone, with real identity, real network design, and real tagging, then the path from proof of concept to wave one is hardening and extension, not rebuild. The compartment structure stays. The federation stays. The connectivity, once reviewed, stays. The candidate workload, having already proven itself, often becomes the first production migration, which means wave one starts with momentum and a team that has already made its mistakes cheaply.

The alternative, tearing everything down and starting fresh, throws away the most valuable thing the proof of concept produced: a working, reviewed foundation. The only honest reason to rebuild is that the proof of concept taught you the design was wrong, and if so, it earned its fee right there. Either way, the exercise ends where it should: not with a demo, but with a decision, a number, and a head start.