Migrate SQL Server to SQL Server
Certified — live-tested pathSame-engine SQL Server migrations are how you move between hosts, clouds, or versions — and they still fail in the boring ways: half-copied tables, stale sequences, missing indexes. DBShifts moves the schema and every row, defers constraints for speed, reseeds counters, and proves the result with row counts and checksums.
Free tier · no credit card
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.
Compatibility level, and the cardinality estimator
A same-version move is a copy. A version upgrade is not, and the reason is the compatibility level of the restored database. Restoring an old database onto a new instance keeps its original compatibility level, so the upgrade appears to work and none of the new optimizer behaviour applies. Raising it afterwards is the real cutover.
The specific hazard is the cardinality estimator rewritten in compatibility level 120. Plans that were stable for years can change, and the change is not uniformly an improvement — a minority of queries regress badly. This is the single most common cause of an upgrade that is reported as slow, and it is why the level should be raised deliberately, with Query Store capturing plans before and after, rather than as an afterthought.
Orphaned users, every time
Logins live at the server level; users live inside the database and reference a login by SID. Restore or attach the database on a different instance and those SIDs no longer resolve, so the users are orphaned: they exist, they own objects, and nobody can log in as them.
The application then fails to connect with a login error that looks like a password problem and is not. Remapping with ALTER USER ... WITH LOGIN takes seconds once you know, and the fix belongs in the runbook, because it will happen on every single move between instances.
If the target is Azure SQL Database, the constraints change
Azure SQL Database is not a hosted copy of the engine. There is no SQL Server Agent, so scheduled jobs need elastic jobs or an external scheduler. Cross-database queries do not work, so any three-part name reaching into another database has to be restructured. USE is not supported in the way scripts expect.
These are architectural, not syntactic, and they are the reason an on-premises to Azure SQL move is a genuine migration while an on-premises to Azure SQL Managed Instance move is much closer to a lift. Establish which of the two the target actually is before estimating anything.
SQL Server → SQL Server 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.
Frequently asked questions
Is SQL Server to SQL Server migration production-ready in DBShifts?
Yes — SQL Server to SQL Server is a certified pair. It passed DBShifts's live certification suite (schema conversion, data transfer, row counts, type-aware checksums over an edge-case fixture) and is battle-tested in production use.
How does DBShifts verify the SQL Server 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 SQL Server 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 SQL Server 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 SQL Server 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 changes in a same-engine SQL Server migration?
Structurally nothing changes — types map one-to-one. The risks are operational: half-copied tables, sequences left pointing at 1, and indexes that never got rebuilt. DBShifts reseeds counters to MAX(id)+1, defers then rebuilds constraints and indexes, and proves the copy with row counts and checksums.
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.
Reference
Compared with other tools
Errors you may hit
Related migration paths
Ready to move SQL Server to SQL Server?
Set up in under two minutes. Validation and rollback included.
Start Free Migration