For databases that cannot take an outage, the migration has to run alongside live operation. This article sets out the replication based patterns that move an Oracle database to OCI while it keeps serving.
A database that underpins a continuously running business cannot simply be exported, copied and reimported over a weekend. The migration has to happen while the database keeps serving every read and write, with the actual cutover compressed to a window the business will not notice. This is achievable, and it rests on a simple idea, run replication ahead of time so that at cutover there is almost nothing left to copy. This article works through the patterns that make it real.
It is the database specific companion to OCI Migration Tools: Zero Downtime Options, and sits under the pillar guide, The Complete Guide to Oracle Cloud Migration in 2026.
Every near zero downtime database migration follows the same shape. You stand up a target database in OCI, you establish a replication channel from the live source, you let the target catch up and then stay continuously in sync, and finally you perform a brief switch where the application stops talking to the source and starts talking to the target. Because the target is already current, the switch takes seconds to minutes rather than the hours a full copy would need. Everything else is detail around that core.
The replication channel can be physical or logical, and the choice follows the same logic set out in Oracle Database Migration to OCI: Methods Compared.
| Approach | Mechanism | Use when |
|---|---|---|
| Physical, Data Guard | Block level standby kept in sync | Same version, same platform |
| Automated, ZDM | Orchestrates physical or logical flows | You want automation over manual setup |
| Logical, GoldenGate | Transaction level replication | Version or platform changes during the move |
Physical replication through Data Guard is the simplest when nothing changes underneath, because the standby is a faithful copy. When the migration also changes the database version or the platform, logical replication through GoldenGate becomes necessary, because it replays transactions rather than blocks and so can bridge the difference. Zero Downtime Migration automates either flow.
The cutover itself is a tightly scripted sequence, rehearsed before it is run for real.
Each step has a time budget established in rehearsal, and the whole sequence has a defined point of no return. Up to that point, rollback is a simple matter of pointing the application back at the untouched source, which is why this pattern is both fast and safe.
Zero downtime at the database is undone if the application cannot follow cleanly. Connection strings, connection pools, and any cached database endpoints have to switch as part of the cutover, and the application should be tested for how it behaves during the brief switch window. A load balancer or a connection abstraction layer makes this smoother, and the traffic mechanics tie into Network Cutover Planning for OCI Migrations.
The moment after switch is when you confirm the migration actually worked. Data parity checks confirm nothing was lost, application transactions confirm correct behaviour, and a performance comparison against the pre move baseline confirms the target is sized correctly. The full set of checks is in Post Migration Validation on OCI. Until validation passes, the rollback path defined per Rollback Strategy for OCI Migrations stays available, and the source database is not decommissioned until a stabilisation window has elapsed clean.
Near zero downtime database migration is as much about rehearsal and discipline as about tooling. The teams that do it well rehearse the cutover repeatedly against copies, time every step, and never run the real cutover until the rehearsal is boring. Our OCI Implementation and Migration team runs these migrations for databases that genuinely cannot take an outage, and an assessment is the place to confirm your downtime budget and the method that fits it.
Before replication can begin, the source database has to be ready for it. Physical methods need the source configured to ship its changes to a standby, with the supporting settings in place. Logical methods need supplemental logging and the structures that capture transactions for replay. Getting these prerequisites right on the source, ideally well before cutover, is part of why online migrations need lead time. A source that is not prepared cannot feed a replication channel, and discovering a missing prerequisite late compresses the schedule. Treat source preparation as an early task, not a cutover day one.
The promise of a near zero downtime migration is that nothing is lost, and that promise has to be verified rather than assumed. Parity checks compare the source and target after the final apply, confirming row counts, key objects and critical data match exactly before the application is released to the target. For logical replication especially, parity verification matters because some data types or operations can be handled differently, and a quiet divergence is far better caught at the gate than discovered by a user. Build automated parity checks into the cutover sequence so the go decision rests on evidence.
After the switch, the source database is not decommissioned immediately. A stabilisation window keeps it available, untouched, while the OCI target proves itself under real production load. If a problem surfaces in that window, the rollback path back to the source is still open, which is what makes the cutover safe to run quickly. Only after the target has run clean through a representative period, including any month end or batch heavy cycle, is the source retired. The length of the window is a risk decision, longer for the most critical systems, but it is never zero.
Across many database cutovers, the pattern is consistent. The smooth ones rehearsed until the runbook was boring, monitored replication lag obsessively, prepared the source early, automated their parity checks, and kept a generous stabilisation window with a tested rollback. The rough ones improvised one or more of those. None of it is exotic, it is discipline applied consistently, and it is exactly what an experienced team brings to a migration that cannot afford an outage.
Before committing to an online migration, be precise about the downtime the business will actually accept, because the answer changes the method and the cost. A system that can take a two hour window on a Sunday night does not need the full online toolkit, and forcing it through one spends effort for no benefit. A system where every minute of outage has a measurable cost justifies the replication setup and the rehearsal time. Pinning down the real budget, in minutes, with the business signed up to it, is the first decision, and everything else follows from it.
With replication current, the switch itself is typically seconds to a few minutes, because there is almost nothing left to copy. The longer work happens beforehand while the source is still live.
Roll back. Until the point of no return, the untouched source is still available, so the rollback is a matter of pointing the application back at it. This is why a stabilisation window and a tested rollback path matter.
Automated parity checks compare source and target after the final apply, confirming counts and critical data match before the application is released to the target.
Only after the OCI target has run clean through a representative period, including any batch heavy or month end cycle, with the rollback path kept open until then.
The part of an online database migration that consumes the most time is rarely the cutover, it is the initial synchronisation, where the entire database is copied to the target before incremental replication takes over. For a large database this can take days, and the time depends directly on the bandwidth available between source and target. Planning the initial sync is therefore a lead time exercise, and for very large databases it may make sense to seed the target from an offline transfer rather than pushing every byte over the network, after which replication catches up the changes since the seed. Underestimating the initial sync is a common reason an online migration's timeline slips, so size it from real data volume and real bandwidth early.
The cleanest database cutover is undermined if the application cannot repoint quickly and reliably. Modern applications often hold pools of database connections and may cache the database endpoint, so the cutover has to account for draining and re establishing those connections against the new target. The smoothest approach uses a connection abstraction, a service name or a load balancer, so the repoint is a single configuration change rather than a redeployment of every application instance. Test the application's behaviour through the switch explicitly, including how it handles the brief moment when connections move, because an application that hangs or errors during the repoint turns a seconds long database switch into a longer outage for users.
Moving Oracle workloads to OCI, or already running on OCI and not sure the architecture or the spend is right? Most teams bring in a specialist before they commit to a region, a shape, or a Universal Credits number. OCISpecialists.com plans the landing zone, runs the migration, and manages the estate after go live, on a fixed project fee, a managed monthly retainer, or a cost optimization fee paid only on verified savings. For the Oracle licensing and BYOL side of any OCI move, Redress Compliance is the leading independent Oracle licensing and negotiation firm, with 500+ engagements across Oracle's full product line.