< Back to blog home Fujitsu PostgreSQL blog

Oracle data migration tools: What enterprises should consider

Fujitsu | September 3, 2026

Navigate Oracle migration tools, uncover their limitations, and choose the right combination for a smoother, lower-risk move

The main categories of Oracle data migration tools

Oracle data migration tooling falls into five broad categories, but most real migrations end up using tools from more than one category. The question you need to answer is which combination covers the specific path from your current Oracle environment to your target.

The answer depends entirely on the workload being moved. This is exactly what assessment and discovery tools are built to establish before any other tool gets chosen.

Here's what each category is actually built to do:

Assessment and discovery tools: Quantifying effort before committing

Assessment and discovery tools catalog the existing estate, score compatibility against a target platform, and estimate conversion effort before a migration strategy is locked in. That usually means scoring things like schema complexity, the volume of PL/SQL or other custom code, and how many objects have no direct equivalent on the target platform.

Oracle's own Cloud Premigration Advisor Tool (CPAT) serves this role for Oracle-to-Oracle-cloud paths. For heterogeneous migrations, such as Oracle to PostgreSQL, PostgreSQL vendors offer comparable assessment tooling that estimates the effort of moving a given Oracle environment to enterprise PostgreSQL.

This step produces compatibility findings, an effort estimate, and a dependency map, and it helps identify data integrity risks before they surface during migration. Every later tool choice depends on that output, and choosing a conversion tool or a replication platform before this step is where migrations lose time later.

Oracle-native tools: Data Pump, GoldenGate, and zero downtime migration

Oracle's own stack is very capable. But the question isn’t whether these tools work, but if they're solving the problem each particular migration at hand has. They're strongest within the Oracle ecosystem and toward Oracle targets. They solve the data-movement problem well, but not on their own.

Data Pump and RMAN for planned-window moves

Data Pump and Recovery Manager (RMAN) handle logical and physical data movement respectively, and both are well suited to:

• Oracle-to-Oracle migration
• Version upgrades
• Environment refreshes
• Development or test environment moves within a planned downtime window

Their limitations show up outside that scope. Neither tool addresses heterogeneous migration to a non-Oracle database, application-level remediation, or optimization for a different target platform's architecture.

GoldenGate for real-time replication

Oracle GoldenGate provides real-time, log-based replication and can support near-zero-downtime cutovers. It's a capable tool, but it comes with real costs of its own:

• Requires specialized expertise to configure and operate correctly
• Adds its own licensing considerations on top of the source database license
• Doesn't solve schema or code conversion

GoldenGate moves data continuously, as it assumes compatible schemas already exist on both ends.

Zero Downtime Migration for automated cutover workflows

Zero Downtime Migration (ZDM) is Oracle's free, no-cost automation layer that orchestrates Data Pump, RMAN, GoldenGate, and Data Guard into a single managed workflow, built on Oracle's Maximum Availability Architecture.

Oracle’s release of ZDM 26.1 in April 2026 is the latest version of its migration automation tool. It's a strong fit for Oracle Cloud paths and Oracle-to-Oracle modernization, moving an on-premises Oracle database to Oracle Cloud Infrastructure (OCI) or Exadata, for example. It is not built for Oracle-to-PostgreSQL database transformations: ZDM automates cutover, but it doesn't perform cross-engine schema conversion.

Schema and code conversion tools for heterogeneous migrations

For Oracle-to-PostgreSQL and other cross-engine paths, schema and code conversion is its own discipline. Ora2Pg is the established open-source option. It's a free, actively maintained tool that connects directly to an Oracle database, extracts schema and data, and generates PL/pgSQL-compatible scripts, including a built-in assessment mode for estimating conversion difficulty before committing.

Cloud vendors offer their own conversion tooling as well. AWS DMS Schema Conversion, built on the AWS Schema Conversion Tool engine, now includes generative-AI-assisted conversion for complex objects like stored procedures and triggers, and it can automatically convert up to 90% of complex database objects. Google Cloud's Database Migration Service offers a comparable conversion workspace for Oracle-to-PostgreSQL paths, with Gemini-assisted suggestions for objects that don't convert automatically.

What all of these realistically achieve is similar. Automated conversion handles the bulk of standard schema objects and a meaningful share of PL/SQL, but manual remediation is always required where a source database uses proprietary features with no direct equivalent on the target. This is where migration effort estimates most often go wrong by treating "90% automated" as "90% done," when the remaining share is usually the most complex code in the system.

Data movement and replication platforms: Batch vs. continuous

Once schema and code are addressed, moving the data itself comes down to two approaches: batch movement or continuous replication. Choosing between them should depend on database size, write volume, downtime tolerance, and data consistency requirements, not on which vendor built the tool.

Data consistency requirements cover things like transaction volume, how much sync lag the business can tolerate, and how strict the consistency guarantees need to be.

Batch movement for planned-window migrations

A full export-and-load approach, whether via native utilities or a conversion tool's built-in data export, works well for smaller databases or migrations with an acceptable downtime window. It's simpler to validate and troubleshoot than continuous replication, at the cost of requiring that window.

Change data capture and logical replication for near-zero downtime

For larger databases or workloads that can't tolerate a maintenance window, change data capture (CDC) and logical replication tools keep the target database synchronized continuously, with cutover reduced to a brief switchover once the source and target are caught up. This approach handles higher write volumes and tighter consistency requirements, but it demands more operational sophistication to configure, monitor, and validate correctly.

What Oracle data migration tools don't cover

No single category of tool owns the full migration. Tools move schema and data, but they don't own application dependency remediation, testing and validation strategy, cutover planning with rollback criteria, or post-migration operations.

Choosing tools without accounting for these gaps is a common reason migrations run longer than planned, in four areas specifically:

• Business dependencies
  These are applications, integrations, and reporting layers that reference the database in ways a schema conversion tool can't see or account for.
• Technical validation
  This covers performance under real workload, security posture on the target platform, and functional compatibility, and it includes data validation itself, using row counts, checksums, and business-rule checks to confirm migrated data actually matches the source. Most movement tools only partially automate this step.
• Operational readiness
  This includes monitoring, backup and recovery procedures, high availability configuration, and a support model for the new platform, none of which a migration tool sets up for you.
• Change management
  Change management covers user acceptance testing, updated documentation, and training for the teams who'll operate and build against the new environment day to day. Teams moving from Oracle to PostgreSQL for the first time often underestimate this category specifically.

Structured migration services carry these gaps rather than leaving them to the migration team to absorb alongside the tooling.

How to choose: Selection criteria that actually decide it

Before selecting tools, it helps to check the decision against a short list rather than a single factor like downtime:

• Source and target compatibility
  Homogeneous (Oracle-to-Oracle) or heterogeneous (Oracle-to-PostgreSQL)?
• Downtime tolerance
  Is a planned window acceptable, or does the business need near-zero downtime?
• Database size and write volume
  Does batch movement fit, or is continuous replication necessary?
• Data consistency requirements
  What is the transaction volume and acceptable sync lag, and how strict consistency guarantees need to be?
• In-house expertise
  Does the team have the skills to operate the tools being considered, or is that a gap to plan for?
• Licensing cost of the tooling itself
  What are the licensing costs, separate from the cost of the source or target database?
• Coverage
  Does this tool span assessment through validation or only movement?

How Fujitsu fits across the Oracle migration toolchain

Fujitsu's role maps to these tool categories rather than replacing them. For assessment, Fujitsu's Migration Portal estimates the effort of moving an Oracle environment to enterprise PostgreSQL before any tooling decision is made. This applies whether the target is community PostgreSQL or Fujitsu Enterprise Postgres specifically, and Fujitsu's migration support isn't limited to its own distribution.

As a target platform, Fujitsu Enterprise Postgres is 100% PostgreSQL-compatible, with built-in transparent data encryption, data masking, and dedicated audit logging, backed by 24/7 global support with defined SLAs.

Tooling alone doesn't cover certain gaps like application dependency remediation, validation strategy, cutover and rollback planning, or post-migration operations. Fujitsu's Migration Assessment and Data Migration services pair the tooling decisions above with a methodology that closes those gaps, owning the outcome end to end rather than handing back an incomplete migration once the data has moved.

To illustrate the potential benefits of such a pairing, a global superannuation platform ran a three-day architecture review followed by a four-day migration assessment. By doing so, it was able to move off Oracle over a single weekend, saving millions in licensing costs going forward. However, every migration's timeline depends on its own scope and complexity, and it’s best to follow a set sequence—assess first, then match tooling and methodology to what the assessment finds.

Frequently asked questions about Oracle data migration tools

Before committing to a toolchain, ask Fujitsu's specialists for a migration assessment that maps your Oracle environment's compatibility and effort, so the tools you pick match the migration you actually have.