Cross-Platform/Cloud Migration, GoldenGate Awareness, Cutover Rehearsal, and Post-Migration Verification

Learning outcomes

A migration team proves that the target cloud database accepts connections and declares success. After cutover, inserts fail because a sequence is behind the imported table, one grant is missing, and the chosen physical copy method was invalid across endian formats. A real migration is a controlled change of data ownership, replication/final sync, service routing and rollback authority—not a connectivity test.

1. Start with platform and endian evidence

SELECT platform_nameFROM v$database;SELECT platform_id,platform_name,endian_formatFROM v$transportable_platformORDER BY platform_name;SELECT parameter,valueFROM nls_database_parametersWHERE parameter IN (  'NLS_CHARACTERSET',  'NLS_NCHAR_CHARACTERSET')ORDER BY parameter;SELECT * FROM v$timezone_file;

Platform and endian format constrain physical methods. Character sets/time-zone versions constrain logical/application correctness. Capture both on source and target before choosing the migration mechanism.

2. Physical/logical method matrix

RMAN CONVERT DATABASE requires same-endian source/target platforms. Different endian full moves normally use logical/transportable approaches with conversion rather than a blind whole-database convert.

3. GoldenGate is CDC/replication, not a free migration switch

Oracle GoldenGate Extract captures committed changes (typically from redo) and Replicat applies them to the target. Initial load plus ongoing change capture can reduce final outage to the time needed to freeze writes, drain lag, verify and redirect traffic. Logical replication requires enough redo/supplemental identity to reconstruct changes safely.

SHOW PARAMETER enable_goldengate_replicationSELECT  supplemental_log_data_min,  supplemental_log_data_pk,  supplemental_log_data_ui,  force_loggingFROM v$database;

4. Low downtime still has a final ownership transfer

Even with CDC, establish a moment when the source stops accepting new authoritative writes. Then drain/apply final changes, prove zero acceptable lag, validate data/application state, switch services/DNS/pools, and decide whether to commit the migration or route back.

1. Initial copy.
2. Continuous delta synchronization.
3. Repeated rehearsal and lag measurement.
4. Final source write freeze/drain.
5. Apply last delta; verify.
6. Switch service/DNS/config and recycle/drain pools.
7. Run target smoke/critical transactions.
8. Commit or rollback within the agreed window.

5. Free local cutover simulation

BEGIN EXECUTE IMMEDIATE 'DROP TABLE sh28_cut_target PURGE';EXCEPTION WHEN OTHERS THEN IF SQLCODE != -942 THEN RAISE; END IF; END;/BEGIN EXECUTE IMMEDIATE 'DROP TABLE sh28_cut_source PURGE';EXCEPTION WHEN OTHERS THEN IF SQLCODE != -942 THEN RAISE; END IF; END;/BEGIN EXECUTE IMMEDIATE 'DROP SEQUENCE sh28_cut_target_seq';EXCEPTION WHEN OTHERS THEN IF SQLCODE != -2289 THEN RAISE; END IF; END;/CREATE TABLE sh28_cut_source (  work_order_id NUMBER PRIMARY KEY,  status_code VARCHAR2(12) NOT NULL,  amount NUMBER(12,2) NOT NULL);CREATE TABLE sh28_cut_target (  work_order_id NUMBER PRIMARY KEY,  status_code VARCHAR2(12) NOT NULL,  amount NUMBER(12,2) NOT NULL);INSERT INTO sh28_cut_source VALUES(98,'OPEN',10);INSERT INTO sh28_cut_source VALUES(99,'OPEN',20);INSERT INTO sh28_cut_source VALUES(100,'CLOSED',30);INSERT INTO sh28_cut_targetSELECT * FROM sh28_cut_source;CREATE SEQUENCE sh28_cut_target_seqSTART WITH 100 INCREMENT BY 1 CACHE 20;COMMIT;

The two tables live in one PDB; this is a state-machine/correctness simulation, not real cross-platform replication.

6. Simulate a final source delta and synchronize

UPDATE sh28_cut_sourceSET amount=25WHERE work_order_id=99;INSERT INTO sh28_cut_sourceVALUES(101,'OPEN',40);COMMIT;

MERGE INTO sh28_cut_target tUSING sh28_cut_source sON (t.work_order_id=s.work_order_id)WHEN MATCHED THEN UPDATE SET  t.status_code=s.status_code,  t.amount=s.amountWHEN NOT MATCHED THEN INSERT(  work_order_id,status_code,amount) VALUES(  s.work_order_id,s.status_code,s.amount);COMMIT;

A real GoldenGate/Data Pump/RMAN migration uses its own delta/apply mechanics; this MERGE simply makes the final-sync concept observable on Free.

7. Prove row equivalence in both directions

SELECT * FROM sh28_cut_sourceMINUSSELECT * FROM sh28_cut_target;SELECT * FROM sh28_cut_targetMINUSSELECT * FROM sh28_cut_source;

SELECT 'SOURCE' side,       COUNT(*) rows_count,       SUM(amount) total_amount,       MIN(work_order_id) min_id,       MAX(work_order_id) max_idFROM sh28_cut_sourceUNION ALLSELECT 'TARGET',       COUNT(*),       SUM(amount),       MIN(work_order_id),       MAX(work_order_id)FROM sh28_cut_target;

Both MINUS queries should return zero rows and aggregate values should match. For large production datasets, use partition/table-level checksums, row counts, business aggregates and targeted row sampling instead of one giant MINUS.

8. Deliberate migration failure: target sequence is behind data

INSERT INTO sh28_cut_target(  work_order_id,status_code,amount) VALUES(  sh28_cut_target_seq.NEXTVAL,  'OPEN',  55);-- First NEXTVAL is 100 while row 100 already exists:-- ORA-00001: unique constraint (...) violated

This is a classic logical-migration failure: table rows moved, but generated-key state did not. A connection smoke test would never detect it.

9. Repair sequence state before accepting traffic

DROP SEQUENCE sh28_cut_target_seq;CREATE SEQUENCE sh28_cut_target_seqSTART WITH 102 INCREMENT BY 1 CACHE 20;INSERT INTO sh28_cut_target(  work_order_id,status_code,amount) VALUES(  sh28_cut_target_seq.NEXTVAL,  'OPEN',  55);COMMIT;SELECT work_order_id,status_code,amountFROM sh28_cut_targetORDER BY work_order_id;

Production sequences may use CACHE, CYCLE, ORDER/NOORDER, scalable/session/global behavior and application assumptions. Capture each sequence definition/high-water requirement rather than merely setting max(id)+1 everywhere.

10. Service/DNS/pool cutover is an application operation

Change one stable application endpoint rather than hard-coded hostnames spread across services. Lower DNS TTL in advance if DNS is part of the design, update Oracle service descriptors/secrets/wallets, drain or recycle connection pools so old physical sessions do not stay pinned to the source, and observe new sessions on the target.

SELECT  SYS_CONTEXT('USERENV','DB_NAME') AS db_name,  SYS_CONTEXT('USERENV','CON_NAME') AS con_name,  SYS_CONTEXT('USERENV','SERVICE_NAME') AS service_name,  SYS_CONTEXT('USERENV','INSTANCE_NAME') AS instance_nameFROM dual;

This proves where the session landed; it does not prove the target data/schema/sequence/workload is correct.

11. Post-migration validation matrix

• Table/partition row counts and business aggregates/checksums.
• Sequences/identities, constraints, indexes, triggers, grants, synonyms, views, jobs and DB links.
• Invalid objects and component/SQL patch state.
• NLS character sets, time-zone file and COMPATIBLE.
• TDE wallet/key and encrypted objects where used.
• Critical SQL runtime plans/latency/throughput, not only EXPLAIN PLAN.
• Backup/restore on the target and monitoring/alert routing.
• Application pool/service identity and write/read smoke tests.

12. Rollback must define the authoritative writer

Before cutover decide exactly when source writes are disabled, how target-only writes are handled if rollback is needed, and whether reverse replication exists. A rollback that simply points DNS back after the target accepted new writes can lose data. If bidirectional/reverse replication is not part of the tested design, keep the validation window short and prevent/record target writes until the migration is committed.

13. Cloud migration is still Oracle-version/platform engineering

OCI/Autonomous/Base Database/Exadata services can add managed migration paths and object-storage Data Pump workflows, but the same questions remain: supported source version, target offering/feature limits, encryption/wallet conversion, endian/datafile rules, network throughput, service names, client certification and licensing. Cloud does not turn an unsupported physical method into a supported one.

14. Cleanup and production judgment

DROP SEQUENCE sh28_cut_target_seq;DROP TABLE sh28_cut_target PURGE;DROP TABLE sh28_cut_source PURGE;

Select migration technology from platform/endian/version, amount of data, allowed downtime, remapping needs and rollback. GoldenGate can shrink the final synchronization window, but it is separately licensed and adds replication lag, supplemental logging, process monitoring and cutover complexity. Never declare success from connectivity alone.

Cross-platform Backup and Recovery is listed as available in Free, while production GoldenGate is a separate licensed product. No mandatory lab enables GoldenGate or uses RAC/Data Guard. This chapter closes the change lifecycle: inventory → precheck → copy/transform → synchronize → cut over → verify → commit/rollback.

Authoritative references

• RMAN Backup and Recovery Reference — CONVERT — cross-platform/endian conversion rules
• Oracle AI Database Upgrade Guide — cross-platform migration planning
• Oracle GoldenGate Licensing — GoldenGate/ADG/XStream license rights
• ENABLE_GOLDENGATE_REPLICATION — parameter and explicit license warning
• Licensing Information — cross-platform backup/recovery and offering matrix