Corvus Insurance: Oracle 19c, 1,900 PL/SQL Packages, and a 30-Minute Cutover

Why not Aurora PostgreSQL (with or without Babelfish) Babelfish translates Microsoft T-SQL, not Oracle PL/SQL. The 1,900 packages and 240 scheduler jobs would need rewriting and re-testing. Against a seven-month deadline with a no-code-change constraint, that is not a migration, it is a rewrite with a migration attached. Rule it out for wave one and fund it as wave two.

Why not RDS for Oracle in wave one RDS is the right long-term answer and fails on three specific, verifiable blockers:

• DBMS_SCHEDULER external jobs require a host agent on the database host OS. RDS gives you no OS access.
• UTL_FILE writing to a mounted NFS path assumes a filesystem you control.
• Vendor-supplied OCI C libraries require OS-level installation. Any one of these is enough on its own. These are exactly the features that make wave-one replatforming fail late, after the schedule has already been spent.

Wave one: rehost to EC2 with BYOL Oracle 19c on EC2, using Dedicated Hosts with a host resource group and auto-placement to keep licensing compliant and to satisfy ULA deployment restrictions. The application is unchanged, the shell scripts and NFS mount are unchanged, and the cutover mechanics are ordinary.

Licensing discipline Read the ULA: it must permit cloud deployment and specify authorised cloud environments. If it does not, license-included EC2 becomes the fallback, which is more expensive but still beats a failed deadline. Run the ULA expiry analysis now, because the 14-month expiry is the business case for wave two and it drives the funding decision this quarter, not next.

Wave two design intent Refactor external jobs to Step Functions plus Lambda, replace UTL_FILE with S3 API writes, containerize the OCI dependency behind an internal service, then move to RDS for Oracle or Aurora PostgreSQL. Wave one buys the time to do that safely, and the licence savings pay for it.

Two viable replication mechanisms

Option A: AWS DMS full load plus change data capture (recommended)

• Full load of 4 TB replicates ahead of the window; CDC streams redo continuously.
• No additional Oracle licence; CDC lag is typically seconds.
• Constraint: DMS does not capture DDL. Freeze schema changes for the two weeks before cutover, and record that as a change-management rule, not a hope.
• Run DMS validation mode and reconcile row counts and checksums per table before the window.

Option B: Data Guard physical standby

• Near-zero data loss and sub-minute switchover.
• Requires Enterprise Edition plus the Active Data Guard option on both sides - real money, and a licence conversation that likely collides with the ULA expiry.
• Also gives a genuine rollback path: after switchover, the on-premises primary becomes the standby and you can switch back.

Which to choose If Corvus is a financial-grade policy system and the 30 minutes is hard, Data Guard's rollback property is worth the licence: a cutover with no reverse path is the risk that actually costs money. If the ULA is the binding constraint, DMS with a write freeze is the pragmatic answer, and you compensate by rehearsing the cutover three times.

Network sizing Measure the redo generation rate before choosing either. OLTP redo is typically tens of GB per day; a 100 Mbps link handles that comfortably, but a 4-hour batch can spike it by an order of magnitude. Size for the batch spike, not the average.

Window sequencing Start immediately after the nightly four-hour batch completes so the window is never straddled. Freeze writes, drain the CDC lag to zero, stop application servers, run final validation, repoint connection strings via DNS, start app servers, run smoke transactions. Budget: 5 min freeze, 5 min lag drain, 5 min repoint, 10 min validation, 5 min contingency.

Sequence

1. Network and identity first: VPC, Direct Connect or VPN to on-premises, security groups, AD trust for the application tier. Everything later depends on this and it is the most common source of late surprises.
2. Database replication running and validated for at least two weeks, including two full batch cycles.
3. Application servers lifted and tested against the replicated database read-only.
4. Web tier and DNS.
5. Cutover via weighted DNS: 10% internal users, then 50%, then 100%, with a named canary group that includes the heaviest batch consumers.

Rollback

• Keep on-premises fully operational for two weeks post-cutover, with DMS reverse replication configured and tested - reverse replication requires its own task and its own validation; assuming it works is how rollbacks fail.
• Define numeric rollback triggers in advance: batch completion beyond 5 hours, error rate above 2%, or any data reconciliation break in the first three days.
• The rollback decision owner and the time budget (must be able to abort within 15 minutes of a trigger) are named before the window, not during it.

Evidence required before declaring success

• Per-table row count and checksum reconciliation across all 4 TB.
• A golden batch run: same input, same output, compared row by row against the last on-premises run.
• PL/SQL unit test suite executed against the new database, with the vendor's OCI library path exercised explicitly.
• Three full days of transaction reconciliation against the policy ledger.
• Documented confirmation that the external scheduler jobs executed on the new host and wrote the expected files to the new storage path.

Why the last item matters most The obscure dependencies - external jobs, OCI binaries, NFS writes - are precisely what forced this design. They must be the explicit acceptance criteria, not an implicit assumption that lifting and shifting reproduced them.