OCI Migration Architect common mistakes
OCI Migration Architect · Understand the traps and how to avoid them.
When sizing a source workload, the candidate treats the CPU and memory figures shown in a hypervisor or OS tool as the whole story and proposes an OCI shape of the same vCPU/RAM count, without reconciling core-to-OCPU ratios, hyperthreading, or the fact that OCI bills per OCPU (one physical core = 2 vCPUs on x86).
Candidates carry over on-prem habits where vCPU counts already include hyperthreads, and they assume a 1:1 mapping to OCI shapes. OCI Flex shapes are quoted in OCPUs, so a 16-vCPU source maps to roughly 8 OCPUs, and an uncorrected comparison either overbuilds cost or underbuilds performance.
What to do instead
Build a sizing worksheet that records per-host physical cores, threads, peak and p95 utilization, and memory working set, then convert to OCPUs explicitly (x86: 2 vCPU = 1 OCPU; Ampere A1: 1 core = 1 OCPU). Validate the resulting shape with a short performance baseline or OCI Compute performance metrics before committing to the design.
The candidate presents a migration plan that lists target services and a timeline but contains no dependency map, no application-to-server inventory with criticality tiers, and no defined migration waves, so unrelated workloads are scheduled to move together.
Assessment questions reward visible artifacts, and candidates under time pressure write a narrative plan. They also underestimate how many hidden dependencies (DNS entries, hard-coded IPs, shared file shares, batch schedulers, AD trusts) exist until they are discovered mid-cutover.
What to do instead
Produce a discovery-driven dependency map (network flow data, DNS logs, config file scans) and group applications into waves by shared dependency clusters and business criticality. State the wave sequence, the entry/exit criteria per wave, and which workloads are candidates for rehost vs replatform vs retire.
When asked to design the landing zone network, the candidate assigns a single flat VCN CIDR and puts every workload in one regional subnet, ignoring that OCI subnets are regional and that a /16 VCN with /24 subnets leaves no room for on-prem overlap or future peering.
Candidates map on-prem VLAN thinking onto OCI and do not plan the IP address space against existing RFC1918 ranges on-prem. They also forget that VCN CIDRs cannot be shrunk later and that overlapping ranges block IPSec, FastConnect, and DR peering.
What to do instead
Design a hierarchical, summarized address plan (for example a /16 per environment with /20 or /24 subnets per tier and per AD where relevant), reserve non-overlapping ranges for on-prem and DR, and document the DRG, route table, and security list/NSG layout per tier. Explicitly call out which CIDRs are advertised over FastConnect and how summarization keeps route tables small.
The candidate designs hybrid connectivity with a single FastConnect virtual circuit and no IPSec VPN backup, and does not state how route preference, BGP ASN, or DRG route tables handle failover.
FastConnect is the headline OCI hybrid product, so candidates stop there. They overlook that a single circuit and a single cross-connect group is a single point of failure, and they have not thought through how the DRG chooses between a FastConnect virtual circuit and a site-to-site VPN when both advertise the same prefixes.
What to do instead
Specify redundant FastConnect (two virtual circuits in different cross-connect groups or locations, or FastConnect plus a site-to-site VPN over the internet as backup), define BGP ASN values and AS-path prepending for preference, and describe DRG route table behavior and failover testing. State the expected failover time and how it is validated.
The candidate proposes moving an Oracle Database to OCI by treating it like any other VM: lift the database files onto a Compute instance with block volumes and call it done, without evaluating Autonomous Database, Base Database Service, Exadata Database Service, or the appropriate migration tool.
Candidates default to rehost because it feels safe, and they are unsure which managed database service fits which workload. They also skip the version, edition, and feature compatibility check (for example whether the workload depends on features not available in a given service) that determines feasibility.
What to do instead
Map each database to a target service using workload characteristics (OLTP vs analytics, isolation and compliance needs, licensing, RAC requirements, version), then name the migration method per target: Data Pump for logical moves, RMAN backup/restore or Data Guard for physical moves, Zero Downtime Migration for supported paths, and GoldenGate for cross-database or minimal-downtime replication. Justify the choice against the alternatives.
The candidate plans an application migration but never addresses the application's dependencies on directory services, DNS, NTP, certificate authorities, SMTP relays, or legacy protocols that the OCI network and security posture will block.
These services are invisible in the application inventory and only surface as failures after cutover. Candidates also assume the on-prem security stack (inspection appliances, proxy, DLP) will somehow be present in OCI, then discover that egress rules and NSGs break the traffic.
What to do instead
Add an explicit shared-services section covering DNS resolution and forwarding, AD/LDAP integration, NTP sources, PKI, and egress paths, and state how each is provided in OCI (for example a hub VCN with shared services, DNS resolver endpoints, and NAT or a firewall appliance). Confirm each dependency with the application owner and test it in the pilot wave.
The candidate writes a cutover plan that is a list of tasks with a start time but no rollback trigger, no rollback time budget, and no defined decision point at which the team reverts.
Cutover questions invite a happy-path runbook, and candidates focus on making the migration succeed rather than on failing safely. They also do not know how long a rollback realistically takes, so they cannot state a credible revert window.
What to do instead
Define explicit go/no-go checkpoints with measurable criteria, a named decision owner, and a rollback procedure with its own tested duration (for example database restore time plus DNS TTL plus application validation). Include the pre-cutover freeze, the DNS TTL reduction ahead of time, and the communication plan for each outcome.
The candidate relies on DNS changes alone to move traffic to OCI and does not account for TTL, client-side caching, hard-coded IPs, or long-lived connections, so the cutover appears complete while a portion of traffic still hits the source.
DNS cutover looks simple and is the most familiar mechanism. Candidates forget that TTL must be lowered well in advance, that some clients ignore TTL, and that established TCP sessions and connection pools do not re-resolve, which produces partial cutovers that are hard to diagnose.
What to do instead
Lower TTLs at least one TTL period before cutover, drain or restart connection pools, and plan for a dual-running period with traffic verification (flow logs, load balancer metrics, application logs) confirming the source receives no traffic. For IP-bound clients, plan an address translation or proxy layer rather than assuming DNS solves it.
The candidate designs monitoring for the migrated estate by listing OCI Monitoring alarms on CPU and availability only, omitting the workload-level signals, log aggregation, and the operational ownership model that the migration team is handing over.
Candidates treat observability as an afterthought and reuse generic infrastructure metrics. They also do not address the gap between the migration team's temporary access and the steady-state operating model, so nobody owns the alarms after handover.
What to do instead
Define a monitoring and operations section covering OCI Monitoring metrics and alarms per tier, Logging and Logging Analytics for application and audit logs, Notifications topics and on-call routing, plus the runbooks and ownership handover. Tie thresholds to the same baselines used in sizing and state how alerts are tested before go-live.
The candidate recommends lift-and-shift for every workload in the estate and never performs a disposition analysis, so workloads that should be retired, replaced with SaaS, or replatformed to managed services are all scheduled for rehost.
Rehost minimizes perceived risk and is easy to defend, and candidates are reluctant to recommend retiring systems without evidence. They also lack a framework for comparing migration strategies, so they collapse to one answer instead of segmenting the portfolio.
What to do instead
Apply a disposition framework (retire, retain, rehost, replatform, refactor, repurchase) to the inventory and justify each assignment with cost, business value, technical debt, and timeline. Show the resulting wave plan reflects the mix, and quantify where replatforming to managed services reduces operational burden enough to justify the extra effort.