Checklist: move an Oracle database to the cloud

Who this is for

Checklist: move an Oracle database to the cloud is written for the team that owns the database and now has to put it somewhere else: the DBA who knows the schemas, the application lead who owns the release calendar, and the finance or procurement person who tracks the Oracle contract. It assumes the database is in production and that people depend on it every day.

Oracle is not a generic database when it comes to moving. Edition, options, multitenant layout, character set and block size all shape what the target can accept. A Standard Edition 2 database behaves very differently from an Enterprise Edition database using Partitioning, Advanced Compression and Active Data Guard. Write those facts down before anyone talks about instance sizes.

It also helps to know which kind of target you want. A self managed Oracle home on a cloud virtual machine gives you the control you have today, including operating system access and full parameter changes. A managed service such as Amazon RDS for Oracle or Oracle Autonomous Database removes that access and takes some features off the table. The checklist works for either, but the answers change.

Before you begin

Start with an inventory you can defend. Pull the version and patch level from v$instance and dba_registry_sqlpatch, check v$option and dba_feature_usage_statistics for options in use, and record the character set and national character set from nls_database_parameters. Note the block size from dba_tablespaces and the time zone file version from v$timezone_file. Those four facts cause more failed imports than anything else in an Oracle move.

Decide the licensing path early, because it drives the target shape. Bringing your own license means the cloud host has to meet the core and virtualization rules in your Oracle agreement, and that conversation belongs to whoever owns the contract. A license included model removes that work but limits which shapes and editions you can pick. Get the answer in writing before you size anything.

Set the scope of the move in one sentence. Are you lifting the database as it is, or are you also upgrading the version, converting to multitenant, or changing the application? Each of those adds separate risk. Doing all of them in one cutover is possible, but you need a longer rehearsal and a clearer rollback.

The checklist

Work the list in order. The early items cost almost nothing and prevent the expensive mistakes. Assign an owner and a date to each line, because a checklist without owners is just a wish list.

Treat anything you cannot test before cutover as a risk you are accepting, not a detail to solve on the night. That includes options the target does not offer, operating system access the application assumes, and any hard coded host name or connection string.

• Write down the source facts: version, patch level, edition, options in use, character set, national character set, block size and time zone file version.
• Confirm in writing whether you bring your own Oracle license or use a license included model, and let that answer narrow the target platform.
• Pick the target type, a self managed Oracle home on a cloud virtual machine, a managed service such as Amazon RDS for Oracle, or an Exadata offering, and list the features it does not support.
• Measure the workload across a full business cycle, including peak CPU, redo per second, IOPS, session counts and monthly growth.
• Run a full size Oracle Data Pump export and import into the target with the parallelism you plan to use, so the elapsed time is real.
• Match the target character set, block size, compatible parameter and time zone file version to the source before you load any data.
• Test every option you depend on, such as Partitioning, Advanced Compression, Database Vault, Label Security or Spatial, on the target itself.
• Choose the cutover method and write down why: Data Pump inside a maintenance window, Data Guard switchover, Oracle GoldenGate replication, or transportable tablespaces.
• Turn on archivelog mode, backups and retention on the target on day one, then restore a backup to a scratch instance to prove it works.
• Copy the parts people forget: scheduler jobs, database links, directories, external table locations, public synonyms, and any Java or C stored code.
• Recreate users, roles and grants deliberately instead of trusting a full export, and check system privileges granted to application schemas.
• Gather fresh optimizer statistics, then compare your top SQL statements against the source with SQL Plan Baselines and AWR reports.
• Rehearse the cutover end to end with the application connected, including DNS or connection string changes and the rollback step.
• Keep the source available and read only for an agreed period after cutover, with a named person who can trigger the rollback.

What good looks like

A good migration ends with evidence, not opinions. You can show a timed export and import, a timed rehearsal that included the application, a tested restore from a target backup, and a before and after comparison of your top SQL statements. If someone asks how long cutover takes, the answer comes from the rehearsal, not from an estimate.

The target should feel boring after the first week. Alerts fire the same way, the backup job finishes on schedule, and the DBA on call can find the logs. Watch a few Oracle specific numbers: redo generation rate, top wait events in AWR, tablespace growth and peak session count. Compare each one with the baseline you captured on the source.

Documentation matters more than usual because the two systems look alike. Write down the connection strings, the target host names, the parameter differences, the options that are missing, and the date after which the source will be retired. A short runbook with the cutover steps, the rollback steps and the people to call is worth more than a long design document.

What to do next

Start with the inventory and the licensing answer, because both are cheap and both change the plan. Then take one small, non critical schema through the full checklist into the target. That pilot will surface the character set issue, the unsupported option or the missing network rule, and it will surface it long before the maintenance window is booked.

If the database is large or the application is tightly coupled, plan a phased approach. Replicate with GoldenGate or Data Guard, run read only tests against the target, and switch over when the numbers hold. Keep the source in shape during the parallel run, since a migration is not a reason to stop patching the system people use today.

For teams that want an independent architecture and a phased plan before committing to a platform, the Cloudverg Discovery and roadmap sprint is a fixed price engagement at $9,500 that runs for two weeks and ends with diagrams, a roadmap and a fixed quote for phase one. Other routes are a direct engagement with Oracle or your cloud provider's migration team, or running the pilot in house with your own DBAs. Any of them work, as long as one person owns the checklist and the rollback decision.

Frequently asked questions