Data migration from MariaDB to SQL Server

Migrating to SQL Server from MariaDB: what changes in the target

If the SQL Server table does not exist, dbSlice stops and shows a CREATE TABLE translated for SQL Server, for your DBA to review and run. By default it creates nothing in your databases. These are the SQL Server details to look at:

• Unsigned integers. SQL Server has no unsigned types, and the suggested DDL does not mark them. Widen the columns that are unsigned in MariaDB before running it: INT UNSIGNED → BIGINT, BIGINT UNSIGNED → DECIMAL(20,0).
• TINYINT(1) flags. They are suggested as SMALLINT. Declare them BIT if they are booleans.
• Zero dates. MariaDB can hold 0000-00-00, which SQL Server rejects. Use a SELECT as the source and turn them into NULL, for example SELECT id, NULLIF(created_at, '0000-00-00 00:00:00') AS created_at, … FROM orders.
• Text becomes NVARCHAR. Up to 4,000 characters it keeps the length; above that and for LONGTEXT it becomes NVARCHAR(MAX). JSON arrives as text in NVARCHAR(MAX); SQL Server reads it with JSON_VALUE and OPENJSON.
• ENUM, SET and YEAR are suggested as text. Add a CHECK constraint if you want the list enforced; YEAR is usually better as SMALLINT.
• AUTO_INCREMENT ids and IDENTITY. SQL Server only accepts explicit values in an IDENTITY column with IDENTITY_INSERT. dbSlice offers Keep identity for that. It needs ALTER permission on the table, and the screen asks you to confirm first. Without it, SQL Server generates new ids, so do not use the id as the sync key.
• Upsert runs as MERGE, and bulk loads use SqlBulkCopy with triggers and constraints checked, so the target's rules still apply.

How dbSlice controls the load

• Reads MariaDB in small batches, so the live database keeps serving its users.
• Matches rows by a key you choose. Modes: Initial load, then Upsert, Insert new, Update only or incremental by column (updated_at or the AUTO_INCREMENT id).
• Checks before writing with Record Diff and on-screen checks, and proves the result with Compare and the full list of divergent keys.
• Masks on the way for development and test copies, keeping keys and foreign keys intact.
• Export instead of load: when you only need a file, the same app exports a MariaDB table to CSV, JSON, XML or HTML.

Step by step: convert a table from MariaDB to SQL Server

1. Connect to MariaDB and to SQL Server.
2. Pick the source table (or a SELECT, as in the zero-date example) and the target table.
3. Choose the key column, and turn on Keep identity if the ids must stay the same.
4. Choose the mode: Initial load, then Upsert or Insert new.
5. Run Record Diff, then the copy, or save it as a job for the CLI and the Task Scheduler.

Moving data between SQL Server and MariaDB in both directions

The same app moves data the other way: see SQL Server to MariaDB. For MySQL as the source, see MySQL to PostgreSQL; the same MariaDB details apply.

FAQ

Does it work with MySQL too?

Yes. MariaDB and MySQL use the same connector in dbSlice, and the details above apply to both.

Do I need to enable anything on MariaDB?

No, reading uses ordinary queries. Only bulk loading into MariaDB needs local_infile.

Are deletes copied by incremental runs?

No. Run Compare or a reload before the switch.

Is there a free version?

Yes, on the Microsoft Store: it connects, browses, compares and exports to CSV. Writing to a target needs a Desktop or Server license.