Oracle
MySQL

Oracle to MySQL Converter

Move Oracle workloads to MySQL, MariaDB, Amazon RDS, or Amazon Aurora. Schema conversion, type mapping, and optional two-way sync.

Oracle to MySQL migration is usually a license and stack-simplification move, not a same-engine copy. DBConvert gives you a desktop wizard for moving Oracle schemas and data into MySQL-compatible targets, with GUI-driven type mapping, saved sessions, and DBSync when the two systems must stay aligned during a staged cutover.


What DBConvert does on this path: handles the Oracle move as a repeatable desktop workflow:

  • Connects to Oracle on-prem, Oracle XE, or Oracle Cloud without requiring an Oracle client or ODBC driver on the migration host.
  • Lets you review object selection and data-type mapping before creating MySQL-compatible tables and rows.
  • Writes to MySQL, MariaDB, Percona Server, Amazon RDS / Aurora MySQL, Azure Database for MySQL, or Google Cloud SQL.

What it does not do: Oracle PL/SQL packages, complex triggers, DBMS_* calls, synonyms, materialized views, hierarchical CONNECT BY queries, and application SQL using Oracle-specific syntax are not translated to MySQL automatically. Treat that code as a rewrite task.

Which DBConvert tool fits?

Use DBConvert for the initial migration; use DBSync only when both systems must keep changing during a staged cutover.

DBConvert for Oracle → MySQL

One-time conversion with selectable objects, type mapping, index and primary-key handling, saved sessions, and direct migration to local, hosted, or cloud MySQL-compatible targets.

DBSync for Oracle ↔ MySQL

Repeat synchronization for staged migration, parallel validation, or a temporary transition period where Oracle and MySQL must keep exchanging inserts, updates, and deletes.

Need more context? Compare DBConvert and DBSync side by side →

How DBConvert handles the Oracle → MySQL differences

Oracle and MySQL differ in numeric precision, sequence handling, type semantics, schema model, and procedural code. DBConvert maps most of those differences in the wizard with sensible defaults that you can review or override per table; PL/SQL rewrite and application-SQL portability are the two items that still need a human.

  • Data types. Defaults to NUMBER → DECIMAL (route PKs / FKs to BIGINT per column in the review), VARCHAR2 → VARCHAR, CLOB → LONGTEXT, BLOB → LONGBLOB, RAW → VARBINARY, DATE → DATETIME, and TIMESTAMP → DATETIME(6). ROWID has no MySQL equivalent — reported in the wizard so the schema decision (drop / replace with surrogate) is explicit.
  • Sequences and generated keys. Collapses Oracle sequences into MySQL AUTO_INCREMENT columns on the primary key and reseeds above the loaded maximum key value — so application inserts do not collide. Multi-table shared sequences need explicit application-side emulation; MySQL has no standalone sequence object (MariaDB does).
  • Schemas and object names. Folds Oracle schemas into MySQL databases and normalizes quoted mixed-case identifiers either to lowercase or preserves backtick-quoted names — pick the policy in the wizard so MySQL's identifier-case behavior does not surface at application boot.
  • Application SQL portability. Oracle-specific query syntax does not run unchanged against MySQL: MINUS rewrites to LEFT JOIN / NOT EXISTS, INTERSECT to INNER JOIN, hierarchical CONNECT BY to WITH RECURSIVE CTEs (MySQL 8+; MySQL 5.x has no recursive CTE), ROWNUM to LIMIT, Oracle (+) outer joins to ANSI LEFT JOIN. DBConvert moves the schema and data; the application SQL layer is its own search-and-replace task.
  • Views translation — two-way. Translates view definitions and supported queries between Oracle and MySQL in both directions during the migration — one of the three native two-way-translation pairs (MySQL ↔ SQL Server, MySQL ↔ Oracle, SQL Server ↔ Oracle).
  • Stored procedures, triggers, and other procedural code — outside DBConvert's scope. DBConvert's migration covers tables (with their fields, types, defaults, and indexes), views, and foreign keys. PL/SQL packages, procedures, functions, triggers, autonomous transactions, materialized views, and DBMS_* package calls stay in the source and are rewritten manually in MySQL's stored-procedure dialect. Typically a small fraction of the schema, but the one item the tool does not handle.

Why teams migrate Oracle workloads to MySQL

License-escape

Oracle Enterprise Edition is licensed per CPU with named-user options and mandatory support contracts that scale with the deployment. MySQL Community (GPL), MariaDB, and Percona Server have no edition tiers and no per-core fee on any size of box. For most application workloads this is the primary business reason for the direction.

Managed cloud targets are ubiquitous

MySQL-compatible managed databases run on Amazon RDS / Aurora, Azure Database for MySQL, and Google Cloud SQL. Oracle's own managed offering (Oracle Cloud) is narrower and exists outside the AWS / Azure / GCP control planes most organizations already standardize on.

Hiring pool and community

MySQL is the second-most-used relational database in the Stack Overflow developer survey; Oracle DBA expertise is scarcer and more expensive. Standardizing on MySQL simplifies hiring, training, and on-call rotation.

Modernization away from Oracle-specific features

Many older applications used Oracle-specific features (packages, hierarchical queries, advanced PL/SQL) that the modern application no longer needs. Migration is a chance to drop dead PL/SQL and move the remaining logic to the application tier or to MySQL stored routines.

Choosing the migration route

Start with the workflow you need: desktop conversion, staged synchronization, cloud-native cutover, or SQL-code translation.

  • DBConvert and DBSync. Pick the desktop wizard path when you want object selection, GUI-driven type-mapping review, saved sessions, scheduled jobs, and the option to keep Oracle and MySQL synchronized during a staged cutover.
  • AWS-native cutover. If the target is Amazon RDS for MySQL or Aurora MySQL and the project needs cloud-native assessment, full-load migration, or change data capture, AWS SCT and AWS DMS may be part of the infrastructure plan. That is a cloud pipeline choice, not a desktop conversion workflow.
  • SQL translators. SQL-dialect conversion tools can help assess queries and stored code, but they do not connect to live databases, move production rows, validate target data, or maintain synchronization.
  • Manual scripts. Custom ETL is reasonable when the migration is mostly bespoke cleanup logic. It gives maximum control, but the team owns type mapping, retry behavior, validation, and repeatability.

Supported versions

  • Oracle 10g and later, including Oracle XE and Oracle Cloud
  • No Oracle client or ODBC driver required
  • MySQL 5.x, 8.x; MariaDB; Percona Server
  • Amazon RDS / Aurora MySQL, Azure Database for MySQL, Google Cloud SQL

Supported in this path

Source Oracle
Target MySQL
Oracle Database Oracle Database XE MySQL MariaDB Percona Server for MySQL Amazon RDS for MySQL Amazon Aurora MySQL Azure Database for MySQL Google Cloud SQL for MySQL

Using Oracle to MySQL Tools

When launching the DBConvert or DBSync application in GUI mode, it guides you through the steps to start database migration or synchronization:

1

Connect to Oracle source database

Specify the username/password and host/port parameters if your source database requires login credentials.

Connect to Oracle source database from DBConvert

Oracle source

Configure the Oracle source with the Oracle source settings. If client or authentication errors appear, use the Oracle troubleshooting guide.

2

Connect to MySQL destination database

Specify parameters for the destination database similar to the source, defining connection settings and username/password pairs.

Connect to MySQL target database from DBConvert

MySQL target

Connect to local MySQL, MariaDB, Percona Server, Amazon Aurora MySQL, Amazon RDS, or Google Cloud SQL.

Next steps: configure, validate, run

After connecting source and target, the remaining steps are the same for every database pair:

  • Configure migration options — pick tables, fields, indices, views.
  • Issue detection — the built-in checker flags integrity problems before migration starts.
  • Execute — commit the job, monitor progress, save the session for reuse.
  • Schedule and CLI — rerun saved sessions on a schedule or from the command line.
Open the full guide

Steps 3–5, software features, command-line mode, scheduler, and system requirements.

See all features