How to Plan an Oracle Database Migration That Lands on Schedule

Two numbers explain why so many Oracle projects are in motion right now. In the 2025 Stack Overflow Developer Survey, 55.6% of developers reported working with PostgreSQL against 10.6% for Oracle — a five-to-one gap in the talent pool you hire from.

Oracle's own cloud is growing hard at the same time. The company's fiscal 2026 results put fourth-quarter cloud infrastructure revenue at $5.8 billion, up 93% year over year.

Both numbers point at the same work. Some teams are moving off Oracle to cut licensing and hire more easily. Others are moving Oracle workloads into Oracle Cloud Infrastructure or onto a managed service. Either way, someone has to convert the schema, the PL/SQL and the data without breaking the applications sitting on top.

This guide covers how that goes in practice: picking the target, sizing the code, the steps in order, and what to check before you promise a date.

Decide Which Kind of Migration You're Running

Before anything else, name the direction. The two cases need different plans and different budgets.

• A homogeneous migration keeps Oracle as the engine. You're moving Oracle 12c to 19c, shifting an instance from one server to another, or lifting an on-premises database into a cloud VM or a managed Oracle service. The SQL comes along unchanged. Risk sits in downtime, data volume and cutover sequencing, and Oracle's own utilities handle most of the mechanics.
• A heterogeneous migration changes the engine: Oracle to PostgreSQL, to Azure SQL Database, to MySQL, to Aurora, to DB2. Now the SQL is the project. Every package, every CONNECT BY query, every autonomous transaction has to come out the other side behaving the same way. Cross-platform Oracle migrations fail on code, not on data.

Most of what follows applies to the second case, because that's where the effort hides. If you’re looking for the pre-migration assessment framework applied across any target platform, our migration readiness assessment guide sets it out stage by stage.

Where Oracle Databases Usually Go

There's no single easiest target. There's a target that fits your code, your team and your licensing position.

• PostgreSQL is the most common destination and the closest match in capability. Procedural code, packages, triggers and sequences all have homes in PL/pgSQL. An Oracle to PostgreSQL migration converts 70–80% of code out of the box, and up to 90% once conversion rules are tuned for your dialect.
• Azure SQL Database suits shops already standardized on Microsoft. T-SQL covers most Oracle procedural patterns, and the managed service removes patching work. We keep a dedicated path for Oracle to Azure SQL because the data type and package differences are predictable enough to automate heavily.
• Aurora is the AWS equivalent for teams who want PostgreSQL semantics with Aurora's storage and replication layer underneath. Oracle to Aurora PostgreSQL follows the same conversion rules as standard PostgreSQL, so the code estimate carries over.
• Amazon RDS is the simpler landing spot — managed infrastructure without re-architecting anything. Our Amazon RDS migration path handles on-premises Oracle moving to RDS for PostgreSQL or RDS for MySQL.
• MySQL works when the application does most of the thinking and the database mostly stores rows. Oracle to MySQL migration is the cheapest route off Oracle when there isn't much procedural code to carry across. OneEmpower in Vietnam took that route with two Oracle instances. Their country head said the Ispirer’s conversion tool "helped us to significantly reduce manual effort and shorten the timeline with high accuracy" — the full note sits on their testimonial page.
• SQL Server remains a frequent target for Windows-centric estates. Package-to-schema mapping, ROWID handling and hierarchy rewrites are covered in our Oracle to SQL Server guide.
• DB2 comes up where licensing is the whole motivation. Worth deciding first whether you need a full move or just a link between the two systems, which we weighed in connect or migrate.
• Oracle Cloud Infrastructure is the option that keeps your SQL. If the goal is leaving the datacenter rather than leaving Oracle, migration to Oracle Cloud skips the conversion problem and turns the project into an infrastructure and cutover exercise.
• Teams sometimes move the other way, consolidating onto Oracle from DB2 or Informix. Our DB2 to Oracle guide covers that direction.

The full set of source and target pairs lives on the supported migration directions page.

Oracle Database Migration Steps, in Order

Eight stages, and they don't reorder well.

1. Assessment. Count objects, lines of code, data volume and integrations. Nothing else gets estimated until this is done.
2. Schema conversion. Tables, indexes, constraints, sequences, views. Data types first, because everything downstream depends on the mapping.
3. Business logic conversion. Packages, procedures, functions, triggers. The long pole.
4. Manual review. Whatever automation didn't reach, handled by someone who knows both dialects.
5. Functional testing. Same inputs, same outputs, row for row.
6. Performance testing. New optimizer, new plans. Expect to add indexes you never needed before.
7. Data migration. Bulk load, then change capture to close the gap.
8. Cutover. Switch the applications and keep the source readable for a rollback window.

Skipping step one is the classic mistake. Teams who start at step two find out in month three that the code volume was double what anyone said, which is the subject of our write-up on how long a migration takes.

Count the Code Before You Commit to a Date

InsightWays connects to Oracle over ODBC, or reads SQL script files off disk, and returns table counts, data volume, object counts by type and lines of code inside each type. It's free, needs no internet connection, runs with read-only privileges and changes nothing in the source.

That report is what makes a schedule defensible. Our SQLWays converter handles 3,000 to 5,000 lines a day per developer against 300 to 400 by hand, so code volume translates fairly directly into calendar time once you know the number. Projects we've run came in at 650,000 lines and 700 tables for Cardinal Health, 1.5 million lines of Oracle code to PostgreSQL for Worldline, and 8 TB of data for Magnit — every one of them sized up front.

PL/SQL Is the Hard Part

Schema conversion is close to solved. Procedural code is where projects earn their timelines, and these are the constructs that cost time:

• Packages. Nothing in PostgreSQL, SQL Server or MySQL maps one-to-one. Package state and package-level variables need a deliberate pattern, not a search-and-replace.
• Collections. Associative arrays, nested tables and varrays each convert differently depending on how they're used.
• CONNECT BY. Becomes a recursive CTE, and the rewrite has to preserve ordering and cycle handling.
• PRAGMA AUTONOMOUS_TRANSACTION. No direct equivalent. Usually it comes out as a separate connection or a background job.
• Supplied packages. UTL_FILE, DBMS_LOB and DBMS_OUTPUT calls need replacements written against the target's own facilities.
• Optimizer hints. They don't carry over, and leaving them in place quietly hurts.

In some cases, our Oracle migration tool automates up to 95% of schema and business logic across these patterns, and the remainder goes to engineers who've met the same constructs on other projects.

Moving Logic Out of the Database Entirely

There's a third option worth weighing. Instead of converting PL/SQL into another dialect, move it into the application layer as Java. That cuts the database down to storage and queries, which makes every future platform change cheaper. Our walkthrough of PL/SQL to Java puts automated conversion at 90–99% success against 50–70% for hand rewrites, with licensing costs down 60–80% once the proprietary engine is gone.

It's more work than a straight dialect swap. It pays off when the same logic would otherwise be rewritten again in three years.

Data, Downtime and Proving the Result

Bulk loading is a throughput problem with known answers. Ispirer Data Migrator moves up to 250 GB an hour on Oracle to PostgreSQL using foreign data wrappers and parallel threads, with no middleware in the path, and its change capture doesn't need transaction or redo logs on the source.

Near-zero downtime comes from sequencing, not speed. Load the bulk while the source stays live, run change capture to keep the target current, then cut over inside a short window with the source still readable. Validation runs alongside: row counts per table, checksums on the columns that matter, and a replay of real queries against both sides with the results compared. Parity you haven't measured isn't parity.

Oracle Database Migration Checklist

Run through this before anyone commits to a date:

• Object counts and lines of code measured, not estimated
• Target chosen against your code patterns, not just price
• Every integration listed — applications, ETL flows, reports, scheduled jobs
• Data volume and acceptable downtime window agreed in writing
• Character set and collation differences identified
• Rollback plan with the source kept readable after cutover
• Test data set that covers the odd cases, not just the happy path
• Named owner for each stage
• Performance baseline captured from Oracle while you still have it

Start With the Measurement

Download InsightWays, point it at your Oracle instance, and you'll have object counts and code volume the same day without granting write access to anything. Bring that report to a 30-minute demo and we'll tell you what converts automatically, what needs a person, and what the project costs.

The teams whose migrations land on schedule are the ones who counted first.

Frequently Asked Questions

What are the most critical phases in an Oracle database migration strategy?

Assessment, business logic conversion, and cutover. Assessment sets the budget, procedural code consumes most of the effort, and cutover is where unlisted integrations surface. Schema and data conversion are largely automated and rarely the reason a project slips.

How do I assess schema compatibility and code complexity before starting an Oracle migration?

Run InsightWays against the instance over ODBC. It returns object counts by type, data volume and lines of code per object type, read-only and free. That gives you code volume, which converts into effort at known rates per developer per day.

What is the difference between a homogeneous and a heterogeneous Oracle migration?

Homogeneous keeps Oracle as the engine — version upgrades, server moves, lift-and-shift to cloud — so the SQL travels unchanged and risk sits in downtime. Heterogeneous changes the engine, so every package and query needs conversion. The second costs considerably more.

How difficult is it to migrate Oracle PL/SQL stored procedures to PostgreSQL?

Most of it automates. Expect 60–80% out of the box and up to 95% with rules tuned to your dialect. The remainder is packages, collections, autonomous transactions and supplied package calls, which need deliberate patterns rather than direct translation.

What are the top cloud-native target options when migrating away from Oracle?

Azure SQL Database, Amazon Aurora PostgreSQL, Amazon RDS, Azure Synapse Analytics for analytics workloads, and managed PostgreSQL or MySQL on any of the three major clouds. Pick by how your procedural code maps, then by price.

How can we achieve near-zero downtime for a mission-critical Oracle database?

Bulk load while the source stays live, run change data capture to keep the target current, then cut over in a short window. Our change capture works without transaction or redo logs, so the source carries no extra load during the sync.

How do we secure sensitive data during the migration?

The toolkit runs inside your environment with read-only privileges on the source and sends nothing to third parties. Assessment works offline. We operate an ISO 27001 information security management system and sign an NDA before project discussions begin.