Migrating Away from Oracle (1/3): A Practical Guide to GCP Native Databases

Most Oracle migrations fail long before the first byte of data is moved.

They fail when teams convince themselves that “Oracle on the cloud” is transformation, when it is really just relocation. They fail when licensing costs quietly follow the database into Google Cloud, when PL/SQL becomes an immovable dependency, and when the promise of modernization collapses into a more expensive version of the same architecture.

If you are migrating Oracle to Google Cloud and your plan still involves running Oracle at the end of the journey, then this article is not for you.

This article is about the harder — and more meaningful — path: migrating away from Oracle toward native Google Cloud database engines. Not lift-and-shift. Not re-hosting. Real re-platforming, with all the trade-offs that come with it.

Brief for Executives

Migrating away from Oracle on Google Cloud is possible, but it is neither cheap nor automatic. The primary technical destination for most workloads is AlloyDB for PostgreSQL, with Cloud SQL suitable only for smaller systems and Cloud Spanner reserved for full architectural redesigns. Google provides solid tooling — notably Database Migration Assessment (DMA) and Database Migration Service (DMS) — but these tools surface complexity rather than eliminate it.

The biggest cost drivers are not data volume, but Oracle-specific features such as PL/SQL packages, autonomous transactions, and embedded scheduling or queuing logic. When those features dominate, migration becomes an application refactoring project, not a database exercise. Organizations that succeed approach this as a strategic modernization effort, not a tactical infrastructure move.

Why “Oracle on GCP” Is Not the Goal

Google Cloud provides supported options to run Oracle, including Compute Engine virtual machines and Oracle Bare Metal Solution. These platforms are robust and enterprise‑ready, and for some workloads they are the right answer. However, they do not fundamentally change the nature of the system. Oracle remains Oracle, with the same licensing model, the same operational footprint, and the same dependency on proprietary features.

If your goals include reducing licensing exposure, simplifying database operations, modernizing applications, or avoiding long‑term vendor lock‑in, then running Oracle somewhere else is not a migration strategy. Re‑platforming requires changing the database engine itself, and that is where complexity, tooling, and realism become critical.

Choosing the Right Google Cloud Target

Before any tools are deployed or assessments are run, the most important decision is the choice of the destination database. In practice, there are only a few realistic targets when migrating away from Oracle on Google Cloud.

For the majority of transactional Oracle workloads, AlloyDB for PostgreSQL is the most natural replacement. AlloyDB is Google’s enterprise PostgreSQL offering, designed for high throughput, low latency, and large transactional systems. It preserves PostgreSQL compatibility while delivering performance characteristics that are closer to what Oracle customers expect. For most serious Oracle re‑platforming efforts, AlloyDB becomes the default target.

Cloud SQL for PostgreSQL occupies a different space. It is simpler, cheaper, and easier to operate, but it is not designed for large or highly concurrent workloads. Cloud SQL can be an excellent destination for smaller Oracle databases, departmental systems, or workloads with limited procedural logic, but it is rarely suitable for a full Oracle estate.

Cloud Spanner is sometimes mentioned in Oracle migration discussions, but it should be approached with caution. Spanner is not a drop‑in replacement for a traditional relational database. Migrating from Oracle to Spanner usually involves schema redesign, changes to transaction models, and application rewrites. When Spanner is chosen, it is typically because global scalability or horizontal consistency requirements already justify a major architectural change.

Assessing Reality with Database Migration Assessment

One of the most common causes of Oracle migration failure is skipping the assessment phase. Assumptions are made based on schema size or row counts, while the real complexity is hidden in procedural logic and Oracle‑specific features.

Google’s Database Migration Assessment, commonly referred to as DMA, exists to make that complexity visible. DMA connects to the Oracle database in read‑only mode and analyzes schemas, objects, SQL constructs, and PL/SQL usage. The result is a detailed compatibility report that highlights unsupported features, estimates migration difficulty, and helps determine which Google Cloud database engine is the most appropriate target.

It is important to understand what DMA is and what it is not. DMA does not migrate schemas, convert code, or guarantee success. It is a diagnostic tool designed to surface risk. When DMA reports heavy usage of packages, autonomous transactions, or Oracle‑specific scheduling and queuing features, those findings should be taken seriously. In practice, DMA is rarely pessimistic without reason.

Schema and Code Conversion with Database Migration Service

Once assessment is complete and a target has been chosen, the migration effort moves into conversion. This phase is handled using Google’s Database Migration Service, or DMS. Beyond data replication, DMS provides Conversion Workspaces that support schema transformation and code translation.

Conversion Workspaces analyze Oracle schemas and generate PostgreSQL‑compatible equivalents. SQL statements are rewritten, objects are mapped, and procedural code is translated where possible. This is also where Gemini AI becomes visible. Gemini can explain legacy PL/SQL logic, suggest PostgreSQL alternatives, and assist in converting procedures, functions, and triggers.

Gemini is particularly effective as a comprehension tool. It helps teams understand what the database code is doing before attempting to rewrite it. However, it is not a substitute for refactoring. Automated translation can reduce effort, but it cannot resolve fundamental differences between Oracle and PostgreSQL.

The Reality of Oracle Packages

Oracle packages are often the most painful aspect of migration. They provide encapsulation, shared state, initialization logic, and a clear separation between public and private code. PostgreSQL has no direct equivalent.

During migration, package procedures typically become standalone PostgreSQL functions. Naming conventions or schemas are used to group related logic, but this provides only namespacing, not true encapsulation. Package‑level state must be re‑implemented using tables, application logic, or carefully managed session context, each of which comes with trade‑offs.

This is a critical distinction. PostgreSQL schemas are not packages, and treating them as such leads to fragile designs. Successful migrations acknowledge this difference and redesign accordingly.

Data Type Mapping and Hidden Risks

Most basic data types map cleanly from Oracle to PostgreSQL, and DMS handles these conversions automatically. Character data becomes VARCHAR or TEXT, large objects become TEXT or BYTEA, and numeric types are mapped to PostgreSQL’s NUMERIC family.

Problems arise in the details. Oracle’s unbounded NUMBER type often maps to NUMERIC without precision, which can introduce performance issues and inefficient indexing. Oracle’s DATE type includes time information, while PostgreSQL’s DATE does not, making TIMESTAMP a more appropriate target in many cases.

DMS identifies these discrepancies, but the final decisions must be made by engineers who understand the workload. Automation highlights issues; it does not resolve them.

Migrating Data with Minimal Downtime

After schemas and code are addressed, data migration becomes the focus. DMS supports both one‑time bulk loads and continuous replication, enabling low‑downtime migrations. A typical approach involves an initial load followed by ongoing synchronization, allowing applications to continue running on Oracle until a controlled cutover window.

Validation is essential throughout this process. Row counts, checksums, and business‑level validations help ensure that the migrated data behaves as expected. Cutting over without verification is a common and costly mistake.

Oracle Features That Increase Migration Cost

Certain Oracle features dramatically increase migration complexity. Stateful packages require architectural changes. Autonomous transactions have no direct PostgreSQL equivalent and often force redesigns around transaction handling. Oracle’s scheduling and queuing mechanisms typically migrate to external services such as Cloud Scheduler, workflow engines, or messaging platforms.

These features are not merely technical inconveniences; they reflect design decisions that tie application behavior tightly to the database. When they appear frequently, migration becomes as much an application project as a database project.

When Migrating Away from Oracle Is the Wrong Choice

Not every Oracle system should be migrated. Enterprise applications tightly coupled to Oracle, vendor products that rely on proprietary features, or databases where PL/SQL effectively is the application may not justify the effort. In such cases, running Oracle on supported Google Cloud infrastructure can be the more pragmatic decision.

Re‑platforming is a business decision informed by cost, risk, and long‑term strategy, not simply a technical preference.

Final Thoughts

Migrating away from Oracle on Google Cloud is entirely achievable, but it is not trivial. Success depends on honest assessment, careful target selection, and a willingness to refactor where necessary. Tools like DMA and DMS provide strong foundations, but they do not eliminate the need for architectural decisions.

When executed well, the payoff is significant: lower operating costs, simpler systems, and a database platform aligned with modern cloud‑native practices. Most importantly, it allows organizations to stop paying a premium for architectural choices made decades ago.

The most important step is the first one. Start with assessment, not assumptions.