01 · Two Projects, One Switchover
A telecom operator needs to move an Oracle 12.2 database from an aging on-premises platform to 19c on ExaCC. Treated as two projects - migrate, then upgrade - this means two outage windows and two rounds of regression testing.
A physical online migration with an in-flight upgrade collapses this into one: the standby is built directly on the 19c Oracle Home on the target, redo from the 12.2 primary is applied and transformed in flight, and a single switchover completes both moves at once.
Q: What is a physical online migration?
A: A migration method that builds a Data Guard physical standby on the target platform while the source stays live, then performs a switchover once the standby is fully synchronized - combining platform migration with near-zero downtime.
02 · What Makes It Physical and Online
Physical means the target is a block-for-block replica maintained via redo apply, not a logically reconstructed copy. Online means the source database remains fully available to applications throughout the entire build and sync process - only the final switchover requires a brief application pause.
It helps to treat these as two separate yes/no questions rather than one combined label. A migration can be physical and offline (a plain RMAN restore from backup), physical and online (this article's topic), logical and offline (Data Pump), or logical and online (GoldenGate) – the two properties are independent of each other. Understanding them separately makes it obvious why "physical online" specifically is the combination that lets you change platform, hardware, and even Oracle version in one motion, without ever taking the source out of production.
Figure 2 · Physical and online are two independent properties of the migration
03 · Standby Instantiation to Switchover
Throughout redo apply, the standby continuously replays transactions from the source while internally accommodating the target's higher release - a mode Oracle refers to as a transient logical/physical upgrade path when combined with ZDM automation.
Notice that the standby in this diagram is not running the same Oracle Home version as the primary - that's what makes the in-flight upgrade possible. Redo generated on the 12.2 primary is transported and applied on a standby built from the 19c Oracle Home, so by the time the standby has fully caught up, it holds an exact copy of the data on the newer release. The switchover at that point is simply a role reversal between two already-synchronized databases, not a separate migration step.
Figure 4 · This migration method is really three independent properties working together
04 · Physical Online vs Offline
| Dimension | Physical Offline (RMAN/XTTS) | Physical Online (Data Guard) |
|---|---|---|
| Source Availability | Read-only or down during transfer | Fully read-write until switchover |
| Downtime | Hours, proportional to data size | Minutes, independent of data size |
| Version Upgrade | Separate step | Combined in-flight |
| Network Sensitivity | One-time bulk transfer | Sustained redo transport bandwidth |
05 · Best Practices
- Run the Pre-Upgrade Assessment EarlyCatch deprecated parameters and dictionary incompatibilities weeks before the switchover date, not the night of.
- Monitor Redo Transport Lag ContinuouslyDo not schedule switchover until lag has been at zero for a sustained period, not just momentarily.
- Rehearse the Switchover Command SequencePractice against a non-production standby to remove hesitation from the live cutover.
- Keep a Documented Rollback TriggerDefine, in advance, the exact conditions under which you would switch back rather than push forward.
Every stage before "Switch" can run for hours or even days without any user-visible impact, because the source keeps serving production traffic the entire time. The only stage that touches the application is the switchover itself, and by the time you reach it, the standby has already proven – through sustained zero lag – that it holds an exact, up-to-date copy of the source. That is what turns a multi-terabyte platform migration into a cutover measured in minutes rather than a maintenance window measured in hours.
Figure 3 · Only the final stage is visible to the application
06 · Technical FAQs
Can a physical online migration also upgrade the database version?
Yes. Building the standby on a higher-release Oracle Home completes both the platform move and the version upgrade in one switchover event.
What is the biggest risk during redo apply?
Redo transport lag. If network throughput between source and target can't keep pace with redo generation, the standby falls behind and the switchover must be delayed.
Is this approach compatible with ZDM?
Yes - ZDM automates exactly this workflow end to end, including the pre-upgrade assessment and switchover orchestration.
The Method Is the Migration
Collapsing a migration and an upgrade into a single switchover demands precise redo transport monitoring and a rehearsed cutover sequence. ExaGuru's DB Migration course walks through the full Data Guard standby build, in-flight upgrade, and switchover validation.
A physical online migration doesn't eliminate risk - it concentrates all of it into one well-rehearsed moment.
At ExaGuru, our Oracle Database Migration Masterclass covers ZDM, GoldenGate, XTTS, RMAN and OCI DMS migration patterns end to end.