MySQL to SQL Server migration guide

IntoSQL reads a MySQL or MariaDB dump and writes one SQL Server script with the same tables, columns, keys, indexes, foreign keys, defaults, identities, comments and rows. It reads the dump itself, without a database server, and lists in the report every value SQL Server can't hold as it is and every object it doesn't carry. The script loads on SQL Server 2017 to 2025.

Convert in the browser: MySQL to SQL Server opens the converter set up for this pair.

Dump for the best result#

Any dump from mysqldump, mariadb-dump, mysqlpump, phpMyAdmin or Adminer works, as .sql or .sql.gz. These options keep more of your data:

mysqldump --default-character-set=utf8mb4 --hex-blob \
  --routines --triggers --events --single-transaction \
  shop | gzip > shop.sql.gz

• --default-character-set=utf8mb4 keeps emoji and other 4-byte characters. A dump made with utf8 has already lost them, and the report says so (dump_lost_four_byte_chars).
• --hex-blob writes binary columns as hexadecimal, which survives copying between systems.
• --routines --triggers --events add those objects to the dump, so the report can list them by name.
• --single-transaction takes a consistent snapshot of InnoDB tables without locking them.

A dump made with --no-create-info still converts: the types are read from the values, and the report says the schema was missing (no_schema).

Convert#

In the browser, open MySQL to SQL Server or the converter on the home page, drop the dump and choose SQL Server. It reads the file from your disk in pieces, twice, and writes the script as it goes, so the dump is never uploaded and its size isn't limited by memory. The desktop app does the same with the file on disk.

With the command line:

intosql inspect shop.sql.gz
intosql convert shop.sql.gz --to sql_server --output shop.sql_server.sql --report shop.report.json

inspect lists the tables, their rows and what won't be converted, without writing anything. convert writes the script and, with --report, the report as JSON.

Through the API, a dump converts like any other file: open a conversion with its name ending in .sql or .sql.gz and "output": {"dialect": "sql_server"}.

Load into SQL Server#

sqlcmd -S localhost -Q "CREATE DATABASE shop"
sqlcmd -b -f 65001 -S localhost -d shop -i shop.sql_server.sql

-b stops at the first error and -f 65001 reads the script as UTF-8. The script creates the tables, copies the rows in batches of up to 1000 with IDENTITY_INSERT, then adds indexes, foreign keys, identities, triggers and comments. Foreign keys are added WITH NOCHECK and then checked: a row that points to a missing row is named by its constraint instead of failing the load half way. Each identity continues after the highest id copied, or after the table's AUTO_INCREMENT when that is higher.

What isn't converted#

Views, triggers, stored procedures, functions and events are written in each database's own language. They are listed in the report by kind and name, never dropped silently. ON UPDATE CURRENT_TIMESTAMP is the exception: it becomes a SQL Server trigger.

Data types#

MySQL to SQL Server data types lists each type that changes in the script: what it becomes, why, and the report line.

Every other rule#

Generated from the engine, where each rule is decided.