With the recent exceptional growth in Public Cloud, more and more enterprises are migrating their Infrastructure, Applications and Databases to Cloud. Database Migration is one of the most critical components of any workload migration and yes, it could be a challenging task due to several reasons:

• A lot of proprietary technology and functionality that’s built into the legacy database technologies and functionalities like stored procedure, custom functions, Oracle RAC etc.

• Historical on-prem databases are all monolithic and humongous servers.

• Incompatibility issues: Both internal- and external-facing applications, that are all relying on the database and might not be compatible with different database platforms.

Oracle Database migration to Google Cloud is one of the prominent use cases that many organizations are adopting and focusing to start their journey.

Migration strategies for Oracle on GCP

In general, there are two types of database migrations:

1. Homogeneous Migration (Lift & Shift/ Re-host, Re-platform)

2. Heterogeneous Migration

Everything starts with an assessment; this is the most critical stage of the engagement. It is important to spend time during assessment analysing the source databases in-order to establish suitable candidates for different type of migrations and approaches

Homogeneous Migration

Rehost

Where you’re retaining the same database engine, but you’re just moving over from on-premises to the cloud. Re-hosting the database on cloud without changing the underline platform (OS) or changes to the app. There are multiple ways to achieve this on Google Cloud:

• Re-hosting the virtualized VM-ware workload on Google Cloud by extending to GCVE (Google Compute VM-Ware Engine).

• Making use of Bare Metal Solution for specialised workloads

• Re-hosting database on GCE (Google Compute Engine)

This approach is very common and brings a lot of benefits, like:

• You already have trained staff that understands the technology and is familiar with the current solution. So, migrating it on cloud would not impact resources — as there’s not as much of a learning curve associated with it and at the same time it accelerates the migration timelines.

• The database engine is still the same — you have fewer application rewrites or for that matter no application changes, which means lower risk and reduced migration timelines.

Bare Metal Solution

To migrate Oracle workloads with specific configurations, Google Cloud offers Bare Metal Solution, where you can simply lift and shift your workloads. Bare Metal Solution provides hardware, hardware support, and integrated billing and support. This infrastructure is connected with a highly resilient interconnect and connects to all native Google Cloud services with less than 2ms latency.

Migrate databases to Google Cloud VMware Engine (GCVE)

There are customers who look to migrate databases from on-premises (Physical or VMware) to Google Cloud VMware Engine (GCVE). Many customers choose this lift-and-shift migration approach as a first step to quickly migrate databases into Google Cloud before beginning database upgrade and modernisation work streams.

What is GCVE?

GCVE is a fully-managed service that lets you run the VMware platform in Google Cloud. This solution includes vSphere, vCenter, vSAN, NSX-T, and corresponding tools. A GCVE VMware environment runs natively on Google Cloud bare metal infrastructure in some Google Cloud locations, and the GCVE service includes all the features required to help consume the VMware platforms efficiently and securely. Each cluster consists of a minimum of three nodes, and provides high availability through vSphere High Availability.

Key points to remember:

• One GCVE private cloud = 1 vCenter + 1 NSX-T Manager + 1 HCX Manager

• GCVE does not allow overlapping CIDR ranges for vSphere or HCX management networks.

• A cluster has to have, at minimum, three nodes.

Database migration tooling for GCVE

A number of tools exist to migrate servers to GCVE, and two common options are listed below.

VMware HCX VMware HCX is used to migrate VMs from your on-premises VMware environment to Google Cloud VMware Engine. GCVE requires that the HCX Connector OVA be downloaded, installed, deployed, and configured both on-premises and on the private cloud. There is a 1:1 correspondence between on-premises vCenters and HCX Connector appliances. For example, if there are 10 datacenters with VMware installations, each vCenter will need a connector installed.

PlateSpin Migrate PlateSpin Migrate is a data center migration tool that decouples the workload infrastructure from its software (operating system, applications, and data) to migrate physical servers to target server platforms like VMware hypervisors. A common use case involves a two-step migration when migrating to GCVE, starting with P2V on-premises and then V2V to GCVE using HCX.

Replatform

Keeping the application unchanged while adopting platforms which are either cloud compatible or help drive additional value while migrating workload to cloud. Keep your core application code and migrate to a new platform to help reduce licensing fees and maintenance costs. For instance,, re-platforming databases running on AIX to Linux

Some other examples include On-prem MS SQL Server / MySQL / PostgreSQL migrations to Cloud SQL. For example, modernize to open source with Cloud SQL for PostgreSQL, which has many similarities to Oracle.

You can also offload data analytics-centric workloads to SQL-compatible data warehousing solutions like BigQuery.

Heterogeneous Migration

Rewrite

The other type of migration is called heterogeneous migration, where you want to port the legacy database engine. Organizations commonly use this in the same vein as Modernization or Digital Transformation. Rewrite your application to take full advantage of cloud-native databases. If your application requires a relational database with global scalability, you can migrate to Cloud Spanner, which provides scalability with an industry-leading high availability of 99.999% SLA.

Reasons to trigger Heterogenous Migrations

• Cost of License and renewal

• With business growth- organizations tend to develop more and more new applications. Therefore, to avail the benefits of cloud like cost savings, lowering TCO (Total Cost of Ownership)

• Reducing your reliance on a particular vendor lock in proprietary technology.

• Adoption of open-source technologies

Although, from a high-level it appears to be a lucrative proposition to migrate off the enterprise database like Oracle to an Open-source database such as PostgreSQL, one could immediately visualize positive impacts such as no periodic renewal cost, freedom to choose an open-source database. However, the following factors must be reviewed while choosing the path forward.

• No two bespoke applications would have the same schema. It is important to understand that unlike lift and shift and re-platform, the issues with heterogeneous conversion are deeper. The database objects and code cannot be migrated as-is. It is important to do a deep schema level analysis before committing.

• Whether there is embedded code or ORM (Object Relational Mapper)

• The knowledge of the business logic is essential in case of application refactoring or Database code re-write.

• Feature mismatch between the source and target database. For example, native packages which are available on source may not have an equivalent on target. This entails finding workarounds for specific problems which are time consuming.

• Downtime availability, while it is not a factor during the code conversion. It may become a critical dependency during the cutover. The choice of tools hence becomes critical.

• The complexity of code and database size are factors that determine the effort required.

• If the application has been developed over a period of time, there is a good possibility that the original application developer is not part of the team anymore and there is legacy code which may have to be rewritten.

• The functional testing although is the primary responsibility of the application team it would require engagement of the database resources. Expect the total time to be spent on the functional and performance testing to be around 50%. These numbers are indicative and may vary greatly depending on the schema and application complexity/requirement.

The choice of platform is critical for the success of migration as different platforms provide different capabilities. The choice of platform would impact the effort where code compatibility is a major issue. The choice of tools depends on the choice of platform and the downtime availability (specifically for a production environment)

The choice of tool for migration is another important factor. There are several tools available both open source and licensed. Both have their own set of advantages, challenges and costs. Knowing when to use which tool is based on the experience of the team. For example, there are situations where you may prefer using an open-source tool like Ora2PG for conversion over a licensed one like Ispirer and vice-versa.

The size of data and the rate of change of data are factors to be considered for critical applications /databases which cannot afford downtime during cutover or require parallel run. Then a CDC (Change Data Capture) based synchronization tool must be considered to facilitate near zero downtime, continuous synchronization, and a possible rollback. There are choices which are cloud native and third-party tools.

The below picture provides a high-level view of steps for Heterogeneous Migration, For e.g. Oracle to Cloud SQL.

Conclusion

Database Migration is a complex process and organizations should decide their roadmap on cloud with full proof planning through in-depth assessment. Both homogeneous and heterogeneous migrations have their own benefits and challenges which must be factored in during the discovery and assessment phase. With careful planning, right strategies, tools, and resources successful migration can be achieved and organizations can gain the real benefit of Google Cloud.