Migrate SQL Server to MongoDB

SQL Server vs MongoDB

SQL Server

Microsoft's enterprise relational database.

MongoDB

the leading document database.

How the migration works

How values land in MongoDB

MongoDB has no fixed schema, so there's no column-type table to show — this is what actually happens to each value on the way in.

• DECIMAL and MONEY values are stored as exact Decimal128, never a lossy float.
• DATE columns with no time component land as a BSON date at midnight UTC — BSON has no date-only type.
• TIME-only values are stored as an ISO-8601 string — BSON has no time-only type.
• DATETIME / DATETIME2 columns become native BSON dates.
• Each row becomes one document — there's no fixed collection schema to map into, so this is about value fidelity, not a type-mapping table.

Example: SQL Server to MongoDB conversion

CREATE TABLE users (
  id INT IDENTITY(1,1) PRIMARY KEY,
  name NVARCHAR(255) NOT NULL,
  is_active BIT DEFAULT 1,
  created_at DATETIME2 DEFAULT SYSUTCDATETIME()
);

{
  id: 1,
  name: "Ada Lovelace",
  is_active: true,
  created_at: ISODate("2026-01-15T10:30:00Z")
}

SQL Server → MongoDB conversion notes

Engine-specific rules baked into the conversion and transfer pipeline — verified by live certification of this exact pair.

• TINYINT is unsigned (0–255) in SQL Server — DBShifts widens it on signed targets so 128–255 don't clip.
• UNIQUEIDENTIFIER, DATETIMEOFFSET, MONEY and NVARCHAR(MAX) all have explicit conversion rules per target.
• Wrapped defaults like ((1)) and (N'foo') are unwrapped to portable literals.
• Rows become flat documents; write errors surface loudly instead of being swallowed by duplicate-tolerance settings.
• Integers beyond BSON's 8-byte range (e.g. Oracle NUMBER) become Decimal128 to stay exact.
• Dates are stored as native BSON dates (UTC instants).

Frequently asked questions

Go deeper

Related migration paths