The OCI Migration Assessment: A 40 Point Checklist

A migration assessment is not a formality before the real work starts. It is the cheapest point in the entire programme to find the problems that would otherwise surface as change requests, delays, and surprise invoices six months in. Across 500+ engagements we have seen the same pattern again and again: the migrations that land on time and on budget are the ones where the assessment was thorough, and the ones that overrun by half are the ones where it was skipped or rushed. The numbers behind that judgement, and the full economics of moving to OCI, are covered in our pillar guide to what an OCI migration really costs. This article is the practical companion: the checklist itself.

The forty points below are organized into themed sections, but they hang together as eight workstreams. If you remember nothing else, remember the frame.

Estate discovery and inventory

Everything downstream depends on the inventory being right. An estimate built on an incomplete inventory is not an estimate, it is a guess with a spreadsheet attached.

1. Build a complete server and VM inventory. Capture every physical host, virtual machine, and appliance in scope, including the forgotten boxes under someone's desk and the shadow IT instances in a departmental cloud account.
2. Capture real utilization, not nameplate capacity. Collect at least thirty days of CPU, memory, storage, and IOPS data per workload, because sizing to provisioned capacity instead of measured demand is the single largest source of cloud overspend.
3. Record operating systems, versions, and support status. Flag anything out of support or approaching end of life, because those workloads carry remediation cost that belongs in the migration budget, not in a later surprise.
4. Inventory storage by tier and growth rate. Separate hot data from archive, note replication and snapshot footprints, and capture the annual growth trend so the target estate is sized for year two, not just day one.
5. Identify workloads that should not move at all. Every estate contains servers that should be retired, consolidated, or replaced with SaaS rather than migrated, and removing them from scope is the first saving the assessment delivers.

Application and dependency mapping

Servers do not migrate, applications do. The dependency map is what turns a list of machines into a sequence of moves that will not break anything in transit.

6. Map every application to its infrastructure. Tie each business application to the servers, databases, storage, and middleware it runs on, so a move group is never split by accident.
7. Trace the dependencies between applications. Use network flow data, not tribal memory, to find the integrations, file transfers, and API calls that connect systems, because the undocumented ones are exactly the ones that cause outages.
8. Classify applications by criticality and tolerance for downtime. A tier one system with a near zero outage window needs a fundamentally different migration method, and budget, than a reporting tool that can be down for a weekend. The economics of that distinction are quantified in our guide to what migration downtime really costs.
9. Identify third party and vendor managed components. Anything supported by an external vendor needs that vendor's confirmation that the application is certified on OCI, and their change windows need to be in the plan.
10. Define the move groups and their sequence. Group tightly coupled systems so they migrate together, and sequence the groups so that early waves build confidence and the riskiest workloads move with the most experience behind them.

Database analysis

For most Oracle estates the databases are the centre of gravity of the whole migration, in effort, in risk, and in cost. They deserve their own workstream.

11. Catalogue every database with version, edition, and patch level. The migration path for a current Enterprise Edition database is very different from the path for an ancient release that needs an upgrade en route.
12. Measure database size and change rate. The volume of data and how fast it changes determine which migration methods are even feasible within the available outage window.
13. Audit the options and packs actually in use. Partitioning, compression, encryption, and the management packs each have licensing and target platform implications, and usage that nobody remembers enabling is a classic audit finding.
14. Match each database to a target service. Decide where each one lands: Base Database Service, Exadata Database Service, Autonomous Database, or a database running on plain compute, because the cost difference between those answers is large and permanent.
15. Define the data migration method and rehearsal plan. Choose between Data Guard, Data Pump, GoldenGate, RMAN, and the Zero Downtime Migration tooling per database, and budget for at least one full rehearsal of the largest and most critical moves.

Licensing position

Licensing is where OCI migrations are won or lost financially. Bring your own licence done well can cut the run rate dramatically; done badly it converts a saving into an audit exposure.

16. Establish a verified inventory of owned Oracle licences. Pull the actual contracts and ordering documents, not the spreadsheet someone maintains from memory, and confirm what is perpetual, what is term, and what the support status is.
17. Model licence included versus bring your own licence per workload. The right answer varies by database and by how the estate consolidates on the target, so run the comparison properly rather than applying one policy across the board.
18. Check the licensing of everything around the database. Middleware, Java, and analytics tools all carry their own entitlements and their own rules about cloud deployment, and they are routinely forgotten until an audit letter arrives.
19. Assess audit exposure before you signal a move. A migration is a known trigger for vendor attention, so the compliance position should be clean, or at least understood, before the project becomes visible. This is specialist territory, and it is the area where independent licensing advice pays for itself many times over.

Network and connectivity

Network design decisions are cheap to make on paper and expensive to change after workloads are live. Four checks settle most of it.

20. Select regions against latency, residency, and disaster recovery needs. Confirm the primary region meets data residency rules and user latency targets, and decide the second region for disaster recovery at the same time, not as an afterthought.
21. Design the connectivity model and order circuits early. Decide between FastConnect and VPN for each phase, and remember that dedicated circuits have lead times measured in weeks or months that can quietly become the critical path.
22. Measure the bandwidth the migration itself will need. Bulk data transfer during cutover windows is a different demand profile from steady state operations, and an undersized link turns a weekend cutover into a week.
23. Map every external integration endpoint. Partner connections, payment gateways, allowlisted IP ranges, and DNS dependencies all need to be reconfigured at cutover, and each one needs an owner and a test.

Security and compliance

Security requirements shape the landing zone, so they have to be gathered before the architecture is drawn, not retrofitted after.

24. Document the regulatory obligations in scope. Identify every framework that applies, from data protection law to industry rules, and translate each into concrete control requirements on the target platform.
25. Define the identity and access model. Decide how existing identity providers federate into OCI IAM, how compartments map to teams and environments, and who holds the keys to production.
26. Set the encryption and key management standard. Confirm requirements for encryption at rest and in transit, and decide early whether platform managed keys are acceptable or customer managed keys in a vault are mandated.
27. Plan logging, monitoring, and audit retention from day one. Define what gets logged, where it flows, and how long it is kept, because reconstructing an audit trail retroactively is somewhere between expensive and impossible.

Target architecture and sizing

This is where discovery turns into design, and where the difference between a sized estate and a copied estate shows up on every invoice for years.

28. Design the landing zone before the first workload moves. Compartment structure, network segmentation, tagging standards, and guardrail policies are the foundation, and getting them right first means every subsequent wave lands into order instead of improvisation.
29. Size compute to measured demand, then verify. Map workloads to OCI shapes using the utilization data from discovery, and validate the contentious cases with a test, not an argument. For workloads where the fit is genuinely uncertain, a structured pilot is the answer, and we cover how to run one in scoping an OCI proof of concept.
30. Right size with headroom policy, not anxiety. Agree a deliberate headroom percentage and an autoscaling posture, because unmanaged fear of undersizing is how a 40% saving becomes a 5% saving.
31. Decide what gets modernized in flight. For each workload, choose rehost, replatform, or rearchitect explicitly, because every quiet scope upgrade from rehost to rebuild adds cost that nobody approved.

The cost model

An assessment that does not end in a defensible number has not finished. The cost model needs to cover three distinct phases: the migration project, the steady state run rate, and the messy overlap in between.

32. Build the run rate from the sized estate, not the current one. Price the target architecture with realistic Universal Credits assumptions and committed use discounts, and state the assumptions so the number can be challenged honestly.
33. Budget the migration project itself, including rehearsals. Tooling, partner fees, internal time, test cycles, and rehearsal environments are all real costs, and the structure of a credible partner estimate is dissected in our guide to the anatomy of an OCI migration quote.
34. Model the parallel running period. For weeks or months you will pay for both the old environment and the new one, and a plan that pretends this overlap does not exist is understating the true cost of the move.
35. Set the baseline you will measure savings against. Record the current fully loaded cost now, because in two years the question will be whether the migration paid off, and without a baseline nobody can answer it. It is also how an optimization fee on verified savings gets verified.

Migration approach and tooling

36. Match the migration method to the workload, per workload. Lift and shift with OCI migration tooling, image export, database replication, or rebuild from automation each have their place, and one size fits all is a budget overrun in disguise.
37. Define cutover runbooks with rollback criteria. Every move group needs a step by step runbook, a go or no go checkpoint, and a tested rollback path, agreed before the night it is needed.
38. Plan testing as a first class workstream. Functional, performance, integration, and failover testing on the target environment consume a third or more of total migration effort, and the assessment should budget them that way.

The operating model after go live

39. Decide who runs the estate on day two. Internal team, managed service, or a hybrid: the answer determines training needs, hiring, and contract structure, and it should be settled before cutover, not after the migration team rolls off.
40. Schedule the first optimization review before the migration ends. Real usage data starts contradicting sizing assumptions within weeks of go live, and a review at the ninety day mark is where the projected savings either get banked or quietly evaporate.

How deep should the assessment go?

Not every estate needs the full treatment. The right depth depends on the size of the estate, the criticality of the workloads, and how much is already documented. We typically scope assessments at one of three tiers, each on a fixed project fee so the cost is known before work starts.

Whichever tier fits, the output should be the same in kind: a number you can defend, a sequence you can execute, and a list of risks with owners. Our consultants bring 20+ years of combined Oracle infrastructure experience to that work through our OCI consulting practice, and across our engagements the assessments that lead into a managed optimization programme average a 40% reduction in cloud spend against the original baseline. Some clients run the assessment as a standalone fixed fee project, others fold it into a managed monthly retainer that carries through migration and into operations; both work, as long as the assessment happens before the commitments are signed.

Using the checklist

Forty points looks like a lot until you compare it with the alternative. Each item on this list takes hours to check during an assessment and weeks to fix when it surfaces mid migration as a missed dependency, an unbudgeted licence, or an undersized circuit. Work through the sections in order, assign an owner to every point, and treat any item answered with a shrug as a risk, not a gap to paper over. The estates that arrive on OCI in good shape are not the ones with the simplest starting position; they are the ones that did this work first.