Almost all IT decision-makers today are confronted with the task of migrating workloads, and thus also databases, to the cloud in order to make their IT more efficient and to advance their transformation. However, migration planning always includes the decision as to what exactly is to be done with specific workloads: Simply move them to the cloud as they are? Modernise? Or perhaps just replace them?
At the same time, more and more CIOs are considering the use of open source software in order to avoid high licence fees, financial risks through audits, or vendor lock-in. Frequently, this also applies to users of Oracle Database. For them, their cloud journey is often also a reason to look for open source alternatives to Oracle. In this article, we talk about the different paths open to Oracle users for a cloud migration and also ask about options beyond Oracle – for example, PostgreSQL.
If you as an Oracle user want to move your database to the cloud, a number of options are open to you. As with any cloud migration, there are generally the familiar migration strategies of the "7 Rs" (see figure). We explain these strategies using AWS as an example, the market leader in public cloud services:
Rehost (Lift and Shift): Move your local Oracle database to a virtual machine (VM) in the cloud without changes, for example to an EC2 instance (Amazon Elastic Compute Cloud).
Relocate (Lift and Shift at hypervisor level): If you are using a VMware virtualised Oracle database, you can move it to VMware Cloud on AWS.
Replatform (Lift and Reshape): Do you want to move your local Oracle database to the AWS cloud without major changes and still benefit from some cloud advantages? For this you can use Amazon Relational Database Service (RDS) for Oracle (Platform as a Service, PaaS).
Repurchase (Drop and Shop): It often makes sense to purchase a new solution that has advantages over Oracle and possibly already runs in the cloud (Software-as-a-Service, SaaS) and only migrate your existing data from Oracle to the new database.
Refactor/Rearchitect: This strategy usually means a new development or revision with substantial changes to architecture and code. In the case of Oracle cloud migration, however, the move to a different architecture is preferable in order to take advantage of cloud-native functions, e.g. with Amazon Aurora.
In addition to these five strategies, there are two that we list for the sake of completeness, but which do not actually involve migration:
Retain: Of course, there is always the option of continuing to use the proven on-premises environment for selected workloads (e.g. to postpone complex optimisations to a later time).
Retire: If an application or service is no longer absolutely needed, it does not have to be migrated – you can simply discard it.
Lift and Shift and Replatform are the most frequently used options, at least in our customer projects, followed by Retire and the switch to SaaS (Repurchase). For about ten per cent of migrated workloads, users opt for modernisation in the narrower sense (Refactor/Rearchitect) – in those cases where cost and benefit are in the most favourable ratio. For many Oracle users, a heterogeneous database migration, i.e. the change to another database management system (DBMS), is also an attractive option.
Databases are mission-critical systems; a migration needs to be carefully considered. But there are a few reasons why many Oracle Database users would like to switch to another DBMS. One of the most important: the costs. In addition to high licence expenses, with many options only available at extra cost, there are mandatory support costs (which are even due for unused licences). In addition, Oracle keeps changing its licence conditions, mostly to the customer's disadvantage.
This also creates financial and legal risks. Oracle reserves the right for licence audits and regularly checks whether users have licensed all workloads in accordance with the contract. This almost always results in additional costs – very few of those audited are fully compliant. Oracle devotes considerable resources and creativity on detecting licence violations and is not squeamish when it comes to the legal enforcement of alleged claims. The law firm Tactical Law Group, which specialises in intellectual property and licensing law, runs its own blog on the subject of Oracle audits and discusses numerous lawsuits filed by the software manufacturer, including 11 proceedings in 2021 alone.
Flexibility also suffers under the pricing policy of the provider, who has perfected the art of "vendor lock-in". For example, anyone who does not use a "Named-User-Plus" licence is supposed to pay licence costs for all processors that they could theoretically use for Oracle workloads (soft partitioning). With VMware's virtualisation technology, this can (as of vCenter Server 6.0) affect the entire IT infrastructure, because resources can be used via "live migration" across instances, regardless of whether Oracle is installed at all on the node currently being used. Users who use Oracle virtualisation do not have this problem.
Particularly those who want to move their Oracle database to the public cloud will feel the restrictions. Oracle wants to keep customers in its own Oracle Cloud Infrastructure and has made its licensing conditions accordingly unfavourable for third-party providers (more information). In addition, there is the risk of unexpected additional costs because it is very easy for users in the public cloud, especially in Amazon Web Services (AWS), to activate additional database functions.
Those who want to use the opportunity of AWS migration to switch to a new database in the AWS cloud, i.e. aim for a heterogeneous database migration, can choose in particular between the Repurchase and Refactor/Rearchitect migration strategies:
Repurchase here usually means switching from Oracle to another relational database, usually an open source database (e.g. PostgreSQL, MySQL, MariaDB).
Refactor/Rearchitect boils down to a move to a cloud-native AWS database service: either as a relational database (e.g. Amazon Aurora), as a NoSQL database (Amazon DynamoDB) or as a data warehouse (Amazon Redshift).
Organisations often decide to switch from Oracle to PostgreSQL – a reasonable choice due to the relative technical proximity of both database technologies. PostgreSQL, or Postgres for short, is a lean, modular and powerful database management system that has been under development since the 1980s, and open source since 1996. Like Oracle, it supports object-relational data, triggers and procedures and is already used in thousands of business-critical applications.
On AWS, PostgreSQL is possible with both of the aforementioned R options: you can install PostgreSQL on an EC2 instance (Repurchase) or use the fully managed database services of AWS (Refactor/Rearchitect): either PostgreSQL on Amazon RDS, or Amazon Aurora PostgreSQL for higher demands on performance, scalability and availability.
Installing PostgreSQL on Amazon EC2 is the cheapest option. You install and manage your database on a VM in Amazon EC2, have access to all configuration options including the server operating system, but have to take care of updates and functions such as high availability, backups or streaming replication (for better scalability) yourself.
PostgreSQL on Amazon RDS: Amazon RDS makes it easy to set up, run and scale relational databases in the AWS Cloud (EC2) and relieves users of most administration tasks. With features such as automated backups, replication for scaling as well as multi-AZ provisioning (synchronised across different Availability Zones) and automatic failover for high availability and disaster recovery, it is ideally suited for low-maintenance production environments.
Amazon Aurora PostgreSQL: Amazon Aurora PostgreSQL uses a higher-performance storage system: instead of utilising Amazon Elastic Block Storage (EBS) volumes for each database instance, it uses dynamic storage, which significantly speeds up replication, failover, recovery and highly parallel workloads. It also offers some additional features (including database cloning, serverless, cross-region databases), but fewer small instances. For those switching from commercial database engines such as Oracle, Aurora PostgreSQL provides the same performance at a lower price, according to AWS. For guidance on choosing the right service option for you, see this AWS post: Is Amazon RDS for PostgreSQL or Amazon Aurora PostgreSQL the better choice for me?
There are a number of tools available to support the migration of your Oracle data to PostgreSQL, such as the AWS Database Migration Service (AWS DMS). https://docs.aws.amazon.com/de_de/dms/latest/userguide/Welcome.htmlAWS DMS is a managed migration and replication service from AWS that allows you to move database and analytics workloads to AWS quickly, with minimal downtime and no data loss, according to AWS.
Choose an experienced partner for your cloud transformation. Find out how SoftwareOne can help you start on a strong cloud foundation and accelerate your results.
Choose an experienced partner for your cloud transformation. Find out how SoftwareOne can help you start on a strong cloud foundation and accelerate your results.
