An Oracle schema migration tool moves a schema from one version to the next and records what ran where. On Oracle, that record has to cover more than tables: most of the change in a typical Oracle application lands in PL/SQL packages, triggers, and views.
This guide covers schema migration and change management, not moving data off Oracle (Zero Downtime Migration, Data Pump, or an Oracle-to-Postgres move are a different category).
Two things set Oracle apart. Oracle ships its own answers: SQLcl, the free command-line client, generates versioned change sets from a live schema, and Edition-Based Redefinition runs old and new PL/SQL side by side during a release. And DDL commits implicitly, so a migration that fails halfway leaves the first half applied.
This post is maintained by Bytebase, an open-source database governance platform. Tool versions and license terms were checked in October 2026, and we update the post as they change.
The same roundup exists for SQL Server, MySQL, and Postgres.
Which one fits
| Tool | Approach | Licensing | Best when |
|---|---|---|---|
| Flyway | Migration-based | Open source core, commercial Enterprise | You want numbered SQL files and nothing clever |
| Liquibase | Migration-based | FSL since 5.0, commercial Secure | One changelog covers Oracle and other engines |
| SQLcl projects | Migration-based (Liquibase runtime), generated from a live schema | Free (Oracle Free Use License) | Developers change a dev schema, and the tool writes the change set |
| Redgate Schema Compare for Oracle | State-based | Commercial | You deploy by diffing two schemas |
| Sqitch | Migration-based | Open source | Change order is a dependency graph |
| Bytebase | Migration-based governance | Open source, paid tiers | The change needs review and an audit trail first |
| Edition-Based Redefinition | Built into the database | Every edition | PL/SQL has to change with the application running |
Flyway
Flyway applies numbered SQL files like V3__add_invoice_status.sql in order and records them in a history table. Version 13.9.0 shipped on October 1, 2026, and Redgate supports Oracle 12.2 through 26ai, including XE.
Its parser handles PL/SQL: a block ends with / on its own line, as in SQL*Plus. Repeatable R__ migrations re-run whenever their checksum changes, which fits packages and views. The catch is SQL*Plus commands. SET DEFINE OFF or WHENEVER SQLERROR need a paid edition, so scripts written for SQL*Plus fail on the first SET line in the free one.
Best for: a straightforward versioned-SQL workflow with minimal setup.
Liquibase
Liquibase declares changes as changesets in a changelog, usually formatted SQL on Oracle. One gotcha: it splits statements on semicolons by default, which cuts a package body into pieces. Set endDelimiter:/ or splitStatements:false on PL/SQL changesets.
Community moved to the Functional Source License with 5.0 in 2025 (free in production, no longer OSI-approved) and is at 5.0.4. The commercial edition, Liquibase Secure, reached 6.0 on September 30, 2026, adding a policy center with 50+ prebuilt rules and role-based access control over policies and exceptions.
Best for: one changelog format across several engines.
SQLcl projects
SQLcl embeds Liquibase and generates changelogs from a live schema through Oracle's own DBMS_METADATA, so grants, PL/SQL, APEX applications, and ORDS modules come out the way Oracle scripts them. The project command adds a CI/CD workflow: project export writes object DDL into Git, project stage compares the branch with its base and generates the change sets, and project gen-artifact and project deploy package and apply a release. The current version is 26.3.0, from September 29, 2026. Under the hood the change sets are Liquibase changelogs and the target database gets the same DATABASECHANGELOG table, so think of it as Liquibase's runtime with Oracle's generator and Oracle's license on top.
It is Oracle-only, which is right for an all-Oracle shop and no help for anyone else. And since stage writes the change set, someone still has to read it before production does.
Best for: Oracle-only teams, especially APEX shops.
Redgate Schema Compare for Oracle
Schema Compare for Oracle is the state-based option: compare two schemas, review the differences per object, and it generates the deploy script. It is a commercial Windows application with a command line (including a Linux one) for pipelines, and the same engine drives state-based deployments in Flyway Enterprise.
It suits PL/SQL-heavy change. It is weaker where a table change needs a data decision, such as a NOT NULL column added to a populated table, and Redgate's own docs point to migrations there.
Best for: teams that deploy by "make production look like this schema".
Sqitch
Sqitch is open source with no commercial edition, at 1.6.1 as of January 2026. Each change declares its dependencies in sqitch.plan and ships deploy, revert, and verify scripts. On Oracle it connects through DBD::Oracle and runs scripts through sqlplus, so SQL*Plus scripts work as written, at the cost of the Oracle Instant Client in your build image.
Best for: long-running refactors where order is not linear.
Bytebase
Bytebase governs how changes are proposed, reviewed, approved, run, and audited, from the web console or a GitOps workflow. On Oracle that includes SQL review rules checked before execution, batch change across many databases (one schema per customer, for example), and schema synchronization. That last one diffs a source schema (another database, one of its past versions, or pasted DDL) against the targets and generates the DDL, the same mechanism as Schema Compare. In the console it is a one-off that feeds an issue for review. The same diff is also an API call (databases:diffSchema takes a schema file as the target and returns the DDL), so a pipeline can diff the schema in Git against production and open the issue itself. For an UPDATE or DELETE, it can back up the affected rows into a bbdataarchive schema and roll the data back in one click.
The boundary: the declarative, state-based workflow covers Postgres and MySQL, not Oracle. For a desired-state model on Oracle, use Schema Compare or project stage, or wire the diff API into your own pipeline. Community is free, and paid tiers add the governance features (pricing).
Best for: more than one person can change production, and someone has to answer for what ran.
Edition-Based Redefinition (built in)
Not a migration tool, but every Oracle team asks. EBR has shipped since 11g Release 2 in every edition at no extra cost. You change PL/SQL, views, and synonyms in a new edition while sessions on the old one keep running the old code. Tables are not editionable, so table changes need editioning views and crossedition triggers, which is why most teams use EBR for one high-availability application rather than everywhere. It also does not record which change ran; pair it with one of the tools above.
Best for: PL/SQL releases that cannot take an outage.
Picking one
- All Oracle, developers work in a dev schema, APEX in the mix: SQLcl projects.
- Plain versioned SQL: Flyway, paid if your scripts rely on SQL*Plus commands.
- One changelog across engines: Liquibase.
- Deploy by comparing schemas: Schema Compare for Oracle.
- Changes form a dependency graph: Sqitch.
- Approvals, SQL review, rollout across many databases, and an audit trail: Bytebase.
- No downtime for PL/SQL: add EBR to any of the above.
My default: SQLcl if everything is Oracle, Flyway if anything is not. Then put a review step in front of production, because when DDL commits as it goes, catching a bad change before it runs is the only reliable undo. That is what database change management covers.
References
- Using Liquibase with SQLcl, Oracle
- Flyway Oracle database support, Redgate
- Introducing Liquibase Secure 6.0, Liquibase
- Edition-Based Redefinition, Oracle
- Sqitch, David E. Wheeler