Migrate your databases from one server to another without staying up all night.
SQLmig backs up, migrates, and restores your MySQL and MariaDB databases in four guided steps. And it does so safely: before writing anything to the target server, it compares the two servers and tells you exactly what could go wrong: different versions, different engines, unusual collations, legacy objects.
One-time payment, no subscription. License valid for installation on one machine, with no time limit for the entire version 4, including updates. Windows, macOS, and Linux. Special 25% launch discount for SQLmig 4. Prices in US$.
MySQL 5.7, Production
MySQL 8.0, New server
Migration path: supported
Foreign keys, views, reserved words: no issues detected
Collations: 2 known adjustments will be applied during import
utf8mb3: 14 objects flagged for review
max_allowed_packet on target: 64 MB, sufficient
The problem never shows up during the dump.
It shows up during import, an hour later, when the maintenance window is already halfway over and the database is only halfway restored.
$ mysqldump -h prod -u root --all-databases > dump.sql
$ mysql -h new-server -u root < dump.sql
ERROR 1273 (HY000) at line 41: Unknown collation: 'utf8mb4_0900_ai_ci'
ERROR 1005 (HY000) at line 2188: Can't create table `crm`.`facturation`
ERROR 2006 (HY000): MySQL server has gone away
# 3 errors. 2 hours wasted. And a database only half restored on a new server that's already running, without all the data or with corrupted data.
Versions don't speak the same language
For example, a collation created in MySQL 8 doesn't exist in 5.7. A legacy ROW_FORMAT works on one side and fails on the other. SQL modes become stricter from one release to the next. What comes out cleanly from the source is rejected by the target.
Neither do the database engines
MySQL and MariaDB don't accept the same collations, table options, or syntax in views and routines. The dump won't warn you. The import will.
Everything is packed into a single command
One wrong host recalled from terminal history, one --all-databases too many, one overwritten file: the riskiest operations in your infrastructure are also the ones that require no confirmation.
No one has time to audit everything
Manually checking collations, DEFINER clauses, views, constraint names, and max_allowed_packet across forty databases takes a full day. So we skip the step and cross our fingers.
The difference isn't made during the migration. It's made beforehand.
Command line
You discover incompatibilities during import.
You read through the dump manually to understand the error.
An 80% failure means you have to start all over again.
Nothing stops you from writing to the production server and accidentally overwriting data.
The SQL command to enter in the terminal is complex, and the options vary depending on the database engine.
If you’re not completely familiar with every command-line option, there’s no guarantee your databases were migrated correctly.
Six months later, no one remembers how the databases were migrated or which command-line options were used. The data may even have been corrupted without anyone knowing during a poorly managed migration.
With SQLmig
Your server settings are configured once and retained from one session to the next.
A migration project’s incompatibilities are listed before the dump, check by check.
Each warning tells you what to check and why.
The dump stays in the library: you can resume the import later, even after restarting.
A server whose "Target" role is unchecked for security cannot accidentally receive an import.
Your databases can be automatically renamed between the Source server and the Target server during migration.
The process is the same every time, for you and your colleagues: just a few clicks. No expertise required.
The history keeps the date, status, versions, databases, and complete log.
Four steps. Always the same, no matter the server.
Add a server to the "Source" area and, optionally, another to the "Target" area, then proceed from left to right. For a simple backup, leave the target empty: steps 2 and 4 disappear.
Choose databases
SQLmig connects, checks the server’s actual version, and lists your application databases, excluding system schemas. The number of tables, estimated size, and collation are shown for each one.
Analyze the migration
Sixteen checks compare the source, the target, and your exact selection. The report classifies each item as OK, a warning, or an error. An error flagged in the report blocks the process until it’s addressed.
Create the dump
One file per database, or a single file for all of them. Includes structure, data, routines, and triggers; events too, whenever the SQL account has permission to read them.
Import to the target
Choose the databases to restore, rename them if needed, and start the import. SQLmig applies known adaptations without modifying your file, then verifies that everything arrived successfully.
What SQLmig checks for you, in just a few seconds.
Sixteen checks run against the exact selection you’re about to migrate. Each returns a status, an explanation, and, when possible, instructions on what to do next.
Migration path from source → target
Connection and identity of both servers
SQL modes rejected by the target
ENUM and SET size limits
Foreign key constraint names
View column names that exceed limits
Partitioning and storage engines
Objects still using utf8 / utf8mb3
Collations missing from the target
Reserved words used as object names
DEFINERs for views, routines, and events
GROUP BY with ASC/DESC in stored objects
Zero or partial dates rejected during import
Legacy InnoDB ROW_FORMAT and KEY_BLOCK_SIZE
Insufficient max_allowed_packet on the target
MySQL Shell check for version upgrades
During import, SQLmig applies known adaptations, MySQL 8 collations for MySQL 5.7, legacy InnoDB row formats, modes related to zero dates, and the "sandbox" directive in recent MariaDB dumps, without ever modifying your original dump file.
A tool designed for operations that can’t afford to fail.
Dump library
Close SQLmig and come back tomorrow: the dump will still be there, with its source, databases, date, and size. Choose a target and import. Nothing to reconfigure. Just one click.
Rename databases during import
Restore hosting1_wordpress as hosting2_wordpress with one click, or apply a prefix to an entire selection. SQLmig remembers the mappings for next time.
Partial import
A grouped dump with thirty databases? Restore three of them. SQLmig flags dependencies to check before you go live.
SQL clients installed for you
mysqldump, mariadb-dump, MySQL Shell: SQLmig installs the official client for your server, without affecting any SQL servers that may already be running on your machine.
Production protection
Uncheck the "Target" setting on a sensitive server: SQLmig won’t be able to write to it by mistake. The Target button simply becomes unavailable for that server.
Encrypted connections
TCP with TLS up to VERIFY_IDENTITY, a certificate authority certificate, a client certificate, or a local UNIX socket. And if needed, a guide to connecting to AWS RDS is available in the documentation.
History and logs
Operation type, date, servers, versions, databases involved, dump mode, and the complete log. Everything you need to explain, six months later, what was actually done.
Analyze an existing dump
Even a .sql file created by another tool: SQLmig reads it, counts the databases and tables, tracks progress, and flags anything that could cause problems on the target server.
Portable configuration, 16 languages
Export your server configuration and settings, then easily import them on another machine running SQLmig. The interface is available in 16 languages, with light, dark, or automatic theme options.
Back up for free. Migrate with a license.
SQLmig installs and works at no cost: connect to a SQL server and create as many backups as you want. It’s a gift to the community, so everyone can always back up data from their SQL server. A SQLmig license unlocks everything else: migrating and importing data to another server. So you know exactly what you’re buying before you pay.
Feature
Free
With a license
Number of SQL servers
1
Unlimited
Connection testing and version detection
Yes
Yes
List databases and create backups
Yes
Yes
Separate dumps or a single combined dump file
Yes
Yes
Choose a target server for migration
-
Yes
Compatibility checks (16 checks)
-
Yes
Dump prepared for migration
-
Yes
SQL analysis of a dump before import
-
Yes
Import and restore to a target server
-
Yes
Rename databases during import
-
Yes
SQLmig 4.x updates
Yes
Yes
One license. One payment. SQLmig without limits.
$199.99
$149.99
One-time payment, no subscription.
License valid for installation on one machine. Price in US$.
What’s included with the license
Valid indefinitely for SQLmig 4.
All version 4 updates included, free of charge.
One machine per license, transferable: release it here and activate it elsewhere.
Windows, macOS, and Linux, all with the same license. Choose where to install it.
All migration, analysis, and restore features unlocked.
Still unsure? Install SQLmig and make a real backup right now, for free. In ten minutes, you’ll know if it’s the right tool for you.
The questions we’re asked most often.
Is the license a subscription?
No. It’s a one-time purchase. The license remains valid indefinitely and covers all version 4 updates.
What happens when SQLmig 5 is released?
Your license will continue to work with version 4 for as long as you use it. You only need to buy a license once per major version.
Will I lose my license if I change computers?
No. In SQLmig, click Settings → SQLmig License, click "Release license," then activate it on the new machine. Each license can be used on only one machine at a time.
Do I need to be connected to the Internet at all times?
No. After an initial online validation, SQLmig validates the license offline for up to 30 days, with that period renewed each time it checks online.
How is my SQL server password stored?
You can choose to save your server password in SQLmig; in that case, it is stored in encrypted form by SQLmig. Or you can choose not to save it at all, in which case you’ll simply need to provide it for every operation performed by SQLmig.
Can I migrate from MySQL to MariaDB, or vice versa?
Yes. SQLmig supports migrations between database engines and alerts you to potential issues: collations, storage engines, table options, and SQL features. Always test on a copy before switching over.
Why can’t I migrate my databases directly from MySQL 5.7 to 8.4?
Because this jump skips the intermediate MySQL 8.0 series. SQLmig first takes you through MySQL 8.0, as recommended by the official MySQL documentation: an intermediate step that’s easy to perform with SQLmig, with far fewer surprises at the end.
Does SQLmig replace my backup strategy?
No, and it doesn’t claim to. SQLmig performs backups and logical migrations. It does not replace real-time replication, physical database engine backups, or your internal testing procedures.
Which SQL servers does SQLmig work with?
SQLmig can work with MySQL 5.0, MySQL 5.1, MySQL 5.5, MySQL 5.6, MySQL 5.7, MySQL 8.0, MySQL 8.4, MySQL 9.7, MySQL 26.7, MariaDB 10.6, MariaDB 10.11, MariaDB 11.4, and MariaDB 11.8.
Want to transfer your data to another SQL server? This time, it can be easy with SQLmig.
Take advantage of the SQLmig 4 launch offer today and buy your license for $149.99 (instead of $199.99). One-time payment, no subscription. Or get started for free with a backup made using SQLmig, right now, on the server of your choice.
MySQL 5.0 to 26.7 · MariaDB 10.6 to 11.8 · Windows, macOS, and Linux · Interface in 16 languages
License valid for installation on one machine. Price in US$.