- 01What has to move in a SQL Server migration
- 02How to plan a SQL Server migration
- 03SQL Server migration types and scenarios
- 04SQL Server migration method options
- 05SQL Server migration inventory checks
- 06SQL Server migration security checks
- 07SQL Server migration job and dependency checks
- 08SQL Server migration backup and restore preparation
- 09SQL Server migration cutover and rollback plan
- 10SQL Server migration validation after cutover
- 11What not to change during a SQL Server migration
- 12When to get SQL Server migration support
sql server hub / migration guide
SQL Servermigration guide
SQL Server migration can mean moving to another server, platform, operating system, hosting model, or version. The practical job is the same: move the SQL Server setup without losing the pieces that make it work.
Use this guide to review source inventory, file paths, logins, SQL Agent jobs, linked servers, certificates, credentials, backups, monitoring, application switches, and post-cutover validation before the production move.
What has to move in a SQL Server migration
When you move SQL Server, move more than the user databases. Recreate or map the logins, SIDs, jobs, linked servers, credentials, certificates, proxies, backup jobs, monitoring, and application connection paths the workload uses.
The migration plan should produce concrete inventory output, restore output, job history, connection-switch steps, validation results, and a rollback decision point. If those pieces are missing, the database may be online while the service is still not ready.
Source instance version and edition
Reads source instance identity, version, edition, update level, and full version string.
ProductVersion and ProductUpdateLevel identify the exact source build. Edition affects target feature availability and licensing decisions. ServerName and InstanceName help catch alias or connection-string confusion. Use this before deciding whether the work is migration, upgrade, or both.
| Layer | What it answers |
|---|---|
| Source | What exists today: databases, files, logins, jobs, linked servers, and dependencies. |
| Move method | How data stays current until cutover and how long the final switch takes. |
| Target | Whether the new server can run the workload, jobs, backups, and monitoring. |
| Rollback | When to stop and how to return users to the source safely. |
How to plan a SQL Server migration
Plan the move before picking tooling. Start with source and target versions, the downtime window, database size, change rate, rollback requirement, application switch method, and who signs off validation.
This order matters because it separates the move from adjacent changes. A migration can also be an upgrade, storage change, HA change, driver change, or application release. Combining those is sometimes necessary, but each extra change needs a tested reason.
| Planning item | What it decides |
|---|---|
| Source and target versions | Whether this is migration only, upgrade only, or both. |
| Downtime window | Whether backup and restore is enough or the target must stay nearly current. |
| Size and change rate | How long copy, restore, final log restore, and validation may take. |
| Rollback requirement | How long the source must remain usable after cutover. |
| Application switch method | Whether connection strings, DNS, aliases, listeners, firewall rules, or scheduled tasks must change. |
| Validation owner | Who checks database state, application workflows, jobs, backups, monitoring, and rollback timing. |
SQL Server migration types and scenarios
Different SQL Server migrations need different runbooks. A same-version server move, a version upgrade, a platform move, and a consolidation project do not fail in the same places.
These are the common shapes. Real projects often combine two of them, but the checklist should still say which part is a server move, which part is an upgrade, and which part changes the platform.
The scripts below assume access to SQL Server instance-level catalog views and msdb.
SQL Server on a VM is still an instance migration; Azure SQL Database and other managed platforms may need different tooling and checks.
If SQL Agent, linked servers, file-system access, or native backup control changes on the target, treat that as platform redesign work, not a simple restore.
Side-by-side server move
Use this when databases move from one SQL Server to another server on the same or similar version.
- 1Build the target instance with the required collation, drives, service accounts, patch level, and network access.
- 2Script or migrate logins, jobs, linked servers, credentials, operators, alerts, and connection aliases.
- 3Restore a test run copy, fix file paths with RESTORE WITH MOVE, and compare jobs, backups, and application access.
- 4Run the production cutover with a final backup or log backup, switch connections, validate, then keep the source available until rollback is no longer needed.
Version upgrade migration
Use this when the move also changes SQL Server version.
- 1Confirm the supported upgrade path, target edition, compatibility-level plan, deprecated features, and driver support.
- 2Restore or migrate to a test target first, then run application checks and important jobs before the real window.
- 3Enable or review Query Store so important queries can be compared before and after cutover.
- 4Keep rollback realistic: once a database is upgraded, it cannot be restored back to an older SQL Server version.
Platform migration
Use this when SQL Server moves to a VM, cloud-hosted server, managed SQL platform, or different operating system.
- 1Check feature support first: SQL Agent behavior, cross-database use, linked servers, CLR, SSIS, file access, and backup options may change.
- 2Plan identity, firewall rules, DNS, private networking, encryption, storage latency, and monitoring before copying data.
- 3Test backup and restore, native tooling, or export/import against the target platform with production-like size.
- 4Rewrite operations that depended on the old server, such as local file paths, maintenance jobs, alerts, and manual restore habits.
Datacenter, hosting, or storage move
Use this when SQL Server stays broadly the same but the location, virtualization, storage, or hosting changes.
- 1Match CPU, memory, storage layout, tempdb, backup throughput, and I/O latency before the move.
- 2Prepare DNS, aliases, firewall rules, monitoring routes, backup destinations, and maintenance windows.
- 3Run a restore test run on the target storage and measure restore time, CHECKDB time, and backup time.
- 4Keep a failback path until application traffic, jobs, backups, and monitoring are stable in the new location.
Consolidation or split
Use this when several databases move onto fewer servers, or one crowded instance is split apart.
- 1Group databases by workload, owner, maintenance window, recovery needs, collation, security model, and application dependency.
- 2Check CPU, memory, tempdb, storage, SQL Agent schedules, backup windows, and licensing before deciding the target layout.
- 3Move a test run group first and look for job collisions, naming conflicts, linked-server assumptions, and noisy-neighbor workload patterns.
- 4Validate each application separately, because one successful database restore does not mean the combined layout works.
SQL Server migration method options
Pick the SQL Server migration method from downtime, data-change rate, target version, feature use, and rollback needs. Backup and restore is simple and reliable, but it may not fit a short window. Log shipping or staged log restore can reduce final downtime. Availability Group seeding can help when the architecture supports it.
Migration tooling can assess upgrade and compatibility issues and can use backup-copy-restore for supported side-by-side moves. It still needs target readiness, validation, and rollback planning.
| Method | Use it when | Rollback concern |
|---|---|---|
| Backup and restore | The outage window can absorb the final backup, copy, restore, and validation. | Keep the source unchanged until the target is validated. |
| Staged log restore or log shipping | The database is large and the final cutover should apply only the last changes. | Know exactly when source writes stop and when final log restore starts. |
| Availability Group or distributed AG path | HA design and version support allow a seeded target and controlled role change. | Confirm failback or source reuse behavior before the role change. |
| Migration tool | Assessment, backup-copy-restore orchestration, and login transfer help more than hand-built steps. | Tool success still needs target checks and a separate rollback plan. |
SQL Server migration inventory checks
SQL Server migration inventory starts with the databases, but it should not stop there. For the database layer, collect size, recovery model, compatibility level, state, owner, file paths, growth settings, and target storage layout.
File paths matter because restore may try to recreate source paths unless RESTORE WITH MOVE is used. Target drives, folders, permissions, and capacity should be checked before test run.
Database inventory
Lists user databases with state, recovery model, compatibility level, owner, total size, and file count.
size_mb helps estimate copy and restore time. recovery_model_desc decides whether log backups are part of the move. compatibility_level shows whether target behavior may need separate review. Database owner should be valid on the target.
Database file layout and growth
Shows logical names, physical paths, file sizes, growth settings, and max size from sys.master_files.
physical_name identifies source paths that may not exist on the target. logical_file_name is needed for RESTORE WITH MOVE. Percent growth on large files can cause painful growth events. Use this output to map target data, log, and backup locations.
SQL Server migration security checks
Restoring a database does not move the full security model. Server logins, SIDs, default databases, server roles, credentials, proxies, certificates, contained users, and application service accounts need separate review.
SQL logins need SID-aware scripting, and sometimes password-hash-aware scripting, if existing database users must keep matching after restore. Orphaned users are usually a symptom of login and SID mismatch.
The target should not blindly copy every permission from the source. High-impact roles, disabled logins, old service accounts, certificates, keys, contained users, database owners, and application ownership need a deliberate target decision.
Login and server role inventory
Lists SQL, Windows, and group logins with disabled status, default database, and server role membership.
Disabled logins may still need a deliberate target decision. Default databases must exist on the target. Server roles show high-impact security that should not be copied blindly. This SQL Server 2012+ query avoids STRING_AGG so it can run on older migration sources. Use this as a starting login list; SID-preserving login scripts, certificates, and keys need separate handling.
Orphaned user check
Run inside each migrated database to find database users without matching server logins.
matching_server_login should be present for normal login-mapped users. Contained users and special users need interpretation. Orphaned users usually mean the database user SID does not match a target server login SID. Fix mappings before application validation.
SQL Server migration job and dependency checks
SQL Agent often carries backup jobs, ETL, reporting, maintenance, monitoring hooks, cleanup, and application-side work. A database can move successfully while the service fails because jobs did not move, schedules are disabled, or job owners cannot run on the target.
Check job steps as well as job names. CmdExec and PowerShell steps, SSIS packages, proxies, credentials, Database Mail, operators, alerts, file paths, shares, and hard-coded server names often break after the move.
Dependencies also include linked servers, server triggers, report servers, DNS aliases, SQL aliases, firewall rules, drivers, and connection strings. Pair SQL Server inventory with application-owner checks.
SQL Agent jobs, schedules, and recent result
Lists jobs with owner, enabled state, schedule, last run status, duration, and message.
job_owner should exist and be valid on the target. schedule_enabled shows whether the job is expected to run automatically. last_run_status and message identify existing failures before the move. This is a starting inventory, not full SQL Agent migration coverage. Review job steps, proxies, credentials, operators, alerts, Database Mail, and file paths separately.
Linked servers, credentials, and server triggers
Lists common server-level objects that need target-side migration or validation.
Linked servers need provider, login mapping, network, and encryption checks. Credentials may support jobs, proxies, backups, or external access. Server triggers can affect login, DDL, and administrative behavior. This output is not a full dependency map; use it as the SQL Server starting point.
SQL Server migration backup and restore preparation
Backup and restore is usually the simplest SQL Server migration base. Large databases or short outage windows may need staged restores, log shipping, or AG-based seeding so only the final changes are applied during cutover.
Every required backup in the restore chain must be restored in order. A full backup plus one final log backup is not enough if differential or earlier log backups are part of the chain.
Remember the version rule: SQL Server backups restore to the same or newer SQL Server versions, not backward to older versions. That affects rollback design when the target version changes. Use the SQL Server backup guide for log-chain checks and the SQL Server recovery guide for restore sequence planning.
Backup readiness before migration
Shows latest full, differential, and log backups for each database.
last_full_backup is the minimum restore input for most migration test runs. last_log_backup matters for full or bulk-logged recovery model databases. Missing recent backups mean the migration method is not ready. Use the backup guide when log-chain or restore-test quality is unclear.
Restore test run history
Reads recent restore records, source backup times, recovery flag, and physical device name.
restore_date shows whether test run restores have happened recently. destination_database_name should identify test or target restores clearly. physical_device_name confirms which backup files were used. No restore history means the migration may not have been testd on this instance.
Backup and restore migration template
Non-executing template showing full, optional differential, repeated log restores, and final recovery.
MOVE targets must match the target server file layout. NORECOVERY keeps the database ready for the next differential or log restore. Restore all required log backups in LSN order before the final WITH RECOVERY step. CHECKSUM helps validate backup handling during restore. Replace every path and logical file name before use.
SQL Server migration cutover and rollback plan
The final window needs a written sequence: freeze writes, take final backup or final log backup, restore or recover the target, switch connections, validate, and decide go or rollback before the decision time.
Rollback also needs details: the decision time, source write state, DNS or alias reversal, user communication, and delayed source cleanup. Do not let rollback become a meeting held after the outage window is already gone.
Staged log-restore cutover template
Non-executing template for final log backup, final restore, connection switch, validation, and decision point.
The source freeze must be confirmed before the final log backup. WITH RECOVERY brings the target online after the final restore. The connection switch should be testd, not invented during the window. Rollback should have a decision time, not an open-ended debate.
Cutover checklist skeleton
Plain checklist structure for the production switch and rollback decision.
Each step needs an owner and expected duration. The rollback decision belongs before the outage window is exhausted. Source cleanup should happen later, after rollback risk is acceptable. Validation should include SQL Server checks and application checks.
SQL Server migration validation after cutover
SQL Server migration validation should cover database online state, login and application access, critical workflows, SQL Agent jobs, backups, monitoring alerts, linked servers, Query Store, waits, and error logs. The target should not be called live just because the database is online.
Query Store helps when it has a useful baseline before cutover and the same workload runs after cutover. Capture the important queries before the move, capture the same business window on the target, then compare duration, CPU, reads, execution counts, and plans.
Query Store workload candidates
Lists high-duration Query Store rows to choose candidates for before-and-after migration comparison.
This query does not compare source and target by itself. avg_duration_ms and avg_cpu_ms identify candidates worth capturing before cutover. avg_logical_reads helps spot access-path or storage-sensitive queries. last_execution_time confirms whether the query is currently relevant. Compare the same workload window after cutover before calling performance stable.
Applications connect to the target using the intended connection path.
Critical workflows, reports, and batch jobs complete on the target.
Backups, monitoring, alerts, and maintenance jobs are active on the target.
Linked servers, external credentials, and reporting paths work from the target.
Query Store, wait stats, and error logs do not show immediate post-cutover regressions.
Source rollback remains available until the agreed retention point.
What not to change during a SQL Server migration
Migration windows create pressure to fix old pain at the same time. Keep the move boring unless the extra change has already been tested as part of the migration plan.
Do not treat database restore as the whole migration.
Do not move databases without logins, jobs, linked servers, credentials, certificates, and connection strings.
Do not assume backup and restore works backward to older SQL Server versions.
Do not use production as the first full migration test run.
Do not switch applications before target backups, monitoring, jobs, and validation are ready.
Do not use log shipping or AG seeding without a clear final synchronization and rollback plan.
Do not clean up the source server until rollback and retention windows have passed.
Do not change compatibility level, indexes, MAXDOP, parameter settings, or application drivers during the move unless tested as part of the migration.
When to get SQL Server migration support
SQL Server migration support makes sense when the cutover window is tight, the database is large, the target version changes, dependencies are not fully mapped, or rollback has not been testd.
Send source and target version output, database inventory, file layout, login list, job history, linked server list, backup history, restore output, planned cutover window, and the validation checklist.
Next step
If the inventory, cutover, or rollback plan is not ready yet, use the SQL Server upgrade support page or request migration support above.
Next useful reads: the SQL Server upgrade guide for version changes, the SQL Server backup guide for restore inputs, the SQL Server recovery guide for rollback planning, and the SQL Server monitoring guide for post-move checks.
