Migrate SQL Server to MongoDB
Beta — live-tested pathMigrating from SQL Server (Microsoft's enterprise relational database) to MongoDB (the leading document database) means every table, column type, key, index and row has to survive two engines' different opinions about data. This is a cross-model migration — rows and relations are preserved as structured documents — and the conversion rules are explicit, not guessed. 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.
Free tier · no credit card
SQL Server vs MongoDB
SQL Server
Microsoft's enterprise relational database.
MongoDB
the leading document 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.
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
SQL Server
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() );
MongoDB
{
id: 1,
name: "Ada Lovelace",
is_active: true,
created_at: ISODate("2026-01-15T10:30:00Z")
}One collection per table is the wrong default
The mechanical conversion — each table becomes a collection, each row a document — produces a MongoDB database that is a relational database with the joins removed. Every query that used to be a join becomes several round trips plus application-side assembly, and the result performs worse than the SQL Server it replaced while being harder to reason about.
The decision that actually matters is which relationships to embed and which to reference. An order and its line items are read together, written together and bounded in size: embed them, and one document read replaces a join. A customer and their orders are unbounded and read separately: reference them. Getting this right is the entire migration; the data movement is trivial by comparison.
Decimal survives, but only if you ask for it
MongoDB has a genuine exact decimal type, Decimal128, which maps cleanly from SQL Server's DECIMAL and NUMERIC. It is not the default. A naive conversion sends DECIMAL(10,2) to a double, which is binary floating point, and monetary values acquire rounding tails that were never present in SQL Server.
This is worth stating plainly because the usual advice about NoSQL and money is that you should not, when in fact the type exists and is exact. The failure is in the conversion defaulting to double, not in MongoDB lacking the capability.
Nothing enforces the schema unless you write a validator
SQL Server rejects a row that violates a column type, a NOT NULL, a CHECK or a foreign key. MongoDB accepts whatever the application sends. The constraints in the source schema are not converted into anything, because there is no default place for them to go.
JSON Schema validators are that place, and they cover types, required fields and value ranges. They do not cover referential integrity — there are no foreign keys, so an orphaned reference is an application concern permanently. Deciding which of the source constraints to reimplement as validators, and which to accept losing, should happen before the move rather than after the first bad document.
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
Is SQL Server to MongoDB migration production-ready in DBShifts?
SQL Server to MongoDB 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 SQL Server to MongoDB 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 SQL Server types that MongoDB 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 SQL Server and MongoDB 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 SQL Server to MongoDB?
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 SQL Server to MongoDB?
The data model itself differs (sql → nosql), so rows and relations are restructured into documents with explicit type rules. DBShifts surfaces every inference and lossy conversion in the migration plan before you run, so nothing is guessed silently.
Go deeper
Related migration paths
Ready to move SQL Server to MongoDB?
Set up in under two minutes. Validation and rollback included.
Start Free Migration