What Is Involved in Migrating Database Workloads to the Cloud?

Contributed by Ken Rugg

Picking up on our last post on moving databases to the cloud, now, let’s look at what is involved with migrating your database workload to the cloud.

To migrate to a different database, you may need to change the schema to accommodate the new database. In moving between different relational databases, this is not generally a complex process, since most of the data types will be common between them and many that are not will have simple mappings. In some cases, database vendors simplify this task even further by providing a data dictionary, which is compatible with another leading vendor, for example, EDB Postgres does this with Oracle.

However, when you move beyond relational database types, for example to a NoSQL system, this mapping can become significantly more challenging and may require a full application rewrite.

You may not even need a full-blown schema migration tool if you’re only using standard SQL. As one example, a simple text editor would likely be sufficient to replace any Oracle-specific types with PostgreSQL equivalents.

The AWS Schema Conversion Tool (SCT) can convert the database schema of your source database into a format compatible with a target Amazon RDS instance. And, the Microsoft Database Migration Service provides help for migrations specifically targeted to SQL Azure.

Additionally, the EDB Migration Portal, currently available in beta, is now available to rapidly assess an existing database for compatibility with EDB Postgres Advanced Server and streamline the remediation steps necessary to achieve a successful conversion. It analyzes and converts definitions, tables, views, stored procedures, and indexes. You can view an 8-minute video demo about the EDB Migration Portal to learn more or sign up for the beta program.

Once the schema has been mapped, data can be transformed and transported into the new data store. Automated migration tools can be a huge timesaver here and include the EDB Replication Server (EPRS), along with HVR Data Replication, Attunity Replicate, Oracle GoldenGate. Also, for extremely large data sets that require batch mode operations, the options include Informatica and Talend. Specific to AWS, there is the Amazon Database Migration Service (DMS) for streaming data into an AWS-based data store, as well as offline tools like Snowball for petabyte-scale data sets.

The process of migrating application logic tends to be overlooked because it’s generally not difficult if the migration is between relational databases and the application uses only standard SQL interfaces to access and manipulate the data. However, if an application was built to take advantage of non-standard proprietary features in PL/SQL, that can represent challenges.

EnterpriseDB provides database compatibility for Oracle including PL/SQL execution, OCI and Pro*C compatible connectors, and numerous other features. The EDB Postgres Platform provides compatibility with native PL/SQL, the programming language that runs in Oracle database products, and includes automated migration tools to help save time and minimize the risks rewriting database code that may have taken thousands of man-hours to perfect and has been running without error for years.

While EDB Postgres eliminates nearly any change to native Oracle PL/SQL, the EDB Postgres Migration Portal also understands PL/SQL, Oracle specific packages like AQ, etc. and how to handle any conversion that may be necessary to move it to EDB Postgres. 

Lastly, moving to a NoSQL database likely means a full rewrite of the code that interacts with the database – much the same scenario as with the schema.

Once the schema, data, and application are migrated, you’ll want to run a thorough set of tests to ensure that the application behaves in the same way it did before the move. To meet users’ expectations, test the performance, availability, scalability, network speed, along with security.

Moving database workloads to the cloud is a worthwhile effort as part of modernizing your architecture and being better prepared for your future. EnterpriseDB has lots of experience in this from identifying the applications and databases that are candidates to move to the cloud, then conducting assessments, and finally tuning workloads and databases for optimum performance in the cloud. We’ve created this guide, Moving Oracle Workloads to the Cloud, with more information on this topic.