Migrating to Database@Azure or @AWS: Stepwise Plan

Most cloud database migrations follow a familiar script: stand up the target, copy the data, repoint the applications, decommission the source. A move to Database@Azure or Database@AWS follows the same broad arc, but the details diverge at almost every step, and teams who treat it as a routine lift discover the differences at the worst possible moments. This article lays out a stepwise plan, six phases plus a condensed master checklist, that reflects how these projects actually succeed.

It belongs to our multicloud database series. The pillar, Oracle Database@Azure, @AWS, and @Google Cloud: The Buyer Guide, covers whether and where these services make sense at all. This article assumes that decision is made and answers the next question: how to get the estate there without burning a year or a weekend you cannot afford.

Why this migration looks different

Four things separate a Database@ migration from a conventional cloud database move.

The platform is Exadata. You are not migrating to a generic managed database service with elastic everything. You are landing on dedicated Exadata infrastructure that must be sized, reserved, and provisioned before the first byte moves, which makes the sizing work in phase 0 consequential in a way it is not when the target can be resized with a click.

The network belongs to the partner cloud. The database sits inside an Azure virtual network through a delegated subnet, or inside an AWS VPC through an ODB network. Application traffic, name resolution, and security controls live in the partner cloud, while the database service itself runs on OCI hardware. The people who own your Azure or AWS landing zone must be in the project from the start, not consulted at cutover.

Two control planes are in play. Provisioning, identity, monitoring, and operations span the partner cloud portal and the OCI console. Some actions happen in one, some in the other, and a team that has only ever lived in one console will hit friction. The operating model has to be designed, not assumed.

Procurement runs in parallel with engineering. The service is bought through the partner cloud marketplace, almost always as a negotiated private offer that interacts with your existing spend commitments. That commercial track has its own timeline, approvers, and failure modes, and it must land before the technical track needs capacity. Projects stall far more often on an unsigned offer than on a failed Data Pump job.

Phase 0: Assessment

Everything downstream depends on knowing what you actually have, so the assessment deserves rigor rather than a spreadsheet of guesses. Inventory every database in scope: versions and patch levels, editions, the options and packs actually in use rather than merely installed, sizes on disk, daily change rates, and the application dependencies hanging off each one. Change rate matters more than size for method selection, because it determines whether replication based approaches can keep up and how long a final synchronization will take.

Two checks belong here that teams often defer. The first is the licensing position: what you own, what you actually use, and whether BYOL or license included rates will carry each workload. Settling this early shapes the private offer itself, and the mechanics are covered in our article on licensing for the Database@ services. The second is region availability. These services exist in a specific and growing list of partner cloud regions, and a plan built for a region where the service does not yet exist is not a plan. Verify against the footprint in our regions and availability guide, and confirm capacity with Oracle, not just listed availability.

The output of phase 0 is a scored inventory: which databases move, in what order of difficulty, on what target sizing, under what licensing model, to which region. Size from measured demand over a representative period, not from peak guesses, because the Exadata reservation you choose here becomes the cost floor for years.

Phase 1: Commercial and landing zone, in parallel

Phase 1 runs two workstreams side by side, and the discipline of the whole project is keeping them in step.

The commercial workstream negotiates the marketplace private offer: the rate card, the term, the commitment structure, and how the spend draws down your existing Azure or AWS agreements. The licensing model chosen in phase 0 feeds directly into this, since BYOL and license included rates produce very different offers. Build in headroom for the rehearsal period, when source and target run side by side, and check the offer validity window against the project schedule. Offers expire, and renegotiating one mid project with no leverage is an avoidable misery.

The technical workstream builds the landing zone. On the partner cloud side that means identity federation with OCI, the delegated subnet or ODB network with its routing and name resolution, and the security controls the database traffic will live under. On the OCI side it means the tenancy wiring: compartments, groups, and policies governing the database resources. Across both it means the unglamorous foundations that make day two livable: naming standards, a tagging scheme finance can use for cost attribution, and guardrails that stop the first emergency from becoming a precedent. The platform specifics differ by provider, and our guides to Database@Azure and Database@AWS walk through each in detail. This landing zone build is the heart of our OCI implementation practice, and it is the piece teams in a hurry skip, then spend phase 4 fighting their own foundations.

Phase 2: Choosing the movement method

With the target standing, the next decision is how each database physically moves. There is no single right answer; a serious estate usually uses two or three methods across its portfolio.

The selection logic is simpler than the table suggests. Databases that can take an outage window move by Data Pump or RMAN, because simple methods fail less. Large databases with tight windows move by Data Guard or ZDM. The handful of genuinely critical systems with near zero tolerance and a hard failback requirement justify GoldenGate, and only that handful, because replication complexity is paid for in engineering hours and operational risk. Standardize on the simplest method each database can tolerate, not the most sophisticated one available.

Phase 3: Rehearsal

Rehearsal is the phase that separates migrations that go quietly from migrations that make the incident channel famous. Pick representative databases, one per method and one per size class, and run the full migration end to end into the real target. Time every step: the copy, the synchronization, the switchover, the application repoint, the validation. Those timings become the schedule for phase 4, and a schedule built on measured rehearsal numbers survives contact with reality in a way estimates never do.

Rehearsal also covers what happens after the data lands. Run application regression against the migrated copies, because connection strings, drivers, and latency profiles all change. Capture performance baselines on the old platform and compare them on the new one; Exadata usually flatters the workload, but the exceptions, often queries whose plans shift, are exactly what you want to find in rehearsal rather than in production. Finally, rehearse the rollback itself at least once. A rollback that has never been executed is a hope, not a plan.

Phase 4: Cutover in waves

Resist the big bang. Group databases into waves by dependency, so applications and the databases they share move together, and sequence the waves from lowest risk to highest. Early waves carry development and test systems and the forgiving production workloads; they harden the runbooks and the team. Later waves carry the systems where a bad weekend has a board level audience, and by then the process has been executed enough times to be boring. Boring is the goal.

Each wave gets the same structure: a freeze window during which no changes land on the source, a decision gate before the point of no return with named people empowered to say go or no go, and explicit rollback triggers agreed in advance. Write the triggers as conditions, not vibes: validation queries that must match, response times that must hold, business transactions that must complete. If a trigger fires, you roll back, and nobody relitigates that decision at two in the morning. The wave plan also keeps the commercial track honest, because each wave consumes capacity the private offer must already cover.

Phase 5: Day two

Go live is the midpoint, not the finish. The first ninety days determine whether the migration delivers its business case or quietly erodes it.

Operationally, wire monitoring across both control planes so one pane of glass tells the on call engineer what is happening, and agree the patching cadence with application owners now, because Exadata maintenance is scheduled, not optional. Verify backups by restoring one, not by reading a green dashboard. Commercially, reconcile the first three invoices line by line against the offer and the sizing model: the first tells you whether the meters match the contract, the second the steady state, the third the trend. Variance caught in month two is a correction; in month nine it is a budget incident. Once the estate is stable, revisit licensing: rehearsal headroom can be released, BYOL coverage tuned to what is actually enabled, and support spend on stranded licenses addressed.

Many teams hand this phase to a partner. Our managed service runs exactly this rhythm, with 24/7/365 monitoring and a monthly cost and capacity review, and across our optimization work clients average a 40% reduction in OCI spend once sizing, licensing, and consumption align with reality.

The master checklist

The phases condense to eight steps. If you track one page, track this.

The mistakes that cost the most

The same failures account for most of the pain we get called in to fix.

• Sizing from peak guesses. The reservation becomes a cost floor, and folklore about peak load inflates it for the life of the contract.
• Skipping rehearsal. Every untimed step becomes a schedule risk, and the first real cutover becomes the rehearsal, performed on production.
• Treating licensing as a post go live cleanup. The licensing model shapes the offer, the rates, and the sizing. Deferred, it resurfaces as double payment or an audit exposure.
• No rollback criteria. Without written triggers, the rollback decision is made by exhausted people under pressure, which means it is made late or not at all.
• Letting the offer expire mid project. An expired private offer halts provisioning and hands all the negotiating leverage to the other side of the table.

Bringing it together

A Database@Azure or Database@AWS migration rewards teams that respect its dual nature. It is an Exadata project, so sizing matters. It is a partner cloud project, so the network and identity work belongs to the Azure or AWS team. And it is a commercial project, so the offer, the commitments, and the licensing model deserve the same project management as the data movement. Run the phases in order, keep the commercial track level with the technical track, move in waves with real gates, and verify the bill as carefully as the backups. Whether you run it on our fixed fee project model, hand the estate to a managed monthly service after go live, or engage us on an optimization basis with the fee paid only on verified savings, the plan is the same, because it is the plan that works.