Workload Migration practice questions

OCI Archive Storage

Why it fails: Archive Storage is an object tier for rarely accessed long-term retention, offering no POSIX file semantics or concurrent multi-instance mounts. It is tempting because archive tiers suit large repositories kept for compliance, and that is the right answer when data is cold, immutable and retrieved only occasionally.

OCI Object Storage standard tier

Why it fails: Object Storage exposes an HTTP API rather than a POSIX file system, so NFS clients cannot mount it for shared concurrent access. It is tempting because Object Storage is the correct choice for storing large unstructured repositories accessed by applications through SDKs or REST, not by mounted file paths.

OCI Block Volume service

Why it fails: Block Volume attaches to a single instance at a time and is not a shared POSIX file system, so it cannot serve multiple instances across availability domains. It is tempting because Block Volume is the correct choice for high-performance single-instance database storage needing low latency and consistent IOPS.

Use OCI Local Peering Gateways (LPGs) to connect different Virtual Cloud Networks (VCNs) containing the tiers.

Why it fails: LPGs connect VCNs but do not guarantee physical proximity of the underlying host hardware.

Deploy the instances across different Availability Domains within the same OCI region.

Why it fails: Spreading instances across Availability Domains introduces inter-AD latency, which typically exceeds 1-2 milliseconds.

Utilize OCI Compute Placement Groups with a 'Spread' strategy.

Why it fails: A Spread placement strategy intentionally places instances on distinct hardware to maximize fault tolerance, which increases network latency.

VMware HCX OS conversion engine

Why it fails: VMware HCX converts workloads between VMware environments; it does not convert RHEL to Oracle Linux or confer Oracle Linux Premier Support entitlement. It is tempting because HCX handles large-scale migration and OS-level conversion between hypervisors, and would be right for moving VMs between vSphere and OCI without re-IP.

OCI Database Migration service

Why it fails: OCI Database Migration service moves Oracle databases, not operating systems, so it cannot convert RHEL instances or apply Oracle Linux entitlements. It is tempting because it is the OCI-native migration tool, and would be correct for migrating an on-premises Oracle database to Autonomous Database or Exadata.

OCI Instance Export/Import wizard

Why it fails: The Instance Export/Import wizard moves existing OCI compute instances between tenancies or regions; it performs no RHEL-to-Oracle-Linux conversion or entitlement change. It is tempting because it is a native OCI migration path for whole instances, and would be correct for relocating already-supported instances rather than converting their OS.

SQL Server Enterprise Edition requires an active Azure ExpressRoute connection to validate cluster heartbeat packets.

Why it fails: SQL Server clustering in OCI does not require Azure connectivity.

OCI Compute instances running Windows do not support Windows Server Failover Clustering (WSFC).

Why it fails: WSFC is fully supported on OCI Windows Compute instances.

OCI block volumes do not support Microsoft NTFS file systems, causing the database files to corrupt upon failover.

Why it fails: OCI block volumes fully support NTFS and Windows Server file systems.

Perform a direct binary block-level copy of the 11.2.0.4 datafiles to OCI and start the 19c instance using the old parameter file.

Why it fails: Binary block copying across major versions with different internal data dictionary structures will corrupt the database.

Migrate the database to an OCI Autonomous Database directly, as Autonomous Database automatically converts any legacy version and character set on the fly.

Why it fails: Autonomous Database has strict version and character set prerequisites and will reject incompatible source databases.

Use OCI GoldenGate to stream the 11.2.0.4 data directly into a 19c target database without any schema adjustments.

Why it fails: GoldenGate requires compatible database structures and data types; structural deprecations between 11g and 19c will cause replication failures.

OCI Standard Multi-Tenant Compute Instances with high-density shapes

Why it fails: Multi-tenant instances share underlying physical hardware hypervisors with other OCI customers.

OCI Burstable Instances

Why it fails: Burstable instances share CPU credits on shared physical hosts.

OCI Container Instances

Why it fails: Container instances run on shared serverless infrastructure managed by Oracle.

OCI Cost Estimator

Why it fails: Cost Estimator calculates prices based on user-entered shapes, not performance metrics discovery.

OCI Logging Analytics

Why it fails: Logging analytics searches and analyzes log files, not hypervisor hardware metrics and right-sizing.

OCI Database Migration Service

Why it fails: Database Migration is strictly for databases, not virtual machine infrastructure discovery.

Use OCI Flexible Load Balancers configured in Layer 2 bridging mode.

Why it fails: OCI Load Balancers operate at Layer 4 and Layer 7; they do not provide Layer 2 bridging.

Design the OCI VCN with disjoint RFC 1918 address space and use OCI NAT gateways to rewrite hardcoded IP addresses dynamically.

Why it fails: NAT gateways perform IP translation for outbound internet traffic; they do not rewrite internal application hardcoded IP addresses between tiers.

Deploy an OCI API Gateway in front of each virtual machine to proxy internal IP traffic.

Why it fails: API Gateway is for HTTP/REST APIs, not internal L3/L4 server-to-server IP addressing.

Automatically rewriting legacy COBOL source code into modern Python applications

Why it fails: Discovery and assessment inventory dependencies, performance baselines and readiness; they do not translate source languages, so no COBOL-to-Python conversion occurs. It is tempting because assessment output does inform refactoring decisions, and automated code conversion is the correct choice when the goal is application modernisation rather than migration planning.

Physically replacing hard drives in on-premises servers before shipping them

Why it fails: Discovery and assessment are read-only analysis activities; they never touch physical hardware, so drive replacement is outside their scope. It is tempting because decommissioning on-premises kit does follow a completed migration, and hardware refresh is the correct choice when the goal is extending the life of retained physical infrastructure rather than cloud migration.

Instantly upgrading on-premises cooling systems without cloud involvement

Why it fails: Assessment tools collect configuration, dependency and utilisation data; they have no control over facilities equipment such as cooling systems. It is tempting because data-centre consolidation often accompanies cloud migration, and cooling upgrades are the correct choice when the goal is improving the efficiency of retained on-premises capacity rather than migrating workloads.

Attaching a single Block Volume across two distinct OCI regions simultaneously over standard iSCSI

Why it fails: Block volumes are regional/availability domain constructs and cannot be attached across different OCI regions simultaneously.

Routing all regional traffic through a single legacy on-premises firewall in a third country

Why it fails: Routing cloud-to-cloud traffic back through on-premises creates a massive single point of failure and high latency.

Enable OCI Load Balancer TCP termination without backend health checks.

Why it fails: Load balancing operates at L4/L7 and does not provide layer 2 bridging or custom MAC support.

Rely on standard OCI Internet Gateways to bridge layer 2 broadcast domains across the public internet.

Why it fails: Internet Gateways route L3 IP packets; they do not bridge layer 2 broadcast domains.

Oracle Container Engine for Kubernetes (OKE), Autonomous Database, and OCI Object Storage

Why it fails: Object Storage does not expose an NFS file system natively for shared block storage, and containerizing a monolithic application is re-architecting, not lift-and-shift.

Oracle Zero Downtime Migration, OCI Exadata Database Service, and OCI Archive Storage

Why it fails: Archive Storage is strictly for long-term cold backup and is not suitable for active shared application file systems.

OCI Functions, MySQL HeatWave, and OCI Block Volume Service

Why it fails: OCI Functions is for serverless code and Block Volume cannot be concurrently shared across multiple VMs via NFS without a cluster file system.

Use Oracle Zero Downtime Migration to rewrite the kernel binary during the transition phase.

Why it fails: Zero Downtime Migration moves Oracle databases, not general-purpose VM images, and it does not rewrite guest kernel binaries. Unsupported kernels and partition layouts must be corrected on the source VMs before bulk instance migration, since the Image Builder cannot convert them directly.

Deploy OCI Full Stack Disaster Recovery to automatically fix and patch the kernel partitions upon boot.

Why it fails: Full Stack Disaster Recovery orchestrates failover and switchover of already-running OCI resources; it neither patches guest kernels nor repairs block partitioning during migration. The unsupported kernels and partition layouts must be remediated on the source VMs before the OCI Image Builder converts them.

Convert the instances directly into OKE worker nodes using the OCI Migration Workbench.

Why it fails: OKE worker nodes run containerised workloads, not converted VM images, and Migration Workbench does not transform arbitrary guest kernels into node pools. The remediation is to correct unsupported kernels and partitioning on the source VMs before image conversion, not to change the target platform.

Convert all block storage volumes directly into OCI Autonomous Database instances.

Why it fails: Block volumes contain file systems and OS partitions, which cannot be directly converted into a managed relational database service.

Disable TDE on the source database before migration.

Why it fails: Disabling TDE would decrypt the data, which is a security risk and may violate compliance. It also requires re-encryption after migration, adding complexity and downtime. TDE should remain enabled to protect data at rest throughout the migration.

Use Oracle Data Pump to export the data and import it into a new database without TDE.

Why it fails: Data Pump export/import would not preserve TDE encryption and would require decrypting data or re-encrypting after import. It also does not address the key management requirement. This approach would not ensure seamless TDE operation and could expose data.

Copy the on-premises Oracle Wallet file to the OCI database server.

Why it fails: OCI Base Database Service does not allow direct access to the underlying server file system. You cannot simply copy the wallet file. TDE key management must be integrated with OCI Vault, which is a managed service. Copying the wallet file is not supported and would not work.

Grant root access directly to the default 'opc' user across all on-premises enterprise Linux servers via group policy objects.

Why it fails: Blanket root for 'opc' violates least privilege and the stem's security constraint; the agent needs only sudo rights for specific discovery commands. It is tempting because elevated privileges do resolve SSH authentication failures, and central group policy makes mass grants appear manageable.

Disable password authentication globally on all target VMs and configure the OCI Migration appliance with the root password in plain text.

Why it fails: Storing a root password in plain text and disabling password authentication globally weakens security across every VM, contradicting the no-compromise requirement. A dedicated least-privilege service account with key-based SSH and sudo rights resolves collection while preserving authentication controls.

Switch the OCI Migration discovery mechanism from agent-based SSH to agentless SNMPv1 polling across the internal firewall.

Why it fails: SNMPv1 polling returns interface counters and device health, not the OS packages, services and filesystem data that migration assessment requires, and SNMPv1's cleartext community strings weaken security. It is tempting because agentless SNMP suits network device monitoring where SSH is unavailable.

Deploy new bare metal instances in OCI and use rsync to copy the root file systems over a secure IPsec VPN tunnel.

Why it fails: rsync copies files but cannot reproduce boot loaders, partition layouts, or kernel modules, so exact OS configuration and custom kernels are lost. It tempts because rsync is a familiar file-synchronisation tool, yet it suits data migration between running hosts, not whole-system image transfer.

Rebuild the application from scratch using Terraform and OCI Resource Manager, then redeploy application binaries.

Why it fails: Terraform rebuilds infrastructure declaratively but redeploys only application binaries, discarding the exact OS configuration, kernel modules, and security policies the stem requires. It tempts because Terraform and Resource Manager automate provisioning well, yet they suit greenfield or cloud-native rebuilds, not lift-and-shift of customised systems.

Export each virtual machine as a VMDK file, upload it to OCI Object Storage, and import it as a generic OCI custom image using the CLI.

Why it fails: VMDK import produces a generic OCI image, which strips VMware-specific drivers and does not preserve custom kernel modules or strict security policies without manual rebuilding. It tempts because VMDK export is the standard VMware portability format, but it suits simple guest conversions, not exact OS fidelity.

Use Oracle Database Actions to export all schemas to a local staging server and import them into the new database.

Why it fails: Database Actions export and import moves logical data through a staging server, which for 15 TB far exceeds two hours and adds a full intermediate copy. It is tempting because it is simple and needs no specialist tooling; it would be correct for small schemas where a logical refresh is acceptable.

Migrate the database using OCI Database Migration service with a standard full database backup without incremental backups.

Why it fails: A standard full backup without incremental backups means the entire 15 TB transfers during cutover, so the two-hour window cannot be met. It is tempting because OCI Database Migration automates the migration workflow; it would be correct when the final cutover window is long enough to move the full dataset.

Perform a cold backup on-premises, upload it to OCI Object Storage, and restore it using RMAN during the maintenance window.

Why it fails: A 15 TB cold backup upload and RMAN restore cannot complete inside a two-hour cutover, since the full data transfer and recovery dominate the window. It is tempting because cold backup plus RMAN is a reliable, well-understood migration path; it would suit migrations where the outage window is measured in days rather than hours.

OCI FastConnect with a dedicated 1 Gbps partner circuit.

Why it fails: FastConnect provides dedicated private connectivity but requires circuit provisioning lead time, and 1 Gbps still moves 80 TB in roughly a week, not the physical shipment timescale the scenario implies. It is tempting because dedicated bandwidth beats the congested internet link, and FastConnect would be correct for ongoing hybrid connectivity rather than one-off bulk migration.

OCI Storage Gateway deployed on an edge server compressing and streaming over the 50 Mbps line.

Why it fails: Compression cannot overcome the 50 Mbps ceiling for already-compressed backup data, and streaming through the gateway still takes months. It is tempting because a storage gateway caches and tiers data to object storage, and it would be correct for ongoing hybrid access to frequently used files rather than a one-off 80 TB migration.

Parallelized multi-part uploads using the OCI CLI over public internet connections.

Why it fails: Multi-part uploads still traverse the same 50 Mbps internet link, so the transfer duration is unchanged; parallelism only improves throughput utilisation, not available bandwidth. It is tempting because multi-part upload is the standard method for large objects, and it would be correct where bandwidth is adequate but single-stream throughput is the bottleneck.

OCI Functions

Why it fails: OCI Functions are designed for event-driven, serverless function code (Fn project/Knative), not general long-running web container applications.

Oracle Container Engine for Kubernetes (OKE)

Why it fails: While OKE runs containers, it introduces Kubernetes control plane and cluster management complexity, which contradicts the goal of avoiding server/cluster management for a single containerized app.

OCI Compute Standard virtual machine instances

Why it fails: Standard VMs require the user to manage the OS, kernel patches, and Docker daemon configuration.