How Do I Migrate 100+ Oracle Databases to PostgreSQL?

Migrating one Oracle database to PostgreSQL is a project. Migrating over a hundred is a program — and treating it like a single monolithic migration project is the most common way these efforts stall or blow their budget. The right approach starts with classification, not conversion.

This post walks through how a real enterprise migration effort — 110 Oracle databases at a global manufacturing organization — was actually scoped, including the tooling model, the complexity triage system, and the specific technical and commercial questions that had to be answered before a single database moved.

Start with classification, not conversion. Before touching a single database, sort your estate into complexity tiers based on how much Oracle-specific functionality each database actually uses.

The classification framework used in a real 110-database migration split databases into a green/yellow/red system:

• Green: Databases with minimal Oracle-specific dependencies — straightforward data types, no or few stored procedures — that automated conversion tooling can handle with minimal manual intervention. This tier moves fast and can often be quoted at a fixed cost per database.
• Yellow: Databases where tooling can handle the bulk of the conversion — often cited around 95% — but require manual conversion work for specific elements like stored procedures that don't map cleanly to PostgreSQL's PL/pgSQL.
• Red: Databases with extensive Oracle-specific functionality — heavy use of stored procedures, Oracle-specific data types, or proprietary functions — that require substantial manual remediation and expert involvement, not just tooling.

As one migration consultant framed the distinction directly during scoping: "For the green ones, this makes sense — fixed cost totally makes sense. For the yellow and red, the expectation would be that we would come in with resources, probably per project, to help remediate — because this is more complex than tooling can manage."

Practical first step: run an inventory and automated classification pass across your full database estate before committing to a timeline or budget for the whole program. You cannot accurately estimate cost or duration for 110 databases until you know how many fall into each tier.

A complete Oracle-to-PostgreSQL migration toolset needs to cover the full lifecycle, not just schema conversion. In a real scoping conversation, the requirement was described explicitly: "We are expecting the vendor to come up with all the toolings that you have in your belt — evaluator, planner, migrator, conversion, transformers, verification, whatever you want to call it."

The stages that matter:

1. Evaluator — connects to the source Oracle database and analyzes what's actually being used: data types, stored procedures, triggers, Oracle-specific SQL syntax
2. Planner — turns the evaluation into a migration strategy specific to that database's complexity profile
3. Migrator/Transformer — performs the actual schema and data conversion, including code transformation for stored procedures where automatable
4. Verification — confirms the migrated database actually works: application connectivity, unit tests, integration tests, and regression tests to catch severity-level bugs before cutover

The verification stage in particular should not be skipped or treated as optional. The real migration plan explicitly included updating application connection strings, confirming the application starts cleanly against the new PostgreSQL instance, and then running the full application test suite — unit, integration, and regression — specifically to catch any severity bugs introduced by the conversion before it's considered complete.

Yes — and this is standard practice for migrations at this scale, not an optional extra step. A proof-of-concept serves a specific purpose beyond technical validation: it builds internal confidence with the teams that will actually operate PostgreSQL going forward.

In the real case referenced throughout this post, the organization was explicit about why the PoC mattered: their DBA, middleware, and application teams had never used PostgreSQL in a live production environment. The PoC wasn't just testing whether the migration tooling worked — it was testing whether the organization's own teams could develop the confidence level needed to operate PostgreSQL at scale. As it was put directly: "After this PoC, we really want to go no-go if their confidence level is really low... if they feel comfortable, I want to continue on my first strategy."

What a PoC should validate:

• Does your T-shirt-size complexity estimation (green/yellow/red) actually hold up against 5-10 real databases, or is the actual complexity higher than assumed?
• Can your internal team operate the resulting PostgreSQL databases without heavy ongoing vendor dependency, if that's your goal?
• Does the toolset's stored procedure conversion handle your organization's actual patterns, not just generic test cases?

This is worth deciding deliberately rather than defaulting to whatever your Oracle databases currently run on. A real migration case specifically wanted to move away from VM-based PostgreSQL toward Kubernetes-based, self-service deployment — driven by the observation that VM-based deployment lacked full automation for provisioning new databases, while a Kubernetes operator model would let developers request a database and have it automatically provisioned on an existing cluster.

Reasons to consider Kubernetes for PostgreSQL specifically:

• You already have Kubernetes clusters running elsewhere in your infrastructure and want consistent operational tooling
• Self-service database provisioning is a goal — developers requesting a database without a manual DBA provisioning step
• You're migrating away from Oracle in part because of operational overhead, and want the new platform to reduce that overhead structurally, not just replace one manual VM process with another

Reasons to stay on VMs:

• Your team's operational expertise is VM-centric and a Kubernetes operator model adds a new skill requirement mid-migration
• Your PostgreSQL workloads have specific storage or performance requirements better served by dedicated VM infrastructure

Whichever you choose, use the standard, publicly-available PostgreSQL Kubernetes operator where possible rather than a proprietary one — this avoids passing additional licensing costs through to your organization and keeps you portable across cloud and on-prem environments.

This depends entirely on your organization's goals and should be decided explicitly, not left ambiguous. In the real case referenced here, the organization was clear about wanting to avoid vendor lock-in on the process, even while evaluating vendor tooling: "We don't want an external company to drive the story... to not inflate the budget of migration."

Two reasonable models exist:

Tool licensing with internal execution. The vendor provides tooling (evaluator, migrator, conversion toolset) for a fixed or tiered fee, and your internal team drives the actual conversion work using that tooling. This preserves internal ownership of the migration timeline and reduces ongoing vendor dependency.

Vendor-driven migration services. The vendor's team executes the migration directly, particularly for yellow and red complexity databases where manual remediation requires deep PostgreSQL/Oracle conversion expertise your internal team may not have. This is typically resourced per-project rather than as a flat tool license.

Most large migrations end up using both models simultaneously: internal teams handling green-tier databases with licensed tooling, and vendor expert resources engaged specifically for yellow and red tier remediation.

This should be planned as part of the same engagement, not treated as a separate future problem. A real migration scoping conversation included explicit questions about post-migration support: whether the vendor could commit to technical and security patching for specific PostgreSQL versions if the organization needed to remain on a particular release, and whether that included support for major version upgrades — not just the database engine, but the downstream application impact of those upgrades.

The distinction that matters here, stated directly during that scoping: patching commitments for PostgreSQL itself are one thing, but "the way it ripples through your enterprise is usually a separate offering" — meaning the vendor can commit to timely PostgreSQL security patches, but the impact assessment and remediation for how those patches affect your specific applications is typically a distinct, scoped engagement rather than bundled automatically into basic patch support.

1. Inventory your full database estate and run (or commission) an automated complexity classification pass
2. Decide your target platform — VM or Kubernetes — based on your operational goals, not just migration convenience
3. Scope a proof-of-concept covering a representative sample across green, yellow, and red tiers
4. Decide your tooling/services model — licensed tooling with internal execution, vendor-driven services, or a hybrid split by complexity tier
5. Plan post-migration patching and support as part of the same engagement, including how major version upgrades will be handled downstream

Planning a large-scale Oracle to PostgreSQL migration? AceMQ provides PostgreSQL support and migration engineering for Oracle-exit projects. Talk to an AceMQ engineer to discuss classification, tooling, and a proof-of-concept scope for your specific database estate.

• PostgreSQL Consulting & Support
• AceMQ Support Options
• RabbitMQ Migration Services
• AceMQ Home