-
Identity columns.
Maps MySQL AUTO_INCREMENT to SQL Server
IDENTITY and reseeds the target with
DBCC CHECKIDENT above the loaded maximum key
value — so the application's next insert does not
collide.
-
Type mapping.
Treats MySQL TINYINT(1) as a SQL Server
BIT candidate in the type-mapping review (or
keeps it TINYINT when it stores integer codes),
maps utf8mb4 VARCHAR to
NVARCHAR, DATETIME(6) to
DATETIME2(6), time-zoned TIMESTAMP
to DATETIMEOFFSET, and routes
JSON to NVARCHAR(MAX) with SQL
Server's JSON functions as the access path. ENUM
/ SET become a lookup table or
CHECK constraint per your policy.
-
Schemas and identifiers.
Rewrites MySQL backtick-quoted names (`order`)
into SQL Server bracket form ([order]), and
lands objects in dbo by default — or in a
custom schema if you pick that policy in the wizard before
the load.
-
Views translation — two-way.
Translates view definitions and supported queries between
MySQL and SQL Server in both directions during the migration
— one of the three native two-way-translation pairs
(MySQL ↔ SQL Server, MySQL ↔ Oracle, SQL Server
↔ Oracle).
-
Stored procedures, triggers, and functions — outside DBConvert's scope.
DBConvert's migration covers tables (with their fields,
types, defaults, and indexes), views, and foreign keys.
MySQL stored procedures, functions, and triggers stay in
the source and are rewritten manually in T-SQL —
T-SQL has a different procedural model (no
DELIMITER, different error handling, different
cursors). Typically a small fraction of the schema, but
the one item the tool does not handle.
-
Application SQL portability.
MySQL-specific syntax (LIMIT/OFFSET,
INSERT...ON DUPLICATE KEY UPDATE,
GROUP_CONCAT, IFNULL, backtick
identifiers, collation-driven case-insensitive
LIKE) does not run unchanged on SQL Server.
DBConvert moves the schema and data; the application SQL
layer is its own task — usually a search-and-replace
pass plus a test cycle.
