SQL Optima guide

Cutover checklists for engine migrations

The boring list that prevents dramatic go-live nights.

SQL diagnosticBackup and log-chain reviewbackup_log_chain.sql
Download .sql
/*
================================================================================
SQL Server Backup Log Chain Integrity
================================================================================
Description:
    Detects breaks in the transaction log backup chain for FULL recovery model
    databases. A broken log chain prevents point-in-time recovery and can make
    restore operations fail after the break point.

Output:
    Sequential log backup listing with LSN ranges, highlighting gaps where
    first_lsn of the next backup does not match last_lsn of the previous backup.

Action:
    If a log chain break is detected (missing LSN continuity), immediately take
    a new full backup followed by regular log backups. Investigate why the break
    occurred — common causes: log backup failure, database switched to SIMPLE
    recovery, or manual log shrink (SHRINKFILE). Run weekly to catch breaks early.

Criticality: Critical
Author:        Ravi Sharma
================================================================================
*/

SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED;
SET NOCOUNT ON;

;WITH LogBackups AS (
    SELECT
        bs.database_name,
        bs.backup_start_date,
        bs.backup_finish_date,
        bs.first_lsn,
        bs.last_lsn,
        bs.database_backup_lsn,
        ROW_NUMBER() OVER (PARTITION BY bs.database_name ORDER BY bs.backup_start_date) AS rn
    FROM msdb.dbo.backupset AS bs
    WHERE bs.type = N'L'
),
ChainCheck AS (
    SELECT
        curr.database_name,
        prev.backup_finish_date AS [Previous_Log_Backup],
        curr.backup_finish_date AS [Current_Log_Backup],
        prev.last_lsn AS [Previous_Last_LSN],
        curr.first_lsn AS [Current_First_LSN],
        CASE
            WHEN prev.last_lsn <> curr.first_lsn THEN N'BREAK'
            ELSE N'OK'
        END AS [Chain_Status]
    FROM LogBackups AS curr
    INNER JOIN LogBackups AS prev
        ON curr.database_name = prev.database_name
       AND curr.rn = prev.rn + 1
)
SELECT
    d.name AS [Database_Name],
    d.recovery_model_desc,
    cc.Previous_Log_Backup,
    cc.Current_Log_Backup,
    cc.Previous_Last_LSN,
    cc.Current_First_LSN,
    cc.Chain_Status
FROM ChainCheck AS cc
INNER JOIN sys.databases AS d ON d.name = cc.database_name
WHERE cc.Chain_Status = N'BREAK'
  AND d.recovery_model_desc = N'FULL'
  AND d.database_id > 4
ORDER BY cc.Current_Log_Backup DESC;

IF @@ROWCOUNT = 0
    PRINT 'No log chain breaks detected in msdb backup history.';

Review the full script and confirm the connected SQL Server instance before execution. The run instructions and output guide appear later in this article.

Diagram for Cutover checklists for engine migrations
Cutover checklists for engine migrations

Migrations fail less from tooling and more from skipped rehearsal.

Baseline latency and top queries, rehearse cutover with schema compare gates, verify backups, and keep a rollback owner. SQLOptima Migration and Monitoring exist to make that checklist measurable.

For SQL Server 2016 → 2022 engagements, use the phase-gated migration checklist and Compat 160 playbook in the handbook:

Why migration cutover deserves a method

The central principle is that a cutover checklist coordinates people, data, applications, validation, and rollback under a limited decision window. A single metric, recommendation, or successful command is not enough. The decision has to connect an observed symptom to a plausible cause, a controlled change, and a result that can be verified under the workload that matters.

Evidence to collect

Use evidence from the same time window whenever possible:

  • replication lag and final synchronization
  • write freeze and connection change
  • business validation and reconciliation
  • rollback time and authority

A practical workflow

  1. Define entry criteria and decision owners.
  2. Rehearse the timed sequence.
  3. Capture evidence at every checkpoint.
  4. Close only after monitoring and business validation stabilize.

Common mistakes

Avoid these shortcuts:

  • using a task list without stop conditions
  • changing scope during the window
  • leaving rollback ownership ambiguous

Verification and completion

Define completion before making the change. Confirm correctness first, then compare latency, throughput, reads, CPU, waits, storage behavior, or recovery time as appropriate for Cutover checklists for engine migrations. Test negative and boundary cases, not only the path expected to succeed. Watch the system long enough to cover the relevant workload pattern.

Download and run the diagnostic

Backup and log-chain review

Download backup_log_chain.sql

Before you run it

  • Review every statement and confirm the connection points to the intended SQL Server database server.
  • Run through a non-production or read-only diagnostic account first when possible.
  • Required access: read access to msdb backup history.
  • Save the output with the server name, database name, collection time, and workload window so another engineer can reproduce the analysis.

What it does

Reviews backup history and log-chain evidence needed before a migration or recovery cutover. The script is diagnostic and does not apply an automatic remediation. Result values still need workload context, a second supporting signal, and a before-and-after comparison.

How to read the output values

Confirm the latest full backup, differential base where used, and uninterrupted log sequence through the planned recovery point. A recent timestamp does not prove restoreability, so retain media locations and complete a restore rehearsal.