A regional healthcare network's patient-records platform had been stuck on Oracle 11g for years — every prior upgrade attempt stalled on fear of breaking heavily customized PL/SQL. OptiSol used log-based replication to move the estate to Oracle 19c with an estimated few minutes of read-only impact.
The platform's Oracle 11g database had been out of Premier Support for years. Every internal proposal to upgrade had been shelved — the risk of breaking custom logic outweighed the risk of staying put, until it didn't.
Oracle 11g had passed both Premier and Extended Support. Any newly disclosed vulnerability affecting the patient-records database would go unpatched — a compliance and security exposure the organization could no longer accept.
Clinical workflows, billing rules, and integration logic were embedded across hundreds of packages and triggers written over more than a decade. No one on the current team could confirm what would happen to that logic on a newer optimizer.
The database backs clinical order entry and patient lookups used around the clock. A traditional export/import upgrade path — with the database offline for the duration — was not an acceptable option for a care-facing system.
Rather than a big-bang DBUA upgrade, we built a parallel Oracle 19c environment, proved every piece of custom logic against it, then used replication to keep it current until cutover was a formality.
Full inventory of packages, procedures, triggers, and deprecated features against Oracle 19c. Preupgrade.jar identified fix-up items; every one was logged, owned, and closed on a clone before touching anything else.
A dedicated Oracle 19c environment was built and schema-migrated using Data Pump. Every custom package and trigger was recompiled and unit-tested in isolation, well ahead of any production data flowing to it.
Oracle GoldenGate was configured to capture and apply changes from the 11g source to the 19c target in near real time, keeping the new environment current throughout weeks of validation without a freeze on production.
Order entry, billing runs, and integration jobs were executed against both environments side by side. Every discrepancy — including optimizer-driven plan changes — was resolved with SQL Plan Baselines before go-live was scheduled.
Once replication lag was consistently near zero and parity was confirmed, application traffic was switched to the 19c target during a short read-only window. A tested rollback plan stood ready throughout — and was never needed.
"We had been putting this off because everyone assumed the custom logic would break. Watching it run clean against 19c for weeks before we ever touched production changed how the whole team thinks about upgrades." — OptiSol Oracle Engineering Lead
Let's Talk
Tell us what you are running today and where you need expert support.
"*" indicates required fields
Global Presence
Five global locations. One connected engineering team.
North America
Chennai · Coimbatore
Client services
Regional operations
Client services
