Pre Migration Assessment Checklist for OCI

Most failed Oracle Cloud Infrastructure migrations were lost before a single workload moved. The team skipped the boring part, the assessment, and discovered halfway through cutover that a licence did not transfer, a dependency was undocumented, or the target shape was wrong. A disciplined pre migration assessment turns those surprises into line items you handle on your own schedule.

This checklist is the same structure we use on client engagements. It walks from raw discovery through to a formal go or no go gate, and it is deliberately exhaustive. You will not need every item on every project, but you should make a conscious decision to skip each one rather than miss it.

Why the assessment phase pays for itself

An assessment costs a fraction of a migration, yet it removes the two most expensive risks: rework and downtime. When you know exactly what you are moving, how big it is, what it depends on, and how it is licensed, you can sequence the work into safe waves and price the project with confidence. Teams that skip this step almost always pay later in extended cutover windows, emergency licensing purchases, or rolled back go lives.

The assessment also produces the artefacts the rest of the project relies on. Your dependency map feeds your wave plan. Your sizing data feeds your cost estimate. Your security findings feed your landing zone design. Nothing downstream is solid until the assessment is done.

The seven assessment domains

We group the checklist into seven domains. Each one has an owner, a deliverable, and a clear definition of done. Treat the table below as the master index for the rest of this article.

1. Discovery and inventory

You cannot migrate what you cannot see. Start by building a complete inventory of every server, virtual machine, database instance and application in scope. Capture operating system versions, database editions and patch levels, CPU and memory allocations, and current utilisation over at least a thirty day window. Peak utilisation matters more than average, because that is what your target shapes must absorb.

Pull data from your existing monitoring, your CMDB, and direct interrogation of the hosts. Expect the three sources to disagree. The reconciliation work is tedious but valuable, because every undocumented host you find now is one you will not trip over during cutover.

2. Application dependency mapping

Once you have the inventory, you need to understand how the pieces connect. Which application servers reach which databases, which batch jobs cross subnets, which integrations call external services. This is the single most under invested step in most migrations, and it is the one that breaks cutovers when skipped. We cover the technique in depth in our guide to application dependency mapping before OCI, but the principle is simple: capture real network flows, not the architecture diagram someone drew three years ago.

The output is a dependency graph that lets you cluster tightly coupled systems into move groups. Systems that chat constantly should move together to avoid latency across a hybrid link. The move groups then become the basis for your wave plan.

3. Sizing and shape selection

OCI shapes are flexible, which is a blessing and a trap. The blessing is that you can right size precisely. The trap is that teams copy their on premises core counts directly, ignoring that those counts were oversized years ago and never revisited. Use the utilisation data from discovery to size for real demand plus a sensible headroom, not for the legacy allocation.

Pay particular attention to storage performance. Many on premises systems run on aggressive flash arrays, and a like for like move to standard block volumes can disappoint. Map each workload to the right OCI storage tier and performance setting, and validate the IOPS and throughput assumptions before you commit.

4. Licensing and BYOL position

Licensing is where migrations quietly overspend. Oracle Database, middleware and applications all carry licence terms that interact with how you deploy on OCI. Bring Your Own Licence can dramatically reduce cost, but only if your entitlements are clean and your deployment respects the metric. Before you finalise any sizing, confirm exactly how each product will be licensed on the target and whether your current entitlements cover it.

This is specialist territory, and getting it wrong is expensive in both directions. Under licensing exposes you to compliance risk. Over provisioning licences wastes budget every year. We recommend a dedicated licence position review as part of the assessment, run with independent licensing expertise rather than left to assumption.

5. Networking and connectivity

Decide early how OCI will connect to your existing estate and to the public internet. Will you use FastConnect for a dedicated private link, or a site to site VPN for lower volumes? How will DNS resolve across the hybrid boundary during the transition? What is the latency budget for any traffic that must cross between on premises and OCI while both run in parallel?

Document the target virtual cloud network topology, subnet layout, route tables and security lists at assessment time. The cutover itself depends on this design being correct, and network mistakes are among the hardest to unwind once traffic is flowing.

6. Security and compliance mapping

List every control that applies to the in scope systems today, from encryption and access management to logging, retention and any regulatory obligations. Map each control to its OCI equivalent, whether that is a native service like Cloud Guard and Vault or a configuration you must build into the landing zone. Flag any control with no clean equivalent as a gap to resolve before go live.

For regulated estates this domain expands considerably, and you may need data residency, audit and segregation requirements baked into the architecture from day one. Build that into the assessment rather than retrofitting it under audit pressure.

7. The go or no go readiness gate

The assessment ends with a decision, not a document that sits on a shelf. Convene the stakeholders, walk the findings, and make an explicit call: proceed, proceed with conditions, or pause. The gate forces honesty about open risks and prevents the all too common pattern of drifting into a migration that the data never actually supported.

A useful gate uses a short scorecard. Each domain is rated red, amber or green, with a named owner for every amber and red item and a date by which it must clear. Only when the critical items are green do you commit to a cutover window.

Common pitfalls that derail an assessment

A few mistakes recur across engagements, and knowing them in advance is the cheapest insurance you can buy. The first is trusting the documentation. The architecture diagram, the CMDB and the licence spreadsheet are all snapshots of someone's understanding at a moment in the past, and reality has drifted. Validate everything against the live estate, because the gap between the documented system and the running one is exactly where cutovers fail.

The second pitfall is sizing from allocation rather than usage. A host provisioned with thirty two cores might peak at four. If you carry the allocation across to OCI you pay for capacity you will never touch, and you undermine the cost case before the project even starts. Always size from measured demand.

The third is treating licensing as a procurement formality to handle later. By the time you discover that a deployment choice doubles your licence requirement, you have already designed around it. Bring the licence question forward to the architecture stage, where it can still influence the design cheaply.

The fourth is a soft readiness gate, one where amber items are waved through because the schedule is tight. The whole point of the gate is to be the place where uncomfortable truths get aired. A gate that never says no is not a gate, it is a rubber stamp, and it leaves the real risks to surface during cutover instead.

Putting the checklist to work

Run the seven domains in order, because each feeds the next. Treat the deliverables as living artefacts that carry through the whole project. And resist the temptation to compress the assessment to save a week, because every week saved here tends to cost three during cutover. Once the assessment is complete and the gate is green, you are ready to sequence the work, which is the subject of our guide to planning an OCI migration wave, and to build the cost case described in OCI migration cost estimation. For the full picture, start from the complete guide to Oracle Cloud migration.