Migrate an on-premises Oracle database to Amazon EC2 by using Oracle Data Pump - AWS Prescriptive Guidance

Migrate an on-premises Oracle database to Amazon EC2 by using Oracle Data Pump

Created by Navakanth Talluri (AWS)

Environment: PoC or pilot

Source: On-premises Oracle database

Target: Oracle database on Amazon EC2

R Type: Rehost

Workload: Oracle

Technologies: Migration; Databases

AWS services: Amazon EC2; AWS Direct Connect


When migrating databases, you must consider factors such as the source and target database engines and versions, migration tools and services, and acceptable downtime periods. If you’re migrating an on-premises Oracle database to Amazon Elastic Compute Cloud (Amazon EC2), you can use Oracle tools, such as Oracle Data Pump and Oracle Recovery Manager (RMAN). For more information about strategies, see Migrating Oracle databases to the AWS Cloud.

Oracle Data Pump helps you extract the logical, consistent backup of the database and restore it to the target EC2 instance. This pattern describes how to migrate an on-premises Oracle database to an EC2 instance by using Oracle Data Pump and the NETWORK_LINK parameter, with minimal downtime. The NETWORK_LINK parameter starts an import through a database link. The Oracle Data Pump Import (impdp) client on the target EC2 instance connects to the source database, retrieves data from it, and writes the data directly to the database on the target instance. There are no backup, or dump, files used in this solution.

Prerequisites and limitations


  • An active AWS account.

  • An on-premises Oracle database that:

    • Isn’t an Oracle Real Application Clusters (RAC) database

    • Isn’t an Oracle Automatic Storage Management (Oracle ASM) database

    • Is in read-write mode.

  • You have created an AWS Direct Connect link between your on-premises data center and AWS. For more information, see Create a connection (Direct Connect documentation).

Product versions

  • Oracle Database 10g release 1 (10.1) and later


Source technology stack

  • A standalone (non-RAC and non-ASM) Oracle database server in an on-premises data center

Target technology stack

  • An Oracle database running on Amazon EC2

Target architecture

The reliability pillar of the AWS Well-Architected Framework recommends creating data backups to help provide high availability and resiliency. For more information, see Architecting for high availability in Best Practices for Running Oracle Database on AWS. This pattern sets up primary and standby databases on EC2 instances by using Oracle Active Data Guard. For high availability, the EC2 instances should be in different Availability Zones. However, the Availability Zones can be in the same AWS Region or in different AWS Regions.

Active Data Guard provides read-only access to a physical standby database and applies redo changes continuously from the primary database. Based on your recovery point objective (RPO) and recovery time objective (RTO), you can choose between synchronous and asynchronous redo transport options.

The following image shows the target architecture if the primary and standby EC2 instances are in different AWS Regions.

Application connecting to the new database on the primary EC2 instance

Data migration architecture

After you have finished setting up the target architecture, you use Oracle Data Pump to migrate the on-premises data and schemas to the primary EC2 instance. During cutover, applications can’t access the on-premises database or the target database. You shut down these applications until they can be connected to the new target database on the primary EC2 instance.

The following image shows the architecture during the data migration. In this sample architecture, the primary and standby EC2 instances are in different AWS Regions.

The source DB connects to the target DB. Applications are disconnected from source and target DBs


AWS services

  • AWS Direct Connect links your internal network to a Direct Connect location over a standard Ethernet fiber-optic cable. With this connection, you can create virtual interfaces directly to public AWS services while bypassing internet service providers in your network path.

  • Amazon Elastic Compute Cloud (Amazon EC2) provides scalable computing capacity in the AWS Cloud. You can launch as many virtual servers as you need and quickly scale them up or down.

Other tools and services

Best practices


TaskDescriptionSkills required

Identify the source hardware configuration for the on-premises host and the kernel parameters.

Validate the on-premises configuration, including storage size, input/output operations per second (IOPS), and CPU. This is important for Oracle licensing, which is based on CPU cores.

DBA, SysAdmin

Create the infrastructure on AWS.

Create the virtual private clouds (VPCs), private subnets, security groups, network access control lists (ACLs), route tables, and internet gateway. For more information, see the following:

DBA, AWS systems administrator

Set up the EC2 instances by using Active Data Guard.

Configure AWS EC2 instances by using an Active Data Guard configuration, as described in the AWS Well-Architected Framework. The version of Oracle Database on the EC2 instance can be different from the on-premises version because this pattern uses logical backups. Note the following:

  • Put the target database in read-write mode.

  • On the target database, provide the Transparent Network Substrate (TNS) detail for the source database.

For more information, see:

DBA, AWS systems administrator
TaskDescriptionSkills required

Create a dblink to the on-premises database from the EC2 instance.

Create a database link (dblink) between the Oracle database on the EC2 instance and the on-premises Oracle database. For more information, see Using Network Link Import to Move Data (Oracle documentation).


Verify the connection between the EC2 instance and the on-premises host.

Use the dblink to confirm that the connection between the EC2 instance and the on-premises database is functioning. For instructions, see CREATE DATABASE LINK (Oracle documentation).


Stop all applications connected to the on-premises database.

After the database downtime is approved, shut down any applications and dependent jobs that connent to your on-premises database. You can do this either from the application directly or from the database by using cron. For more information, see Use the Crontab Utility to Schedule Tasks on Oracle Linux.

DBA, App developer

Schedule the data migration job.

On the target host, use the command impdb to schedule the Data Pump import. This connects the target database to the on-premises host and starts the data migration. For more information, see Data Pump Import and NETWORK_LINK (Oracle documentation).


Validate the data migration.

Data validation is a crucial step. For data validation, you can use custom tools or Oracle tools, such as a combination of dblink and SQL queries.

TaskDescriptionSkills required

Put the source database in read-only mode.

Confirm that the application is shut down and no changes are being made to the source database. Open the source database in read-only mode. This helps you avoid any open transactions. For more information, see ALTER DATABASE in SQL Statements (Oracle documentation).

DBA, DevOps engineer, App developer

Validate the object count and data.

To validate the data and object, use custom tools or Oracle tools, such as a combination of dblink and SQL queries.

DBA, App developer

Connect the applications to the database on the primary EC2 instance.

Change the application’s connection attribute to point to the new database you created on the primary EC2 instance.

DBA, App developer

Validate the application performance.

Start the application. Validate the functionality and performance of the application by using Automated Workload Repository (Oracle documentation).

App developer, DevOps engineer, DBA

Related resources

AWS references

Oracle references