UAN Team needed to relocate a 700 GB production Oracle database out of a locked-down third-party US datacentre and into AWS London — with zero business downtime and zero ability to install software on the source platform. MigDB Remote made it possible.
"SkyliftAI MigDB helped us migrate from a third-party hosted platform to AWS without any downtime."
UAN Team needed to relocate a 700 GB production Oracle database out of a locked-down third-party US datacenter and into AWS London — with zero business downtime and zero ability to install software on the source platform. Using MigDB Remote, the entire database transfer completed in 2 hours, and the end-to-end migration including application cutover finished in half a day, with no measurable latency impact on the live workload.
MigDB Remote was deployed in the AWS London region (eu-west-2) and connected to the on-premise source database over SQL*Net. All migration phases — initial load, change extract, capture, and apply — executed remotely. No binaries, agents, or configuration changes were required on the source platform.
Figure 1 — MigDB Remote in AWS London accessing the locked-down US source database over SQL*Net. No binaries, agents, or configuration changes were required on the source platform.
Zero tolerance for business application downtime — the workload could not be paused, even briefly, for cutover.
The source database was hosted in a secured third-party environment with no provision to install any software, agent, or replication binary.
No access to the on-premise platform to deploy any third-party software components — ruling out classic capture, in-database extracts, and most CDC products that require a source-side footprint.
MigDB Remote deployment pattern accesses the on-premise database remotely over standard SQL*Net — the only ingress UAN was willing to expose.
MigDB Remote was provisioned in the AWS London region (eu-west-2), inside a private VPC subnet, with TLS-secured SQL*Net tunnels back to the source listener.
Initial Data Load, Extract, Capture, and Apply phases were all driven remotely from MigDB — no source agents, no installed binaries, no privileged jobs on the source host.
Change Data Capture ran in parallel with the bulk load so the source database remained online and writable throughout the migration window.
The full migration was sequenced into five phases, executed end-to-end by the MigDB Remote orchestrator. CDC ran in parallel with the bulk load, so the source workload was never paused.
Figure 2 — Five-phase migration timeline; 700 GB transferred and applied in approximately 2 hours wall clock.
700 GB of production data was transferred from a US hosting center to AWS London with zero source-side agent footprint.
No measurable latency impact and no system downtime were observed during the migration window.
The full database migration — baseline plus CDC catch-up — completed in approximately 2 hours wall clock.
End-to-end migration including application cutover and validation completed in half a day.
| Capability | How it applied to UAN |
|---|---|
| Parallel CDC kept the source online throughout the cutover window. | |
| Tuned remote extract and apply pipelines reduced wall-clock time by half versus baseline tooling. | |
| Horizontal scaling of extract/apply workers handled the 700 GB volume without backlog. | |
| Schema discovery, parameter generation, and replicat provisioning were fully automated. | |
| No agent or binary touched the source host — entire pipeline driven from AWS London. | |
| TLS-secured SQL*Net, KMS-encrypted trail files, audit logging into customer SIEM. | |
| Single-pane orchestration console for monitoring all phases. | |
| Per-table lag, throughput, and validation metrics surfaced in real time. | |
| Centralized logs and structured error surfacing accelerated incident triage. | |
| Source in US datacenter, MigDB engine in AWS London, target in AWS — coordinated as one pipeline. |
Most CDC and migration tools assume you can deploy a capture agent on the source host or attach an in-database extract process. When that assumption fails — because of vendor restrictions, compliance posture, or a locked-down hosting contract — migrations stall.
MigDB Remote inverts the model: capture, extract, and apply all run on the target side, reaching back into the source only through the standard SQL*Net listener that the customer was already exposing.
The UAN engagement is a clean demonstration that a 700 GB, transatlantic, zero-downtime migration can be executed entirely from the landing zone, with no footprint on the source platform and no concession on cutover quality.
Facing a locked-down source environment or zero-downtime requirement? Talk to a SkyliftAI MigDB expert today.