OCI Migration Architect Pro study materials
OCI Migration Architect Pro study resources

OCI Migration Architect Pro: Compute and Application Migration

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

All guide sections

Compute and Application Migration

What this domain tests

Shapes, images, and the mechanics of moving applications: agent-based replication with OCI Cloud Migrations, VMware workloads on Oracle Cloud VMware Solution (OCVS), containers to OKE, and how licensing affects the choice of target.

Core rules and concepts

  • Shapes: VM (flexible OCPU/memory), bare metal (dedicated, high core count), and GPU. Flexible shapes let you resize after migration, which changes sizing philosophy - start at observed peak, adjust post-go-live.
  • OCI Cloud Migrations migration works by installing a replication agent on the source, replicating disks to OCI, launching test instances, validating, then cutting over. Test cutover runs without touching the production source.
  • OCVS runs vSphere on bare metal in your VCN; migrate VMs with HCX or compatible tooling and keep existing vSphere skills and tooling.
  • Containerized applications should be rebuilt as images and run on OKE with OCIR as the registry - not lifted as VMs.
  • Image import accepts common formats (QCOW2, VMDK, OCI-native); custom images carry boot volume size constraints.
  • Licensing: BYOL for Oracle Database and Windows; Oracle Linux/UEK; confirm the target shape supports the licence model, including constrained-core options.

Worked example

200 RHEL VMs, 4-hour RTO, strict change control. Use OCI Cloud Migrations replication: deploy agents, seed data over two weeks with no production outage, run a test cutover into a sandbox compartment to validate boot, drivers, and application smoke tests, then schedule the real cutover inside a 4-hour window with a DNS switch. Keep the database on Exadata Database Service rather than on a replicated VM, because licensing and RTO are both better served there.

Traps that cost marks

  • Believing the full seeding period requires production downtime; it does not.
  • Forgetting OS-level customization: fstab entries, network configs, licence servers, hard-coded IPs.
  • Migrating VMs with local state (sessions, licence files) without externalizing it first.
  • Skipping test cutover; the exam rewards validated migrations over optimistic ones.