Top Oracle Migration Pitfalls Every DBA Must Avoid

1. Architecture‑level considerations

In many production environments the primary database participates in disaster‑recovery (DR), backup, BCV (Backup Copy Verification) and emergency‑response setups, and may act as source or target for other databases. When the database is part of such a topology, every dependent component must be taken into account during migration.

Example: a telecom operator upgraded a core database using Oracle GoldenGate. The environment included:

DR copy synchronized by Symantec (now Broadcom) underlying replication software;

BCV copy also synchronized by the same replication layer;

An emergency system fed by GoldenGate.

The migration plan upgraded the application tier first, then the primary system, followed by the DR and BCV copies, ensuring that each dependent system remained functional.

2. Resource‑impact risks

Migration activities should minimise load on the production environment. Common sources of overload are:

Export utilities (e.g., expdp/impdp) that consume CPU, memory, I/O and file‑system bandwidth on the source host.

Unsegregated network transfers (multiple concurrent FTP or SCP sessions) that saturate the LAN and affect application traffic.

Import into a target that shares storage with the live system; high‑concurrency impdp jobs can degrade the performance of the running database.

If the target is itself a production database, additional metrics must be watched continuously: CPU, PGA/SGA usage, archive‑log generation rate, tablespace free space, redo‑log size, and any custom alerts. Missing a single threshold can cause a cut‑over failure.

3. Application‑side pitfalls

Successful cut‑over requires coordination between the application owners and the DBA team. Typical incidents observed in practice:

Post‑cut‑over complaints of data mismatch because the legacy application was not fully stopped; early monitoring of source‑side activity caught the issue.

Incorrect modification of application configuration files, causing connections to the wrong database instance and delaying the schedule.

Insufficient functional or performance testing before the upgrade window, leading to unexpected errors during the migration.

4. Database‑specific problems to anticipate

Beyond architectural and resource concerns, the database itself can introduce failures. Project managers should track the following categories:

SQL performance regressions – version upgrades may change optimizer behavior; benchmark critical queries before and after the upgrade.

Object compilation or privilege errors – PL/SQL packages, views or synonyms that fail to compile become blockers during cut‑over.

Job‑scheduler anomalies – instance restarts can leave orphaned DBMS_SCHEDULER jobs that generate duplicate or “dirty” data.

Monitoring and backup gaps – existing RMAN or OEM monitoring may not automatically adapt to the new environment, leaving gaps.

Parameter mis‑configuration – memory, parallelism or redo‑log settings that were optimal for the old hardware may be unsuitable after migration.

Special object types – rarely used objects such as Oracle QUEUE tables may be migrated but not started, causing runtime errors in dependent applications.