OCI Migration Architect Pro cheat sheet

OCI migration phases: Assess, Plan, Design, Migrate, Validate, Operate. Each phase produces artifacts that feed the next; skipping assessment increases cutover risk.

Assessment inputs: application inventory, dependency mapping, utilization baselines (CPU, memory, IOPS, throughput), licensing (BYOL vs. included), compliance constraints, and RTO/RPO per workload.

7 Rs framework: Retire, Retain, Rehost, Replatform, Repurchase, Refactor, Relocate. OCI migration typically favors Rehost (lift-and-shift to Compute) and Replatform (to Autonomous Database or OKE).

TCO comparison must include compute shape cost, storage tier, data transfer egress, licensing (BYOL vs. license-included), support level, and operational overhead - not just VM price.

Migration waves group applications by dependency, business criticality, and cutover window. Wave 0 is typically non-production or low-risk stateless workloads.

OCI Cloud Adoption Framework (CAF) pillars: architecture, security, operations, cost, people, and governance. Use CAF to structure the migration plan and landing zone design.

Application dependency mapping identifies north-south (user traffic) and east-west (service-to-service) flows; missed east-west dependencies are a leading cause of failed cutovers.

RTO/RPO drive replication choice: RPO near zero requires synchronous replication or continuous data guard; RTO in minutes requires pre-provisioned standby or automated failover.

Migration plan must include rollback criteria, communication plan, and a validation checklist per workload; rollback is a pre-approved decision, not an improvisation.

OCI landing zone hierarchy: Tenancy → Compartments → Resources. Compartments are the primary policy and cost boundary; design them by environment, business unit, or workload tier.

IAM policy syntax: Allow to in where . Policies are additive; there is no deny rule in OCI IAM.

Dynamic groups match compute instances by rule (e.g., instance.compartment.id = 'ocid1.compartment...'), enabling instance principals without stored credentials.

Federation: OCI IAM supports SAML 2.0 and SCIM for identity synchronization; map IdP groups to OCI groups to avoid per-user policy sprawl.

Cost governance: budgets and budget alerts per compartment; cost-tracking tags applied at resource creation; tag defaults enforce consistent tagging.

Security zones (Cloud Guard) detect and optionally deny public buckets, unencrypted volumes, and open security lists; enable at tenancy or compartment level.

Network landing zone: hub-and-spoke with a central VCN for shared services (DNS, bastion, inspection) and peered or DRG-attached spoke VCNs per workload.

Governance artifacts: compartment quotas to cap spend, service limits review before migration, and audit log retention for compliance evidence.

Compute shapes for migration: VM (flexible OCPU/memory), BM (dedicated), and GPU. Flexible shapes allow right-sizing during migration rather than after.

OS migration: OCI supports Oracle Linux, RHEL, Ubuntu, Windows Server, and others. Bring-your-own-image via custom image import (QCOW2, VMDK, OVA).

Rehost path: export VM from source (OVF/VMDK), import as custom image, launch instance in target compartment, reattach data, validate boot and network.

Replatform path: containerize to OKE (Kubernetes) or migrate to OCI Functions for event-driven components; validate image registry (OCIR) and network policies.

Instance metadata and user data (cloud-init) automate post-boot configuration; use for hostname, agents, and app bootstrap to reduce manual steps.

Oracle Cloud Agent plugins (monitoring, management, vulnerability scanning, OS management) should be enabled on migrated instances for post-migration operations.

Autoscaling and instance pools: define pool by shape and image, attach load balancer, set scaling policy based on CPU or schedule.

Application migration validation: health checks, session persistence, DNS resolution, latency to dependencies, and license compliance on the new shape.

Target selection: Autonomous Database (ATP/ADW) for OLTP/analytics with auto-scaling and patching; Base Database (VM/BM) for full control; Exadata for high-performance consolidated workloads.

Migration methods: Data Pump (expdp/impdp) for logical, RMAN for physical, GoldenGate for near-zero downtime, and Zero Downtime Migration (ZDM) for automated orchestration.

Autonomous Database connectivity requires a wallet (mTLS) or TLS; configure network access control lists and private endpoints for security.

Character set and national character set must be compatible between source and target; verify before Data Pump export to avoid data loss.

GoldenGate requires supplemental logging on source tables and a compatible extract/replicat version; use for cross-version and cross-platform replication.

ZDM supports online and offline modes; online uses Data Guard or GoldenGate to minimize downtime, offline uses backup/restore for acceptable downtime windows.

Exadata migration: use Data Guard for physical standby, or XTTS (transportable tablespaces) for cross-endian platforms; validate storage cell and ASM configuration.

Post-migration database validation: row counts, checksums, optimizer statistics, execution plans for critical queries, and application connection string updates.

Block Volume: network-attached, persistent; performance tiers (Lower Cost, Balanced, Higher Performance, Ultra High Performance) set VPUs per GB.

Object Storage: buckets with standard, infrequent access, and archive tiers; use for backups, unstructured data, and Data Transfer Service targets.

File Storage: NFSv3 file systems for shared workloads; mount targets in a VCN subnet with export options per client CIDR.

Data Transfer Service: physical appliance for large datasets (TB–PB); order device, load on-prem, ship to OCI, data ingested to Object Storage.

Storage Gateway: hybrid - presents on-prem NFS/SMB/iSCSI backed by Object Storage; useful for incremental migration of file data.

RMAN backup to Object Storage: configure DBMS_CLOUD or RMAN SBT channel; enables restore-based migration without physical media.

Data transfer sizing: estimate bandwidth × time; for TB-scale over WAN, compare Data Transfer Service vs. network transfer cost and duration.

Encryption: all OCI storage encrypted at rest by default (Oracle-managed keys); customer-managed keys via Vault for compliance requirements.

VCN design: CIDR must not overlap with on-prem or peered networks; plan subnets by tier (web, app, data) and availability domain.

Connectivity options: FastConnect (dedicated/private, predictable latency), Site-to-Site VPN (IPSec over internet), and public internet with TLS.

DRG (Dynamic Routing Gateway) attaches VCNs to on-prem via FastConnect or VPN; use DRG v2 for transit routing between VCNs and on-prem.

Security lists are subnet-level; NSGs are VNIC-level. Prefer NSGs for granular east-west control; security lists for coarse subnet boundaries.

Private endpoints: use service gateway for Object Storage access without internet; private endpoint for Autonomous Database and other managed services.

DNS: configure private DNS zones in VCN resolver; update application connection strings to new endpoints during cutover.

Load balancing: public/private load balancers and network load balancers; configure health checks and session persistence matching source behavior.

Latency and throughput validation: test with representative traffic before cutover; FastConnect latency is typically sub-10ms within region.

Cutover runbook: pre-cutover checks, freeze window, DNS/connection switch, smoke tests, rollback trigger, and post-cutover monitoring - each with owner and timestamp.

DNS cutover: lower TTL 24–48 hours before cutover; keep old environment running until TTL expires and validation passes.

Validation checklist: application login, critical transactions, batch jobs, integrations, performance baseline comparison, and data integrity checks.

Rollback plan: define maximum tolerable downtime and data loss; for databases, keep source in read-only or standby mode until validation completes.

Post-migration operations: enable monitoring (OCI Monitoring, Logging), set alarms on key metrics, configure backups and patching schedules.

Cost review after migration: compare actual spend to TCO model; right-size shapes and storage tiers based on observed utilization.

Security posture: run Cloud Guard and vulnerability scanning; review IAM policies and remove migration-era broad permissions.

Decommission source only after a defined stabilization period (e.g., 30 days) and formal sign-off from application owners.