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.

Guide

Guide~11 min readUpdated 19 Apr 2026

Share

LinkedInXEmail
  1. 01What has to move in a SQL Server migration
  2. 02How to plan a SQL Server migration
  3. 03SQL Server migration types and scenarios
  4. 04SQL Server migration method options
  5. 05SQL Server migration inventory checks
  6. 06SQL Server migration security checks
  7. 07SQL Server migration job and dependency checks
  8. 08SQL Server migration backup and restore preparation
  9. 09SQL Server migration cutover and rollback plan
  10. 10SQL Server migration validation after cutover
  11. 11What not to change during a SQL Server migration
  12. 12When to get SQL Server migration support

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.

SELECT
    SERVERPROPERTY('MachineName') AS machine_name,
    SERVERPROPERTY('ServerName') AS server_name,
    SERVERPROPERTY('InstanceName') AS instance_name,
    SERVERPROPERTY('Edition') AS edition,
    SERVERPROPERTY('ProductVersion') AS product_version,
    SERVERPROPERTY('ProductLevel') AS product_level,
    SERVERPROPERTY('ProductUpdateLevel') AS product_update_level,
    SERVERPROPERTY('EngineEdition') AS engine_edition,
    @@VERSION AS 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.

LayerWhat it answers
SourceWhat exists today: databases, files, logins, jobs, linked servers, and dependencies.
Move methodHow data stays current until cutover and how long the final switch takes.
TargetWhether the new server can run the workload, jobs, backups, and monitoring.
RollbackWhen 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 itemWhat it decides
Source and target versionsWhether this is migration only, upgrade only, or both.
Downtime windowWhether backup and restore is enough or the target must stay nearly current.
Size and change rateHow long copy, restore, final log restore, and validation may take.
Rollback requirementHow long the source must remain usable after cutover.
Application switch methodWhether connection strings, DNS, aliases, listeners, firewall rules, or scheduled tasks must change.
Validation ownerWho 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.

1

The scripts below assume access to SQL Server instance-level catalog views and msdb.

2

SQL Server on a VM is still an instance migration; Azure SQL Database and other managed platforms may need different tooling and checks.

3

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.

01

Side-by-side server move

Use this when databases move from one SQL Server to another server on the same or similar version.

  1. 1Build the target instance with the required collation, drives, service accounts, patch level, and network access.
  2. 2Script or migrate logins, jobs, linked servers, credentials, operators, alerts, and connection aliases.
  3. 3Restore a test run copy, fix file paths with RESTORE WITH MOVE, and compare jobs, backups, and application access.
  4. 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.
02

Version upgrade migration

Use this when the move also changes SQL Server version.

  1. 1Confirm the supported upgrade path, target edition, compatibility-level plan, deprecated features, and driver support.
  2. 2Restore or migrate to a test target first, then run application checks and important jobs before the real window.
  3. 3Enable or review Query Store so important queries can be compared before and after cutover.
  4. 4Keep rollback realistic: once a database is upgraded, it cannot be restored back to an older SQL Server version.
03

Platform migration

Use this when SQL Server moves to a VM, cloud-hosted server, managed SQL platform, or different operating system.

  1. 1Check feature support first: SQL Agent behavior, cross-database use, linked servers, CLR, SSIS, file access, and backup options may change.
  2. 2Plan identity, firewall rules, DNS, private networking, encryption, storage latency, and monitoring before copying data.
  3. 3Test backup and restore, native tooling, or export/import against the target platform with production-like size.
  4. 4Rewrite operations that depended on the old server, such as local file paths, maintenance jobs, alerts, and manual restore habits.
04

Datacenter, hosting, or storage move

Use this when SQL Server stays broadly the same but the location, virtualization, storage, or hosting changes.

  1. 1Match CPU, memory, storage layout, tempdb, backup throughput, and I/O latency before the move.
  2. 2Prepare DNS, aliases, firewall rules, monitoring routes, backup destinations, and maintenance windows.
  3. 3Run a restore test run on the target storage and measure restore time, CHECKDB time, and backup time.
  4. 4Keep a failback path until application traffic, jobs, backups, and monitoring are stable in the new location.
05

Consolidation or split

Use this when several databases move onto fewer servers, or one crowded instance is split apart.

  1. 1Group databases by workload, owner, maintenance window, recovery needs, collation, security model, and application dependency.
  2. 2Check CPU, memory, tempdb, storage, SQL Agent schedules, backup windows, and licensing before deciding the target layout.
  3. 3Move a test run group first and look for job collisions, naming conflicts, linked-server assumptions, and noisy-neighbor workload patterns.
  4. 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.

MethodUse it whenRollback concern
Backup and restoreThe 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 shippingThe 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 pathHA design and version support allow a seeded target and controlled role change.Confirm failback or source reuse behavior before the role change.
Migration toolAssessment, 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.

SELECT
    d.name AS database_name,
    d.state_desc,
    d.recovery_model_desc,
    d.compatibility_level,
    d.is_read_only,
    SUSER_SNAME(d.owner_sid) AS database_owner,
    CONVERT(decimal(18,2), SUM(mf.size) * 8.0 / 1024.0) AS size_mb,
    COUNT(mf.file_id) AS file_count
FROM sys.databases AS d
JOIN sys.master_files AS mf
    ON mf.database_id = d.database_id
WHERE d.name NOT IN (N'master', N'model', N'msdb', N'tempdb')
GROUP BY
    d.name,
    d.state_desc,
    d.recovery_model_desc,
    d.compatibility_level,
    d.is_read_only,
    d.owner_sid
ORDER BY size_mb DESC;

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.

SELECT
    DB_NAME(mf.database_id) AS database_name,
    mf.file_id,
    mf.type_desc,
    mf.name AS logical_file_name,
    mf.physical_name,
    CONVERT(decimal(18,2), mf.size * 8.0 / 1024.0) AS size_mb,
    CASE
        WHEN mf.is_percent_growth = 1 THEN CONCAT(mf.growth, N'%')
        ELSE CONCAT(CONVERT(decimal(18,2), mf.growth * 8.0 / 1024.0), N' MB')
    END AS growth_setting,
    CASE
        WHEN mf.max_size = -1 THEN N'Unlimited'
        ELSE CONCAT(CONVERT(decimal(18,2), mf.max_size * 8.0 / 1024.0), N' MB')
    END AS max_size
FROM sys.master_files AS mf
WHERE DB_NAME(mf.database_id) NOT IN (N'master', N'model', N'msdb', N'tempdb')
ORDER BY database_name, mf.type_desc, mf.file_id;

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.

SELECT
    sp.name AS login_name,
    sp.type_desc,
    sp.is_disabled,
    sp.default_database_name,
    sp.create_date,
    sp.modify_date,
    STUFF((
        SELECT N', ' + role_principal.name
        FROM sys.server_role_members AS srm
        JOIN sys.server_principals AS role_principal
            ON role_principal.principal_id = srm.role_principal_id
        WHERE srm.member_principal_id = sp.principal_id
        ORDER BY role_principal.name
        FOR XML PATH(''), TYPE
    ).value(N'.', N'nvarchar(max)'), 1, 2, N'') AS server_roles
FROM sys.server_principals AS sp
WHERE sp.type IN ('S', 'U', 'G')
  AND sp.name NOT LIKE N'##MS_%'
ORDER BY sp.is_disabled, sp.type_desc, sp.name;

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.

SELECT
    DB_NAME() AS database_name,
    dp.name AS database_user,
    dp.type_desc,
    dp.authentication_type_desc,
    dp.default_schema_name,
    sp.name AS matching_server_login
FROM sys.database_principals AS dp
LEFT JOIN sys.server_principals AS sp
    ON sp.sid = dp.sid
WHERE dp.type IN ('S', 'U', 'G')
  AND dp.sid IS NOT NULL
  AND dp.name NOT IN (N'dbo', N'guest', N'INFORMATION_SCHEMA', N'sys')
  AND sp.sid IS NULL
ORDER BY dp.name;

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.

SELECT TOP (150)
    j.name AS job_name,
    SUSER_SNAME(j.owner_sid) AS job_owner,
    j.enabled,
    s.name AS schedule_name,
    s.enabled AS schedule_enabled,
    h.run_status AS last_run_status,
    DATETIMEFROMPARTS(
        h.run_date / 10000,
        (h.run_date % 10000) / 100,
        h.run_date % 100,
        h.run_time / 10000,
        (h.run_time % 10000) / 100,
        h.run_time % 100,
        0
    ) AS last_run_start_time,
    ((h.run_duration / 10000) * 3600)
      + (((h.run_duration % 10000) / 100) * 60)
      + (h.run_duration % 100) AS last_run_duration_seconds,
    h.message AS last_run_message
FROM msdb.dbo.sysjobs AS j
LEFT JOIN msdb.dbo.sysjobschedules AS js
    ON js.job_id = j.job_id
LEFT JOIN msdb.dbo.sysschedules AS s
    ON s.schedule_id = js.schedule_id
OUTER APPLY (
    SELECT TOP (1)
        h.run_date,
        h.run_time,
        h.run_duration,
        h.run_status,
        h.message
    FROM msdb.dbo.sysjobhistory AS h
    WHERE h.job_id = j.job_id
      AND h.step_id = 0
      AND h.run_date > 0
    ORDER BY h.run_date DESC, h.run_time DESC
) AS h
ORDER BY j.enabled DESC, j.name, s.name;

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.

SELECT
    N'Linked server' AS object_type,
    s.name AS object_name,
    s.product,
    s.provider,
    s.data_source,
    CONVERT(nvarchar(4000), NULL) AS extra_detail
FROM sys.servers AS s
WHERE s.is_linked = 1

UNION ALL

SELECT
    N'Credential' AS object_type,
    c.name AS object_name,
    CONVERT(nvarchar(128), NULL) AS product,
    CONVERT(nvarchar(128), NULL) AS provider,
    CONVERT(nvarchar(4000), NULL) AS data_source,
    c.credential_identity AS extra_detail
FROM sys.credentials AS c

UNION ALL

SELECT
    N'Server trigger' AS object_type,
    tr.name AS object_name,
    CONVERT(nvarchar(128), NULL) AS product,
    CONVERT(nvarchar(128), NULL) AS provider,
    CONVERT(nvarchar(4000), NULL) AS data_source,
    CASE WHEN tr.is_disabled = 1 THEN N'Disabled' ELSE N'Enabled' END AS extra_detail
FROM sys.server_triggers AS tr
ORDER BY object_type, object_name;

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.

WITH LastBackups AS (
    SELECT
        bs.database_name,
        bs.type,
        MAX(bs.backup_finish_date) AS last_backup_finish_date
    FROM msdb.dbo.backupset AS bs
    WHERE bs.type IN ('D', 'I', 'L')
    GROUP BY bs.database_name, bs.type
)
SELECT
    d.name AS database_name,
    d.recovery_model_desc,
    d.state_desc,
    MAX(CASE WHEN lb.type = 'D' THEN lb.last_backup_finish_date END) AS last_full_backup,
    MAX(CASE WHEN lb.type = 'I' THEN lb.last_backup_finish_date END) AS last_differential_backup,
    MAX(CASE WHEN lb.type = 'L' THEN lb.last_backup_finish_date END) AS last_log_backup
FROM sys.databases AS d
LEFT JOIN LastBackups AS lb
    ON lb.database_name = d.name
WHERE d.name <> N'tempdb'
GROUP BY d.name, d.recovery_model_desc, d.state_desc
ORDER BY d.name;

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.

SELECT TOP (100)
    rh.destination_database_name,
    rh.restore_date,
    rh.restore_type,
    rh.replace,
    rh.recovery,
    bs.database_name AS source_database_name,
    bs.backup_start_date,
    bs.backup_finish_date,
    bmf.physical_device_name
FROM msdb.dbo.restorehistory AS rh
LEFT JOIN msdb.dbo.backupset AS bs
    ON bs.backup_set_id = rh.backup_set_id
LEFT JOIN msdb.dbo.backupmediafamily AS bmf
    ON bmf.media_set_id = bs.media_set_id
ORDER BY rh.restore_date DESC;

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.

-- Template only. Replace names, paths, and MOVE targets.
-- Restore every required backup in order before using WITH RECOVERY.
-- Confirm target storage, permissions, and file paths before the test run.

RESTORE DATABASE YourDatabase
FROM DISK = N'\\fileserver\sqlbackups\YourDatabase_full.bak'
WITH MOVE N'YourDatabase' TO N'D:\SQLData\YourDatabase.mdf',
     MOVE N'YourDatabase_log' TO N'L:\SQLLogs\YourDatabase.ldf',
     NORECOVERY,
     CHECKSUM;

-- Optional: restore the latest useful differential backup after the full backup.
RESTORE DATABASE YourDatabase
FROM DISK = N'\\fileserver\sqlbackups\YourDatabase_diff.bak'
WITH NORECOVERY,
     CHECKSUM;

-- Restore each required log backup in sequence, keeping the database restoring.
RESTORE LOG YourDatabase
FROM DISK = N'\\fileserver\sqlbackups\YourDatabase_log_001.trn'
WITH NORECOVERY,
     CHECKSUM;

RESTORE LOG YourDatabase
FROM DISK = N'\\fileserver\sqlbackups\YourDatabase_log_002.trn'
WITH NORECOVERY,
     CHECKSUM;

-- Restore the final log backup with RECOVERY only when cutover is ready.
RESTORE LOG YourDatabase
FROM DISK = N'\\fileserver\sqlbackups\YourDatabase_final.trn'
WITH RECOVERY,
     CHECKSUM;

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.

-- Template only for a staged log-restore cutover.
-- Use only after test run and after confirming the final synchronization point.

-- 1. Freeze application writes.
-- 2. Take the final source log backup.
BACKUP LOG YourDatabase
TO DISK = N'\\fileserver\sqlbackups\YourDatabase_final.trn'
WITH CHECKSUM;

-- 3. Restore the final log on the target.
RESTORE LOG YourDatabase
FROM DISK = N'\\fileserver\sqlbackups\YourDatabase_final.trn'
WITH RECOVERY,
     CHECKSUM;

-- 4. Switch connections.
-- 5. Run validation.
-- 6. Decide go, rollback, or hold.

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.

Cutover checklist skeleton

1. Confirm source freeze and change window start.
2. Confirm latest backup or final log backup completed.
3. Restore final backup on target and recover the database.
4. Switch application connection strings, DNS, aliases, or listener routing.
5. Validate logins, jobs, linked servers, backups, monitoring, and critical workflows.
6. Decide go or rollback before the agreed decision time.
7. Keep source protected until rollback and retention windows have passed.

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.

SELECT TOP (50)
    qt.query_sql_text,
    q.query_id,
    p.plan_id,
    rs.count_executions,
    CAST(rs.avg_duration / 1000.0 AS decimal(18,2)) AS avg_duration_ms,
    CAST(rs.avg_cpu_time / 1000.0 AS decimal(18,2)) AS avg_cpu_ms,
    CAST(rs.avg_logical_io_reads AS decimal(18,2)) AS avg_logical_reads,
    rs.last_execution_time
FROM sys.query_store_runtime_stats AS rs
JOIN sys.query_store_plan AS p
    ON p.plan_id = rs.plan_id
JOIN sys.query_store_query AS q
    ON q.query_id = p.query_id
JOIN sys.query_store_query_text AS qt
    ON qt.query_text_id = q.query_text_id
ORDER BY rs.avg_duration DESC;

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.

1

Applications connect to the target using the intended connection path.

2

Critical workflows, reports, and batch jobs complete on the target.

3

Backups, monitoring, alerts, and maintenance jobs are active on the target.

4

Linked servers, external credentials, and reporting paths work from the target.

5

Query Store, wait stats, and error logs do not show immediate post-cutover regressions.

6

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.

1

Do not treat database restore as the whole migration.

2

Do not move databases without logins, jobs, linked servers, credentials, certificates, and connection strings.

3

Do not assume backup and restore works backward to older SQL Server versions.

4

Do not use production as the first full migration test run.

5

Do not switch applications before target backups, monitoring, jobs, and validation are ready.

6

Do not use log shipping or AG seeding without a clear final synchronization and rollback plan.

7

Do not clean up the source server until rollback and retention windows have passed.

8

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.