Oracle
MySQL

Oracle to MySQL Converter for Database Migration

Move Oracle databases to MySQL, MariaDB, Amazon RDS, or Amazon Aurora with schema conversion, type mapping, saved sessions, and optional two-way sync.

Move Oracle schemas and data into MySQL-compatible targets without turning the project into a manual export/import job.

DBConvert gives you a desktop wizard for type mapping, object selection, saved sessions, and staged cutover sync with DBSync.

Main reason

license and stack simplification

Target family

MySQL, MariaDB, RDS, Aurora, Cloud SQL

Cutover option

one-time move or staged sync

Not an online upload converter. DBConvert connects to your Oracle and MySQL databases directly, so credentials and data stay under your control instead of being uploaded to a browser-based conversion service.

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: rewrite Oracle-specific application code automatically. Treat code conversion as a separate review track.

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.

Data type mapping

DBConvert proposes MySQL-compatible types first, then lets you adjust precision, length, and binary/text storage before creating the target tables.

Oracle source MySQL target Review note
NUMBER DECIMAL or integer type Use BIGINT for primary and foreign keys when the column is an integer identifier.
VARCHAR2 / NVARCHAR2 VARCHAR Confirm character set and length semantics before loading multilingual data.
CLOB / NCLOB TEXT / LONGTEXT Choose storage size based on real column values, not only declared type.
BLOB / RAW LONGBLOB / VARBINARY Keep binary columns binary; do not route encoded payloads through text columns.
DATE / TIMESTAMP DATETIME / DATETIME(6) Review timezone handling and fractional seconds if the application depends on them.

ROWID has no MySQL equivalent. DBConvert reports it so you can drop it, replace it with a surrogate key, or handle it in application logic.

What to verify after conversion

DBConvert creates the MySQL-side structure and moves the data. After that, check the few Oracle-specific parts that may affect application startup or cutover.

Check DBConvert does You verify
Generated keys Maps primary-key sequences to MySQL generated-key columns and reseeds above loaded values. Run a test insert in tables that used Oracle sequences.
Object names Maps Oracle schemas into MySQL databases and applies the identifier policy selected in the wizard. Confirm application code uses the same casing and database names as the target.
Views Translates selected Oracle views and SELECT-type queries to MySQL-compatible view SQL. Review generated SQL before production; see views translation.
Application SQL Does not rewrite SQL embedded in your application code. Update Oracle-only syntax: MINUS to LEFT JOIN / NOT EXISTS, INTERSECT to join logic, CONNECT BY to recursive CTEs, ROWNUM to LIMIT, and (+) joins to ANSI joins.
PL/SQL code Keeps the migration focused on schema objects and data movement. Port packages, procedures, triggers, materialized views, and DBMS_* calls manually if they are still used.

Why teams migrate Oracle workloads to MySQL

License cost eliminated

Oracle EE charges per CPU with mandatory support contracts. MySQL Community, MariaDB, and Percona Server carry no per-core fee — for most workloads, this is the primary reason to move.

Cloud-native target support

MySQL-compatible managed databases run on Amazon RDS / Aurora, Azure Database for MySQL, and Google Cloud SQL — the same control planes most organizations already standardize on.

Wider hiring pool

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

Shed Oracle-specific complexity

Migration is a chance to retire database-side logic the application no longer needs and move what remains to the application tier or 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
Oracle

All Oracle Tools

Other directions and pairs
MySQL

All MySQL Tools

Migration & sync options

Reverse Conversion

MySQL to Oracle

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.

More guides for Oracle ↔ MySQL

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