Oracle Cloud Infrastructure migration, planned around your downtime

We move Oracle databases, and the applications that depend on them, from your data center or another cloud to Oracle Cloud Infrastructure (OCI). For each database we choose the OCI service and the migration method with you, rehearse the switch on a copy of production and keep a way back until you are sure. Afterwards your own team can run the new environment, or our remote DBAs can.

Book a strategy call See case studies

What we cover

Choosing the targetPick the OCI service that fits each database
Migration methodsChoose the method by the downtime you can accept
Before the data movesSet up the tenancy, network and security first
The switchRehearse the cut-over, and keep a way back
Risks we plan forThe surprises we look for before they find you
After the moveRun it yourself, or let our DBAs run it

Choosing the target

Pick the OCI service that fits each database

OCI offers several homes for an Oracle database, and they differ in who looks after what. Base Database Service runs your database on virtual machines whose infrastructure Oracle manages, while you keep control of the database itself. Exadata Database Service runs it on Exadata, for databases that need its performance and scale. Autonomous Database automates patching, tuning and backups, in exchange for less control over configuration. A compute instance lets you install and run Oracle Database exactly as you do today.

We start with an inventory: versions, sizes, the features in use (RAC, Data Guard, partitioning, database links), the applications that connect and how long each database can be unavailable. From that we recommend a target for every database and write down why, so your architects and your finance team can check the reasoning.

What we do

Inventory of databases, versions, features and dependencies
A recommended OCI service for each database, with the reasons
Sizing and a running-cost estimate for each option
A move order that puts the low-risk databases first

Migration methods

Choose the method by the downtime you can accept

The right method depends mostly on how long the database can be offline. When the business can accept a planned window, an RMAN backup restored in OCI or a Data Pump export and import is simple, well understood and easy to test. When it cannot, we build the OCI database as a Data Guard standby of the current one and switch over, or keep the two in sync with Oracle GoldenGate so users carry on working on the old database until the new one has passed its tests.

Oracle's Zero Downtime Migration tool and the OCI Database Migration service automate much of this, and we use them where they fit. Two things narrow the choice: a change of Oracle version, and a move from a big-endian platform such as Solaris on SPARC or AIX to Linux on x86, which rules out a physical standby. We prove the chosen method on a copy before anyone relies on it.

What we do

RMAN or Data Pump when a planned outage window is acceptable
A Data Guard standby in OCI, then a switchover
Oracle GoldenGate for cross-version moves with users still working
Zero Downtime Migration and OCI Database Migration where they fit

Before the data moves

Set up the tenancy, network and security first

Cloud migrations are slowed down as often by the network and permissions as by the data. Before the first database moves we agree the compartments, the virtual cloud network with its subnets and security rules, the link back to your data center (site-to-site VPN or FastConnect), the identity and access policies, the encryption keys and the backup policy. Every choice is written down, so your own team can run and audit the environment without us.

What we do

Compartments, virtual cloud network, subnets and security rules
Site-to-site VPN or FastConnect to your data center
Access policies, keys in OCI Vault and Transparent Data Encryption
Backups to Object Storage, with a tested restore

The switch

Rehearse the cut-over, and keep a way back

Each move has a written runbook: every step, who does it, how long it took in rehearsal and the check that shows it worked. We rehearse on a copy of production, compare row counts and checksums between the old and new databases, and test the applications against OCI before the real switch. Where the method allows it, the old database is kept in sync after the switch, so going back to it is a decision rather than a restore.

It is the approach we used to move a 30 TB Oracle database for a global retail bank with zero downtime: the new platform built alongside the old one, the two kept in sync with GoldenGate, everything tested, then a planned switch. That move was between two on-premises platforms, and the same steps apply to a move to OCI.

What we do

A written runbook, timed in rehearsal
Row-count and checksum comparison of every table
Application and performance tests before go-live
A fallback agreed before the switch

Risks we plan for

The surprises we look for before they find you

The problems that delay a move to OCI are usually predictable. Database links, directory objects, external tables and scheduler jobs may assume a server in the same building. Applications that stay on-premises can slow down when every query crosses a wide-area link. Character sets and time zones can differ between the old and new databases, and SQL can run differently after a version upgrade. We look for each of these in the assessment, test them in rehearsal and record how each one is handled.

What we do

Database links, directories and jobs that point at local servers
Latency for applications that stay on-premises
Character set, time zone and version differences
SQL performance compared before and after the move

After the move

Run it yourself, or let our DBAs run it

When the databases are live we hand the runbooks, the monitoring and the backup checks over to your team. If you would rather not run them yourselves, our remote DBAs can look after the OCI databases along with the rest of your estate: patching, tuning, backups and the on-call cover agreed at the start. The same engineers move Oracle databases to other clouds too, as they did for a national nonprofit whose Oracle database they moved from its own servers to Amazon RDS for Oracle.

Case studies

Oracle Cloud (OCI) Migration in practice

Client names are withheld. We are happy to share details on a call.

All case studies

Delivered
30 TB, zero downtime
Financial services
Oracle
Zero-downtime move of a 30 TB Oracle database for a global retail bank
The bank's transaction database served thousands of users around the clock. We built the new Oracle 12c RAC platform on IBM AIX alongside the old Solaris system, kept the two in sync with Oracle GoldenGate, tested everything and switched over with no downtime and no data loss.
- 30 TB moved with zero downtime
- Zero data loss at cut-over
Read the case study →
Delivered
On-prem → Amazon RDS
Nonprofit
Oracle
Oracle from on-premises to Amazon RDS for a national nonprofit
The nonprofit's on-premises Oracle database had become hard to maintain and scale. We planned the move with automated workflows and validation tests, migrated to Amazon RDS for Oracle with minimal disruption and left a repeatable process for future changes.
- Automated, tested migration
- Less day-to-day database upkeep
Read the case study →

Questions

Common questions

Which OCI database service should we use?

It depends on how much control you need and how much routine work you want to hand over. Base Database Service suits most databases that are moving as they are. Exadata Database Service suits large or performance-critical databases. Autonomous Database suits applications that need no unusual configuration, run by owners who want routine administration automated. We recommend one per database after the inventory, with the reasons.

Can we move to OCI without downtime?

Close to it, for most databases. With a Data Guard standby or Oracle GoldenGate, users keep working on the old database while the new one is prepared and tested, and the switch itself is a short, planned pause while connections move. How short depends on the version, the platform and the applications, so we measure it in rehearsal rather than promise it in advance.

Can we bring our existing Oracle licences to OCI?

OCI database services are offered either with the licence included or with licences you already own (bring your own licence). Which is cheaper depends on the licences and support contracts you hold. We set out the options for each database so that your licensing team, or Oracle, can confirm them before you commit.

What happens to the applications that use the database?

Each one is part of the plan. Some move to OCI compute alongside the database, some stay where they are and connect over VPN or FastConnect, and some only need new connection details. We test every application against the new database, including how quickly it responds over the network, before the switch.

How long does an OCI migration take?

It depends on the number and size of the databases, the methods and how often the business can accept change. Our migration plan consult ends with a fixed-scope plan that sets out the order, the method for each database and the risks, so the timeline is based on your estate rather than on a general estimate.

From the blog