Data Guard Switchover vs GoldenGate Cutover for a Small Single-Schema Oracle Migration

Goal is to move a small single-schema Oracle application to a new host with no user-visible downtime.

The constraint is low write volume and no session affinity requirement. Two documented approaches are under consideration: Data Guard physical standby switchover, which provides a controlled role reversal with a short application reconnect window assuming compatible releases and initialization parameters, and Oracle GoldenGate logical replication, which can tolerate different patch levels and allows a DNS or connection string flip but introduces ongoing lag monitoring and conflict handling overhead that is disproportionate for a small workload.

The unresolved decision concerns session and identifier continuity at cutover. Switchover implies a brief quiesce or reconnect window for in-flight transactions, while GoldenGate requires a defined point where writes stop on source to avoid late-arriving changes. Preserving database and service names simplifies reconnects but complicates rollback, while changing them avoids confusion but forces application configuration updates at cutover.

What is the expected behavior for in-flight transactions and connection pool reconnects during a Data Guard switchover versus a GoldenGate cutover point? How does preserving versus changing database service names affect rollback capability and required application configuration changes?