Migration from MySQL

A MySQL to MariaDB migration is a data migration, not an upgrade. Plan it as one.

What does not transfer

• Data directories. MySQL 8.0's transactional data dictionary is not readable by MariaDB. An in-place swap of the binaries is not supported.
• GTIDs. The formats are incompatible, so you cannot replicate from MySQL to MariaDB to keep the target current during a cutover.
• Authentication plugins. caching_sha2_password users need to be recreated with a plugin MariaDB supports.
• JSON internals and multi-valued indexes. MariaDB's JSON is validated LONGTEXT; indexes on JSON array members do not carry over.
• Some information_schema contents, which is what breaks monitoring and schema-diff tooling.

Assessment first

Before scheduling anything, enumerate what you actually depend on:

-- Non-InnoDB tables that need converting.
SELECT table_schema, table_name, engine FROM information_schema.tables
WHERE engine NOT IN ('InnoDB')
  AND table_schema NOT IN ('mysql','information_schema','performance_schema','sys');
 
-- Users whose authentication plugin will not exist on the target.
SELECT user, host, plugin FROM mysql.user;
 
-- Generated columns, JSON usage and functional indexes worth reviewing by hand.
SELECT table_schema, table_name, column_name, data_type, generation_expression
FROM information_schema.columns
WHERE generation_expression <> '' OR data_type = 'json';

Also inventory the tooling: backup jobs, monitoring queries, schema migration tools, CDC connectors and ORM dialect settings all need verifying against MariaDB.

Migration procedure

1. Build the target on the intended MariaDB version and create the schema from a dump of the structure only. Fix incompatibilities here, in review, not during the cutover.
2. Load the data with mariadb-dump/mariadb-import, or with a parallel loader for large datasets. Record how long it takes.
3. Recreate users and grants explicitly, choosing MariaDB-supported authentication plugins.
4. Keep the target current with a CDC pipeline reading MySQL's binlog and applying to MariaDB — Debezium plus a sink, or an application-level dual write. Native replication is not available between the engines.
5. Verify. Row counts per table, checksums on the largest tables, and a sample of application queries with their plans compared side by side.
6. Cut over during a low-traffic window: stop writes, drain the CDC lag to zero, switch the application, verify, then allow writes.
7. Keep MySQL running and intact until the new system has proven itself. That is your rollback.