Migrate MariaDB to SQL Server

Beta — live-tested path

Migrating from MariaDB (the community-driven MySQL fork) to SQL Server (Microsoft's enterprise relational database) means every table, column type, key, index and row has to survive two engines' different opinions about data. DBShifts converts the schema with deterministic rules, transfers data in parallel batches, and validates the result with per-table row counts and type-aware checksums.

Start MariaDB → SQL Server Migration

Free tier · no credit card

MariaDB vs SQL Server

MariaDB

the community-driven MySQL fork.

SQL Server

Microsoft's enterprise relational database.

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.

MariaDB to SQL Server data type mapping

Pulled directly from DBShifts's own conversion rules — not a general reference table, this is what actually runs.

MariaDB	SQL Server	Note
INT	INT
BIGINT	BIGINT
SMALLINT	SMALLINT
TINYINT(1)	BIT	MySQL and MariaDB store booleans here. Plain TINYINT is numeric — the width is the only thing distinguishing them.
DECIMAL(10,2)	DECIMAL(10,2)
FLOAT	FLOAT	Binary floating point, same rounding caveat as DOUBLE.
DOUBLE	FLOAT(53)	Binary floating point. Money stored in a DOUBLE will round; use DECIMAL end to end.
VARCHAR(255)	NVARCHAR(255)
TEXT	NVARCHAR(MAX)
LONGTEXT	NVARCHAR(MAX)
CHAR(10)	NCHAR(10)
DATE	DATE
DATETIME	DATETIME2
TIMESTAMP	DATETIMEOFFSET	Timezone behaviour differs per engine — a naive target shifts the instant rather than failing.
TIME	TIME	MySQL TIME is a duration spanning -838:59:59 to 838:59:59, not a clock time. Targets with a 24-hour TIME cannot hold the full range.
YEAR	SMALLINT	MySQL-only type. Widened on every other engine.
BLOB	VARBINARY(MAX)
JSON	NVARCHAR(MAX)	JSON is stored and indexed very differently per engine; queries against it will need rewriting.
ENUM('a','b')	NVARCHAR(255)	Value list is kept as a CHECK constraint where the target supports one.
SET('a','b')	NVARCHAR(MAX)	No equivalent outside MySQL and MariaDB. The value list is preserved but the constraint is not.

Example: MariaDB to SQL Server schema conversion

MariaDB

CREATE TABLE orders (
  id            INT AUTO_INCREMENT PRIMARY KEY,
  customer_id   INT NOT NULL,
  status        ENUM('new','paid','shipped') NOT NULL DEFAULT 'new',
  total         DECIMAL(10,2) NOT NULL,
  is_gift       TINYINT(1) NOT NULL DEFAULT 0,
  notes         TEXT,
  metadata      JSON,
  placed_at     DATETIME NOT NULL
);

SQL Server

IF OBJECT_ID(N'orders', 'U') IS NULL
CREATE TABLE [orders] (
    [id] INT NOT NULL,
    [customer_id] INT NOT NULL,
    [status] NVARCHAR(255),
    [total] DECIMAL(10,2) NOT NULL,
    [is_gift] BIT,
    [notes] NVARCHAR(MAX),
    [metadata] NVARCHAR(MAX),
    [placed_at] DATETIME2 NOT NULL,
    CONSTRAINT [PK_orders] PRIMARY KEY ([id])
);

Moving to SQL Server usually means moving to a Microsoft stack

This direction is less common than the reverse and is normally driven by consolidation: an application is being absorbed into an estate that already runs SQL Server, Active Directory and reporting built on SSRS or Power BI. The database move is one part of a larger integration, which means the deadline is usually set by something other than the database.

The practical consequence is that the target schema is often not yours to design. Naming conventions, schema placement and audit columns may be dictated by the receiving estate, so plan for a mapping step rather than a direct copy.

Where MariaDB is more permissive than SQL Server

MariaDB accepts a great deal that SQL Server rejects. Zero dates such as 0000-00-00 are valid in MariaDB and impossible in SQL Server. Implicit conversion between strings and numbers is routine in MariaDB and an error in SQL Server. GROUP BY with unaggregated columns in the select list is permitted by MariaDB's default configuration and rejected outright by SQL Server.

Each of those is a data problem, not a schema problem, which means it surfaces during the load rather than during conversion. Zero dates in particular need a decision before the migration: they become NULL, a sentinel date, or the row is quarantined. Making that choice in advance is much cheaper than discovering it a third of the way through a load.

Unsigned integers are the other gap. MariaDB has them and SQL Server does not, so an unsigned column has to widen to the next larger signed type to keep values above the signed maximum. A BIGINT UNSIGNED holding values near its ceiling has no lossless destination and needs DECIMAL(20,0).

Storage engines and what does not come across

MariaDB storage engines have no SQL Server counterpart. Tables on MyISAM have no transactions and no foreign keys, so a schema that used MyISAM may have relationships that were never enforced and data that does not satisfy them. Those orphans appear when foreign keys are applied on the target.

MariaDB's own extensions, notably Aria, Sequence and Spider engines, and its system-versioned tables, are MariaDB-specific. System-versioned history is queryable data that a plain table copy will not bring along, so decide explicitly whether the history is being migrated or dropped.

MariaDB → SQL Server 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.
IDENTITY_INSERT is managed per table so explicit IDs from the source load correctly, then counters are reseeded with DBCC CHECKIDENT.
Binary columns always carry an explicit length — bare VARBINARY (which means 1 byte) never reaches the target.
TRUNCATE falls back to DELETE on FK-referenced tables automatically.

Frequently asked questions

Is MariaDB to SQL Server migration production-ready in DBShifts?

MariaDB to SQL Server is a live-verified beta pair: it passed the same certification suite as every other pair — a real migration with edge-case data validated by row counts and checksums — and ships with a post-migration fidelity report you can audit before cutover.

How does DBShifts verify the MariaDB to SQL Server 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 SQL Server 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 SQL Server 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 SQL Server?

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's the hardest part of moving MariaDB to SQL Server?

Type-system mismatches that fail silently rather than loudly — MariaDB's edge-case types (3 engine-specific rules apply) converting into SQL Server's nearest equivalent. DBShifts's deterministic mapping records every downgrade in the fidelity report, so a value that clips, rounds, or widens is visible before cutover, not after.

Which MariaDB data types change when moving to SQL Server?

9 of the mapped types convert to something that cannot represent exactly the same range or constraint. The clearest cases are TINYINT(1) to BIT, FLOAT to FLOAT, DOUBLE to FLOAT(53). The full table above lists every mapping the converter performs, and analysis flags each one on your actual schema before any data moves.

Go deeper

How We Live-Certified All 49 Migration Paths

The certification harness behind this page's claims.

Why Row Counts Aren't Enough

How type-aware checksum validation works.

Related migration paths

MySQLSQL Server MariaDBMySQL MariaDBMariaDB MariaDBPostgreSQL MariaDBOracle MariaDBSQLite

Ready to move MariaDB to SQL Server?

Set up in under two minutes. Validation and rollback included.

Start Free Migration