Migrate MariaDB to MariaDB
Certified — live-tested pathSame-engine MariaDB migrations are how you move between hosts, clouds, or versions — and they still fail in the boring ways: half-copied tables, stale sequences, missing indexes. DBShifts moves the schema and every row, defers constraints for speed, reseeds counters, and proves the result with row counts and checksums.
Free tier · no credit card
How the migration works
Connect
Point DBShifts at your source and target. Credentials stay encrypted; SSH tunnels supported for private databases.
Analyze
Automatic schema introspection produces a migration plan: what converts automatically, what migrates with warnings, what needs human review.
Migrate
Schema is created on the target, data transfers in parallel batches with constraints deferred, indexes rebuilt after load.
Validate
Per-table row counts, type-aware checksums on both sides, FK integrity — plus a fidelity report listing anything lossy.
Run the upgrade tool after the binaries change
After a newer MariaDB starts on an existing data directory, the system tables keep their old structure until mariadb-upgrade (formerly mysql_upgrade) runs. Until then some features and grants behave unpredictably, and the errors point at the system schema rather than at your tables.
It is a one-line step and the most commonly skipped one. Put it in the runbook immediately after the server starts on the new version, before the application reconnects.
MariaDB and MySQL are no longer the same database
A MariaDB-to-MariaDB move should stay that way. The two forked years ago and have diverged: MariaDB's JSON type is an alias for LONGTEXT with a validity check rather than a binary format, it has its own sequences and system-versioned tables, and replication between the two works only in limited combinations.
If a hosting change offers a 'MySQL-compatible' target, treat it as a cross-engine migration and check those features, rather than assuming a dump will load unchanged.
Galera clusters upgrade one node at a time
If the source is a Galera cluster, the move is usually a rolling upgrade: one node leaves, upgrades, rejoins and catches up before the next one goes. When a node has been away too long to catch up incrementally, it receives a full state transfer, copying the whole dataset over the network, so database size sets how long each node is out.
A cluster running mixed versions is a transitional state during the upgrade, not somewhere to stay. Plan the node order, and check the release notes for which versions can run side by side.
MariaDB → MariaDB conversion notes
Engine-specific rules baked into the conversion and transfer pipeline — verified by live certification of this exact pair.
- MariaDB's JSON columns (LONGTEXT + json_valid CHECK) are detected and mapped to real JSON types on targets that have them.
- Engine-specific CHECK constraints like json_valid() are filtered on targets that don't support them — data still migrates.
- Display-width unsigned types (bigint(20) unsigned) are recognized and widened correctly.
Frequently asked questions
Is MariaDB to MariaDB migration production-ready in DBShifts?
Yes — MariaDB to MariaDB is a certified pair. It passed DBShifts's live certification suite (schema conversion, data transfer, row counts, type-aware checksums over an edge-case fixture) and is battle-tested in production use.
How does DBShifts verify the MariaDB to MariaDB migration was correct?
Three layers: per-table row counts on both sides, an order-independent type-aware checksum of row data (canonicalized so engine representation differences don't false-alarm), and FK integrity checks on the target. Rows that fail to insert are quarantined with the exact error — never silently dropped — and can be fixed and retried from the UI.
What happens to MariaDB types that MariaDB doesn't have?
They convert by deterministic rules with a recorded decision: a native equivalent where one exists, a portable fallback (TEXT/JSON/DECIMAL) where one doesn't. Every lossy conversion appears in the migration plan before you run and in the fidelity report after. You can override any mapping per column.
Can I keep MariaDB and MariaDB in sync after the initial migration?
Yes. DBShifts supports incremental sync (UPSERT-based delta transfers on a sync key) and, for supported sources, real-time change data capture so the target stays current until you cut over.
Do I need to write any SQL or scripts for MariaDB to MariaDB?
No. Connect both databases, review the generated migration plan (what's automatic, what migrates with warnings, what needs manual review — typically triggers and stored procedures), and run. Procedural code is transpiled best-effort and queued for human review rather than auto-applied.
What changes in a same-engine MariaDB migration?
Structurally nothing changes — types map one-to-one. The risks are operational: half-copied tables, sequences left pointing at 1, and indexes that never got rebuilt. DBShifts reseeds counters to MAX(id)+1, defers then rebuilds constraints and indexes, and proves the copy with row counts and checksums.
Go deeper
Related migration paths
Ready to move MariaDB to MariaDB?
Set up in under two minutes. Validation and rollback included.
Start Free Migration