Key Considerations for Database Migration to AWS Cloud - Part 1

Nishant Sharma | 02 Feb 2019 | Newsletter

Customers are migrating critical workloads to benefit the inherent scalability and elasticity of Cloud, powered by high level of automation—which significantly increases business ability to innovate and respond to market conditions.

Moving database to the Cloud is fraught with complexities requiring a planned and purposeful approach. Database comes in all shapes and sizes underpinning application performance and a key criteria to measure migration success. This requires careful consideration of multiple aspects. To keep the discussion focussed this blog will examine aspects of homogenous database migration from on premise to AWS Cloud.

In homogenous migration source and target database are same such as Oracle to Amazon RDS for Oracle; MySQL to Amazon Aurora; MySQL to Amazon RDS for MySQL; or Microsoft SQL Server to Amazon RDS for SQL Server. Customers also have the option to run database on EC2.

The schema structure, data types, and database code are compatible between source and target database and therefore homogenous migration is relatively simple. Customers can use one of the following migration options:

Based on our experience below are few things to bear in mind while migrating database to AWS Cloud.

Compliance: Compliance requirements must take precedence over performance and latency. Depending on the industry and regulatory requirements, you must choose the AWS region carefully to comply with regulations such Payment Card Industry Data Security Standard, Health Insurance Portability and Accountability Act, General Data Protection Regulation which mandates how data must be stored and accessed.

Data privacy being a key mandate for most regulatory requirements, encrypting data at rest and transit is a good practice—including database storage, backup and snapshots must be encrypted. Some compliance may require data transfer through a secure tunnel in which case a secure VPN tunnel between the host and network is required.

Database Licensing: This is a crucial issue in migration and AWS supports the following options:

  1. Bring Your Own License wherein you have already purchased database licence and want to take it to the Cloud. Customers will have to deploy it on EC2 and manage the database themselves.
  2. Subscribe to managed database service such as AWS RDS, AWS Aurora or Document DB in which case you do not pay for licensing separately. The per hour cost comprises licence and infrastructure and management capabilities.

However RDS for Oracle database offers BYOL option in which case customer bears licensing cost.

  1. Customers can use MS SQL on EC2 with AWS provided license.


Choosing the database platform on AWS: Depending on technical compatibility and business objectives, you can choose how you want to run the database—a managed service or host your own database in AWS Cloud.

  1. Managed Database: AWS RDS, Document DB and AWS Aurora are managed services where customer does not worry about scalability, maintenance, patching, replication, back-ups, snapshots and recovery. For example if you are currently using  relational database you can choose AWS RDS; for MySQL and PostGres choose Aurora; for Mongo DB choose Document DB.
  2. Virtual Hosts: Here you run your own virtual instance on EC2 and install database of choice. The advantage being the ability to choose the database engine and version and customer has access to the OS which gives complete configuration control.

Umbrella has migrated very large and complex deployments comprising multiple and varied database to AWS Cloud. We have successfully migrated SQL and NoSQL database running into terabytes of data to homogenous and heterogenous environment using AWS services such as Direct Connect, Data Migration Service and Amazon Snowball to transfer large amounts of data at high speed in a secure manner.

Our expertise have helped migrate data with near zero downtime—continuously replicating changes in the source to the target database to be fully operational during migration. The self-healing capabilities of services we use continuously monitors the source and target database, network connectivity and replication instance to automatically restart in case of interruption.

We will take up migration approaches in the next blog.

If you are considering database migration and want to know more, do reach out to us at or call us at 956 070 0360.




Popular Blogs