Oracle to OCI migration checklist: 40 checks before, during and after cutover

A migration to Oracle Cloud Infrastructure does not fail on cutover day. It fails three weeks earlier, when nobody asked which integrations depend on a fixed IP, or when Data Pump was chosen for a 4 TB database with a six-hour window. This list gathers what we verify on every project, in the order it matters. Use it as a working script, not a formality.

Phase 0: before deciding

1. Define why you are migrating. Hardware end of life, cost, continuity, a vendor requirement. The reason sets the priorities: a cost-driven design is optimized differently from a continuity-driven one.

2. Define RTO and RPO with the business, per system. “Zero downtime” without budget for GoldenGate is not a requirement, it is a wish. Write them down and sign them.

3. Inventory everything that touches the database. Applications, interfaces, external jobs, reports, ETL, monitoring tools, backups, users with direct connections. 80 % of post-migration problems come from something that was not in the inventory.

4. Review licensing. Your on-premise Oracle licenses can be used on OCI (BYOL) and cut Base Database Service cost to a fraction. Verify edition, options (Partitioning, Diagnostics Pack, RAC) and processor count. OCI counts OCPUs, not physical cores.

5. Measure the real size. Data size (not datafile size: DBA_SEGMENTS), peak redo generation rate per hour (V$ARCHIVED_LOG), and actual internet bandwidth. Those three numbers decide the migration method.

Phase 1: target architecture

6. Design compartments by environment and sensitivity (production, non-production, shared network). IAM policies apply per compartment; a flat tenancy is impossible to audit.

7. Design the VCN with private subnets for database and applications, and a public subnet only for the load balancer and, if there is no alternative, the bastion. The database never gets a public IP.

8. Use OCI Bastion or a jump host instead of opening SSH/1521 to the internet, with security lists restricting the source.

9. Define hybrid connectivity. Site-to-Site VPN is enough for most; FastConnect when you need predictable latency or move tens of TB regularly. Test the VPN before the migration, not during it.

10. Pick the database service. Base Database Service (VM) for full control, Exadata Cloud for heavy workloads, Autonomous when the application tolerates it (no OS access, some features missing). For Forms/legacy ERP, Base DB on VM is the norm.

11. Size by real load, not by the current server. A 32-core on-premise server running at 20 % CPU does not need 32 OCPUs. Size from the last month of AWR and leave room to grow with one click.

12. Design high availability. Data Guard across availability domains (or regions) for production. Decide up front whether the standby will be active (Active Data Guard, licensed) or recovery-only.

13. Design backups. OCI automatic backup to Object Storage with a defined retention, plus an RMAN copy in Object Storage in another region if the disaster RPO requires it. Verify you can restore before signing off the design.

14. Define secrets management. Database passwords, wallets and keys in OCI Vault, not in configuration files.

15. Plan the application servers. WebLogic and Forms go on compute instances or OCI Marketplace images (license included or BYOL). Same network rule: private subnet, load balancer in front.

16. Design the OCI load balancer with your own SSL certificate and real health checks (an application URL, not just the port).

17. Budget with the OCI calculator and add Object Storage, internet egress and backups. Configure budgets and consumption alerts from day one.

Phase 2: migration method

18. Choose the method by size, window and source platform:

Method	When	Typical downtime
Data Pump (expdp/impdp)	Small to medium databases (< 500 GB), wide window, platform or version change	Hours
RMAN duplicate / restore	Same platform and endianness, medium to large database	Hours
Transportable Tablespaces	Endianness change (AIX → Linux) on large databases	Hours, less than Data Pump
Data Guard (physical standby on OCI)	Same platform, large database, short window	Minutes
GoldenGate	Platform or version change with minimal window, or phased migration	Minutes
Zero Downtime Migration (ZDM)	Orchestrates Data Guard or GoldenGate with Oracle’s automation	Minutes

19. If you migrate from IBM AIX or Solaris SPARC, remember endianness changes: direct RMAN restore and physical Data Guard do not work. It is Data Pump, Transportable Tablespaces with conversion, or GoldenGate.

20. Check version compatibility. If you go from 11g/12c to 19c in the same migration, decide whether to do it at source (upgrade first) or at target (import into 19c). Doing it at target is cleaner but requires testing the application against 19c beforehand.

21. Test real bandwidth by transferring a 50 GB file to Object Storage. Extrapolate. If it does not fit the window, use the OCI Data Transfer Appliance or GoldenGate.

22. Write the rollback plan. What happens if at 3:00 AM on cutover something misses the go criterion: return to source (which must be untouched), repoint DNS, communicate. With owners and timings.

Phase 3: rehearsal

23. Run a full test migration into the target environment, timed step by step. It is the only source of real timings for the cutover plan.

24. Validate the application at target with key users from every module: invoicing, inventory, accounting, reports. With written test cases and expected results.

25. Compare performance. AWR for a representative window at source versus the same scenario at target. If the target is slower, fix it before cutover: sizing, parameters, storage type (Block Volume performance tier).

26. Test integrations one by one: bank interfaces, tax authority e-invoicing, ERP, ETL, network printers, email. Each one has an IP, a certificate or a route that changes.

27. Test backup and restore at target. Restore to a point in time.

28. Test Data Guard failover if configured. Switchover there and back.

29. Adjust the cutover plan with real timings and repeat the rehearsal if anything relevant changed.

Phase 4: cutover

30. Freeze changes at source from a week before: no patches, no new objects, no configuration changes.

31. Communicate the window to the business with date, start time, estimated end time and the deadline for a rollback decision.

32. Lower the DNS TTL to 5 minutes at least 24 hours before, so the IP change propagates fast.

33. Printed checklist with checkboxes and an owner per step. Every step with a success criterion. Explicit go/no-go points.

34. Final backup of the source before starting, verified.

35. Stop the application at source, sync the last delta (last archive log, last GoldenGate trail, last incremental export depending on the method).

36. Validate at target before opening to users: invalid object count (DBA_OBJECTS with STATUS='INVALID'), sequences at the right value, scheduled jobs, users and grants, database links, external directories.

37. Repoint DNS and load balancers, open to a pilot group of users, then to everyone.

38. Do not shut down the source. Leave it intact, receiving no transactions, for at least a week.

Phase 5: stabilization

39. Intensive monitoring for the first week: alert log, waits, OCPU consumption, load balancer latency, daily cost. Fix whatever shows up.

40. Formal closure: final architecture document, OCI operations runbook, access inventory, backup and patch calendar, actual cost versus budget review. Only then is the source decommissioned.

---

This list comes from real migrations, including a retail company’s entire infrastructure moved to OCI, with databases, WebLogic and load balancers. If you are evaluating a migration, an architecture assessment gives you the method, a realistic window and the budget before you commit.