OCI Migration Architect study materials
OCI Migration Architect study resources

OCI Migration Architect: Migration Architecture and Assessment

OCI Migration Architect · Work through your exam, one topic at a time.

All guide sections

Migration Architecture and Assessment

This domain tests how you turn a business case into a defensible OCI migration plan: inventory, dependency mapping, target architecture, wave sequencing, and risk. The exam expects you to choose a migration strategy per workload and justify it with evidence, not default to rehost.

Core rules

  • Start with discovery: collect server, database, network, storage, and application dependency data. OCI Cloud Migration Service discovery and assessment is the anchor; complement it with CMDB and flow data.
  • Classify each workload with the 6 Rs: retire, retain, rehost, replatform, refactor, repurchase. Record the rationale and target OCI service.
  • Map dependencies in both directions. A database shared by three applications changes the wave plan; so does a latency-sensitive chatty tier.
  • Build a landing zone before wave 1: compartments, identity, tagging, network baseline, logging, and cost controls.
  • Sequence waves by business value and risk: non-production first, then low-criticality production, then critical systems. Keep a rollback path per wave.

Worked example

A retailer has 120 VMs, 8 Oracle databases, and 15 integrations. Discovery shows 30 VMs belong to an order-management suite with one 4 TB Oracle database and a chatty middleware tier. The team proposes rehosting all 120 VMs in one wave. That is wrong: dependency mapping shows the suite must move as a unit, and the chatty tier needs latency testing before cutover. A better plan retires 10 idle VMs, rehosts 80, replatforms 20 to containers on OKE, and moves the order suite as a dedicated wave with a pilot and rollback. The reasoning is risk isolation and dependency integrity, not VM count.

Traps

  • Treating assessment as an inventory export; missing application-to-database and latency dependencies.
  • Assuming every workload is a rehost candidate; ignoring licensing and OS support on OCI.
  • Planning waves by department rather than by dependency boundary.
  • Skipping the landing zone, then discovering identity and network gaps during cutover.