Chapter 24 · Upgrades, Compatibility Levels, Migration, Cloud/Hybrid Paths, and Change Management

Database Migration Assistant Concepts, Backup/Restore Moves, Log Shipping/AG Cutovers, and Validation

Use current SSMS migration assessment plus rehearsed backup/restore, log shipping, or AG cutovers with explicit validation and rollback criteria.

Advanced180–260 minutesMigration rehearsal + cutover validation labSQL Server 2025 CU7 · 17.0.4065.4Target compatibility 170 · staged labSSMS 22.8.2 · Last reviewed August 2026

Learning outcomes

ServiceHub has chosen a side-by-side target. The next question is not “which migration wizard?” but which data movement and cutover mechanism meets downtime, RPO/RTO, reversibility and validation requirements. Tool names change; the underlying mechanisms—assessment, backup/copy/restore, log replay, AG synchronization, login transfer and application redirection—are the stable mental model.

01

Use the current SSMS migration component for SQL Server-to-SQL Server assessment/migration rather than relying on retired or mismatched tooling guidance.

02

Distinguish SQL Server Migration Assistant (SSMA) heterogeneous-source conversion from SQL Server version-upgrade migration.

03

Perform a safe local copy-only backup/verify/restore rehearsal and validate the copied ServiceHub database.

04

Compare backup/restore, log shipping and Availability Group cutovers by downtime and rollback semantics.

05

Define cutover acceptance criteria that include data, security, application connectivity and operations—not just restore completion.

Lab baseline. SQL Server 2025 (17.x), CU7 build 17.0.4065.4; compatibility level 170 is the target, but several labs deliberately stage at level 160 to demonstrate compatibility-controlled change. SSMS 22.8.2 is the checked Windows administration tool; current VS Code + MSSQL extension and current sqlcmd are valid free alternatives. Azure Data Studio is retired. Mandatory work uses a free non-production SQL Server 2025 Developer edition or Express where the feature exists and a disposable database named ServiceHubUpgradeLab. The current SQL Server-to-SQL Server upgrade workflow is the migration component in SSMS 21+; current SSMS 22.8.2 includes the Hybrid and Migration workload. SSMA is for heterogeneous sources such as Access, Db2, MySQL, Oracle and SAP ASE.

1. Tool names change; classify the migration task first

Older guidance often says “run DMA.” Current Microsoft guidance for SQL Server-to-SQL Server upgrades uses the migration component in SQL Server Management Studio. It performs compatibility/feature-parity assessment and can execute a backup-copy-restore style move plus eligible login transfer. SQL Server Migration Assistant (SSMA) is a different family intended to convert heterogeneous sources to SQL Server/Azure SQL. For Azure targets, the current SSMS migration experience can recommend Azure SQL targets and orchestrate appropriate services, but the on-premises SQL-to-SQL backup/copy workflow itself is not the same as an Azure SQL Database migration.

Do not choose a migration path because an old screenshot says DMA. Start from source/target, downtime, data size, network, HA topology, key material and rollback requirements, then use the currently supported tool that implements the needed mechanism.

2. Rehearse backup/restore locally before the real cutover

A restore rehearsal tests more than “can BACKUP finish?” It validates media readability, target file paths, database recovery, integrity checks and application-level invariants. The following lab creates a copy-only backup in the instance's default backup directory, restores it under a new name on the same instance, verifies row counts and then drops only the disposable copy.

sql · ensure the source lab exists
USE master;GOIF DB_ID(N'ServiceHubUpgradeLab') IS NULLBEGIN    CREATE DATABASE ServiceHubUpgradeLab;END;GOALTER DATABASE ServiceHubUpgradeLab SET COMPATIBILITY_LEVEL = 160;ALTER DATABASE ServiceHubUpgradeLab SET QUERY_STORE = ON(    OPERATION_MODE = READ_WRITE,    QUERY_CAPTURE_MODE = AUTO,    WAIT_STATS_CAPTURE_MODE = ON);GOUSE ServiceHubUpgradeLab;GOIF SCHEMA_ID(N'lab24') IS NULL EXEC(N'CREATE SCHEMA lab24 AUTHORIZATION dbo;');GOIF OBJECT_ID(N'lab24.WorkOrder', N'U') IS NULLBEGIN    CREATE TABLE lab24.WorkOrder    (        work_order_id bigint IDENTITY(1001,1) NOT NULL CONSTRAINT PK_lab24_WorkOrder PRIMARY KEY,        customer_id int NOT NULL,        region_code char(3) NOT NULL,        status varchar(16) NOT NULL,        priority tinyint NOT NULL,        opened_at datetime2(0) NOT NULL,        description nvarchar(300) NULL,        row_version rowversion NOT NULL,        CONSTRAINT CK_lab24_WorkOrder_Status CHECK(status IN ('OPEN','ASSIGNED','CLOSED','ESCALATED')),        CONSTRAINT CK_lab24_WorkOrder_Priority CHECK(priority BETWEEN 1 AND 5)    );    ;WITH n AS    (        SELECT TOP (12000) ROW_NUMBER() OVER (ORDER BY (SELECT NULL)) AS rn        FROM sys.all_objects a CROSS JOIN sys.all_objects b    )    INSERT lab24.WorkOrder(customer_id,region_code,status,priority,opened_at,description)    SELECT        CASE WHEN rn <= 5000 THEN 42 ELSE 100 + (rn % 2000) END,        CASE rn % 3 WHEN 0 THEN 'N01' WHEN 1 THEN 'W02' ELSE 'E03' END,        CASE rn % 4 WHEN 0 THEN 'OPEN' WHEN 1 THEN 'ASSIGNED' WHEN 2 THEN 'CLOSED' ELSE 'ESCALATED' END,        1 + (rn % 5),        DATEADD(minute,-rn,'2026-08-20T12:00:00'),        N'ServiceHub migration lab row ' + CONVERT(nvarchar(20),rn)    FROM n;    CREATE INDEX IX_lab24_WorkOrder_CustomerStatus      ON lab24.WorkOrder(customer_id,status,opened_at)      INCLUDE(region_code,priority);END;GO
sql · copy-only backup, verify and same-instance restore rehearsal
USE master;GODECLARE @sep nchar(1) = CASE WHEN CONVERT(nvarchar(4000),SERVERPROPERTY('InstanceDefaultBackupPath')) LIKE N'%' + NCHAR(92) + N'%' THEN NCHAR(92) ELSE N'/' END;DECLARE @backup nvarchar(4000) = CONVERT(nvarchar(4000),SERVERPROPERTY('InstanceDefaultBackupPath')) +    CASE WHEN RIGHT(CONVERT(nvarchar(4000),SERVERPROPERTY('InstanceDefaultBackupPath')),1) IN (NCHAR(92),N'/') THEN N'' ELSE @sep END +    N'ServiceHubUpgradeLab_ch24.bak';BACKUP DATABASE ServiceHubUpgradeLabTO DISK = @backupWITH COPY_ONLY, INIT, CHECKSUM, STATS = 10;RESTORE VERIFYONLY FROM DISK = @backup WITH CHECKSUM;DECLARE @data_logical sysname, @log_logical sysname;SELECT @data_logical = name FROM ServiceHubUpgradeLab.sys.database_files WHERE type = 0;SELECT @log_logical  = name FROM ServiceHubUpgradeLab.sys.database_files WHERE type = 1;DECLARE @data_root nvarchar(4000)=CONVERT(nvarchar(4000),SERVERPROPERTY('InstanceDefaultDataPath'));DECLARE @log_root  nvarchar(4000)=CONVERT(nvarchar(4000),SERVERPROPERTY('InstanceDefaultLogPath'));DECLARE @datafile nvarchar(4000)=@data_root + CASE WHEN RIGHT(@data_root,1) IN (NCHAR(92),N'/') THEN N'' ELSE @sep END + N'ServiceHubUpgradeLab_Copy.mdf';DECLARE @logfile  nvarchar(4000)=@log_root  + CASE WHEN RIGHT(@log_root,1)  IN (NCHAR(92),N'/') THEN N'' ELSE @sep END + N'ServiceHubUpgradeLab_Copy_log.ldf';IF DB_ID(N'ServiceHubUpgradeLab_Copy') IS NOT NULLBEGIN    ALTER DATABASE ServiceHubUpgradeLab_Copy SET SINGLE_USER WITH ROLLBACK IMMEDIATE;    DROP DATABASE ServiceHubUpgradeLab_Copy;END;DECLARE @q nchar(1)=NCHAR(39);DECLARE @sql nvarchar(max) =N'RESTORE DATABASE ServiceHubUpgradeLab_Copy FROM DISK = N' + @q + REPLACE(@backup,@q,@q+@q) + @q +N' WITH MOVE N' + @q + REPLACE(@data_logical,@q,@q+@q) + @q + N' TO N' + @q + REPLACE(@datafile,@q,@q+@q) + @q +N', MOVE N' + @q + REPLACE(@log_logical,@q,@q+@q) + @q + N' TO N' + @q + REPLACE(@logfile,@q,@q+@q) + @q +N', RECOVERY, STATS = 10;';EXEC sys.sp_executesql @sql;GOSELECT DB_NAME() AS source_db, COUNT_BIG(*) AS work_orders FROM ServiceHubUpgradeLab.lab24.WorkOrder;SELECT N'ServiceHubUpgradeLab_Copy' AS restored_db, COUNT_BIG(*) AS work_orders FROM ServiceHubUpgradeLab_Copy.lab24.WorkOrder;DBCC CHECKDB(N'ServiceHubUpgradeLab_Copy') WITH NO_INFOMSGS;GO

RESTORE VERIFYONLY is useful but does not replace an actual restore plus integrity and business checks. This rehearsal also proves that target file paths and permissions work. For TDE-protected databases, the target must have the protector certificate/asymmetric key before restore can succeed.

3. Cutover mechanisms by downtime and orchestration

Mechanism Pre-seeding Cutover Rollback concern
Backup/restore Full backup can be rehearsed; final downtime often includes final backup/transfer/restore Stop writes, final backup, restore/recover, redirect clients Do not allow divergent writes on both sides
Log shipping Full + continuous log backups/copy/restore Stop writes, final/tail log as appropriate, restore with recovery, redirect clients Manual orchestration; reverse direction requires a deliberate plan
Availability Group Database synchronizes to target replica Validate synchronized state, fail over under supported mode, redirect/listener behavior Topology/edition/cluster requirements; forced failover can lose data

Log shipping is intentionally simple DR/data movement and has no automatic listener-style application redirection. AG cutover can reduce data-movement downtime but adds endpoint, cluster, edition and failover-mode prerequisites. Neither mechanism removes the need to migrate instance-level dependencies or test the application.

4. Wrong approach: “the restore completed, therefore migration succeeded”

A database can restore cleanly while the application fails because a login SID differs, a credential is missing, the certificate chain is incomplete, an Agent job still points to the old server, the driver rejects the target certificate, or a connection string still resolves the source. Build a migration manifest with explicit evidence.

sql · target-side post-restore validation evidence
SELECT    SERVERPROPERTY('ServerName') AS server_name,    SERVERPROPERTY('ProductVersion') AS product_version,    SERVERPROPERTY('Edition') AS edition;SELECT name, compatibility_level, state_desc, recovery_model_descFROM sys.databasesWHERE name IN (N'ServiceHubUpgradeLab',N'ServiceHubUpgradeLab_Copy');SELECT COUNT_BIG(*) AS copied_rows,       CHECKSUM_AGG(BINARY_CHECKSUM(customer_id,region_code,status,priority,opened_at)) AS business_checksumFROM ServiceHubUpgradeLab_Copy.lab24.WorkOrder;SELECT sp.name AS login_name, sp.sidFROM sys.server_principals AS spWHERE sp.type_desc IN ('SQL_LOGIN','WINDOWS_LOGIN','WINDOWS_GROUP')ORDER BY sp.name;

Checksums are only one coarse comparison signal; they are not cryptographic proof of application equivalence. Combine row/domain invariants, DBCC integrity, key objects, authorization, scheduled operations, backup jobs, connectivity and representative application transactions.

5. Cleanup and production judgment

sql · remove only the rehearsal target; keep the source lab for later lessons
USE master;GOIF DB_ID(N'ServiceHubUpgradeLab_Copy') IS NOT NULLBEGIN    ALTER DATABASE ServiceHubUpgradeLab_Copy SET SINGLE_USER WITH ROLLBACK IMMEDIATE;    DROP DATABASE ServiceHubUpgradeLab_Copy;END;GO-- The .bak file is intentionally not deleted by T-SQL.-- Remove it later using an approved OS/storage retention process after verification.

For production, choose the simplest mechanism that satisfies downtime and reversibility. Rehearse the exact sequence with realistic data size and network/storage limits, capture the duration of each phase, and decide when the source becomes read-only and when it may be decommissioned. The migration component can accelerate assessment and transfer; it cannot decide your business-consistency boundary.

Check your understanding

  1. What is the current Microsoft tool for SQL Server-to-SQL Server upgrade assessment/migration?
  2. What is SSMA primarily for?
  3. Why is RESTORE VERIFYONLY insufficient as the sole migration test?
  4. Why can log shipping reduce cutover data-transfer time?
  5. What must be prevented after cutover?
Review the answers

1. The migration component in current SQL Server Management Studio.

2. Heterogeneous-source migrations such as Access, Db2, MySQL, Oracle or SAP ASE into SQL Server/Azure SQL.

3. It does not prove that a real restore, integrity checks, target paths, security dependencies and application behavior all succeed.

4. The secondary is continuously advanced by restored log backups before the final cutover.

5. Uncontrolled divergent writes to old and new systems without an explicit reconciliation/failback design.

Authoritative references

Keep knowledge open

Help the academy stay free and grow.

If these tutorials save you time, a small donation supports new lessons, technical review, diagrams, examples, and long-term maintenance.

ETHEthereum / ERC-20 only
0x716c4Ab160C4B66F31a28AE2448BfF68fc3a2ef0

Send only Ethereum or ERC-20 compatible assets to this address.