OCI Migration Architect Pro common mistakes
OCI Migration Architect Pro · Understand the traps and how to avoid them.
Treating the migration as a lift-and-shift project plan and selecting the migration approach (rehost, replatform, refactor, repurchase) only after the technical design is fixed, rather than using the assessment findings to drive the approach per workload.
Candidates carry over on-premises habits where the target is a single data center and the 'how' is assumed; they skim the business and technical assessment outputs and jump straight to compute sizing, so they never map application criticality, dependencies, and cloud-fit ratings to a 6R decision.
What to do instead
Practice producing a per-application disposition table: capture business value, technical fit, dependencies, and data gravity, then assign a 6R treatment and a wave. In scenario questions, first ask 'what does the assessment say about this app's fit?' before choosing a migration method; if the stem gives no fit data, the correct answer often is 'run an assessment/discovery first'.
Building a migration wave plan around application count or team preference instead of dependency order, shared infrastructure, and cutover risk, and omitting a pilot wave.
Wave planning looks like scheduling; candidates underestimate how tightly coupled apps (shared DBs, AD/LDAP, file shares, middleware) force sequencing, and they forget that a pilot wave is how you validate runbooks and the landing zone before scale.
What to do instead
Memorize the wave-planning logic: pilot first (low-risk, representative), then waves grouped by dependency cluster, then the complex/large workloads. When a question describes an app with many inbound dependencies, the answer is usually to migrate it late or after its dependencies. Rehearse identifying 'what must move together' from a described dependency list.
Designing the landing zone as a flat tenancy with a single compartment and permissive IAM policies, then trying to retrofit isolation, budgets, and guardrails during migration.
Candidates focus on the workload and treat tenancy structure as an afterthought; they also under-use compartments, tags, and policy inheritance because on-premises AD/OU structures feel sufficient.
What to do instead
Learn the reference pattern: compartments by environment and workload (or business unit), IAM groups mapped to roles with least privilege, defined tags for cost and ownership, budgets and quota policies at the compartment level, and Cloud Guard/Security Zones for guardrails. On scenario questions, reject any design that puts prod and non-prod in one compartment or grants broad tenancy-level admin.
Assuming on-premises identity (Active Directory) maps directly to OCI IAM and forgetting federation and the distinction between workforce (console/API) identity and workload/instance identity.
Candidates conflate authentication with authorization and do not separate human SSO from machine credentials; they also miss that OCI IAM policies are written against groups and compartments, not users, and that federation via identity provider does not by itself grant OCI permissions.
What to do instead
Study the two-layer model: federate users through an identity provider into OCI IAM, then map IdP groups to OCI IAM groups and write policies on those groups. Separately cover instance principals and dynamic groups for workloads. In questions, treat 'federated the users' as only half the answer and look for the group-to-policy mapping.
Sizing compute by copying on-premises vCPU and RAM 1:1 without accounting for OCPU definition, burstable vs flexible shapes, and the performance profile of the workload.
Candidates assume vCPU equals OCPU and ignore that OCI OCPU maps to a physical core with hyperthreading, and that flexible shapes let you set OCPUs and memory independently; they also ignore whether the app is CPU-bound, memory-bound, or latency-sensitive.
What to do instead
Internalize that 1 OCPU = 1 physical core = 2 vCPUs on x86, and that AMD/Intel flexible shapes allow independent CPU and memory selection. Practice right-sizing from utilization data (peak vs average) and picking shapes by workload profile: burstable for spiky low-average, flexible for steady, dense/GPU for specialized. Always ask whether the stem provides utilization numbers and use them.
Choosing a database migration method (Data Pump, GoldenGate, Zero Downtime Migration, logical vs physical) without checking version, edition, character set, and downtime tolerance, and assuming any method works for any source.
Candidates memorize tool names but not their preconditions: ZDM supports specific source/target combinations, GoldenGate needs supplemental logging and supports near-zero downtime, Data Pump is logical and version-sensitive, and cross-platform transportable tablespaces have endianness constraints. They also forget Autonomous Database restrictions on things like certain privileges and directory objects.
What to do instead
Build a decision table keyed on downtime tolerance, data volume, version, and target (ADB vs Base DB vs Exadata). Map: minimal downtime and heterogeneous or cross-version to GoldenGate; offline bulk to Data Pump or RMAN/transportable tablespaces; automated end-to-end to ZDM. For Autonomous Database, flag unsupported features (e.g., certain system privileges, OS access) and plan remediation before cutover.
Planning data transfer by assuming the network link will carry the volume in time, without calculating throughput from bandwidth, latency, and TCP window effects, and without comparing physical transfer appliance or object storage transfer options.
Candidates multiply bandwidth by time and ignore latency and packet loss, which dominate long-haul transfers; they also default to one method (often rsync or a VPN) without considering Data Transfer Service, FastConnect, or offline appliance for very large datasets.
What to do instead
Practice the throughput math: effective throughput is limited by window size and round-trip time, so high bandwidth with high latency still yields low per-stream throughput; parallelization and multiple streams help. Then choose: online over FastConnect/VPN for incremental and moderate volumes, Data Transfer Service or physical appliance for large one-time seeds, and replication for ongoing sync. In questions, compute whether the link can finish inside the window before selecting it.
Designing connectivity as a single VPN or a single FastConnect circuit with no redundancy, no route design (DRG, VCN peering, transit), and no separation of management, data, and replication traffic.
Candidates treat connectivity as a checkbox and forget that migration traffic (bulk data, replication) competes with production and management traffic, and that a single circuit or tunnel is a single point of failure for cutover.
What to do instead
Learn the topology building blocks: DRG for on-premises and cross-VCN transit, VCN peering (local and remote), FastConnect with redundant virtual circuits or FastConnect plus VPN backup, and route tables and security lists/NSGs that isolate traffic classes. On scenario questions, look for the design that has redundant paths and separate route domains for replication vs user traffic, and reject single-path answers for production cutover.
Treating cutover as a single switchover event with no rehearsal, no rollback plan, and no defined validation criteria or acceptance gates.
Candidates focus on getting workloads running in OCI and treat the cutover as the finish line; they skip the runbook rehearsal, the DNS/TTL and connection-string changes, the freeze window, and the explicit go/no-go criteria, so they cannot answer questions about minimizing downtime or proving success.
What to do instead
Memorize the cutover sequence: pre-cutover validation in a test environment, freeze and final delta sync, DNS/connection switch with low TTL prepared in advance, smoke tests against acceptance criteria, and a documented rollback trigger and procedure. Practice questions that ask 'what should happen first' or 'what proves the migration succeeded' and prefer answers that reference rehearsed runbooks and measurable validation over 'monitor after cutover'.
Declaring the migration complete at cutover and neglecting post-migration operations: cost monitoring, right-sizing, backup and DR validation, observability, and decommissioning of the source.
Candidates equate 'running in OCI' with 'migrated' and do not plan for the operational steady state, so they miss questions on FinOps, backup policy verification, DR drills, log/metric/alarm setup, and secure source decommissioning and data destruction.
What to do instead
Study the post-migration checklist: verify backup policies and test restore, confirm DR runbooks and failover drills, enable monitoring/logging/alarms and set budgets with alerts, right-size after a measurement period, and decommission source systems with data sanitization and access revocation. When a question asks what to do after cutover, prefer answers that validate recoverability and cost, not just 'turn off the old system'.