A Migration Cutover Checklist

The data copy can be perfect and the application can still fail at cutover. A migration cutover checklist keeps the small dependencies visible when the clock gets loud. Put the decision owner, validation steps, and reversal point on one page.

Name the Go or No-Go Owner on the Migration Cutover Checklist

Before the window, assign one person to make the go or no-go call and one person to record evidence. Name application, database, network, and business validators. Give each a specific task and a contact path. Define what stops the cutover, what can be fixed within the window, and when the team reverses. An unowned call is a meeting, not a decision.

I read the stop conditions aloud during rehearsal. Which failure would make you refuse the switch even if the database is online? Put that answer in the migration cutover checklist. A cutover is easier when the team does not invent the acceptance standard after seeing a problem.

Freeze Writes and Take the Final Backup

Set a clear source write freeze or a tested method for capturing changes after the initial copy. Confirm the time and the application state. Take the final database and log backups required by the recovery model and migration path. Verify the backup files and record their names. Do not treat a backup job success message as proof that the target can restore the files.

I keep the final backup and restore sequence in exact order. If a log backup is missing, the chain cannot be guessed into place. Preserve the source until target validation and the rollback point are settled. The freeze notice should tell users what they can still read and when writes resume.

Move Server-Level Dependencies

Check logins and database user mappings, SQL Server Agent jobs, credentials, linked servers, Database Mail, certificates, and server configuration required by the application. These objects do not all travel in a user database backup. Test each under the identity that will use it. A job that exists but points at the old server is still a cutover defect.

The query below lists enabled jobs on the connected instance. Compare target jobs with the approved inventory, not just with the source count. I check schedules and owners too. A job that starts tomorrow can be the first place a forgotten dependency appears.

SELECT
    name,
    enabled,
    SUSER_SNAME(owner_sid) AS OwnerName
FROM msdb.dbo.sysjobs
ORDER BY name;

Check External Connections on the Migration Cutover Checklist

Inventory linked servers, external data sources, file shares, service endpoints, and reports that refer to the old location. Verify authentication from the target host. Check firewall and DNS changes with the network owner before the window. A DNS update has caching behavior. Test from the application host rather than assuming the new record is already in use.

I ask for a connection test that reports the target instance, database, and login. A successful ping is not that test. The query below can run through the application connection after the switch. Keep its output with the cutover log.

SELECT
    @@SERVERNAME AS ConnectedInstance,
    DB_NAME() AS CurrentDatabase,
    ORIGINAL_LOGIN() AS LoginName,
    SERVERPROPERTY('ProductVersion') AS ProductVersion;

Apply the Final Sync

Restore or apply the final change set according to the rehearsed method. For backup and log restores, confirm the chain and recovery state before bringing the database online. For another replication or synchronization method, record the last applied point and compare source and target under the same cutoff. Stop the source write path before users can create two divergent copies.

I do not run an untested extra cleanup script at this stage. If a schema fix is required, it belongs in the rehearsed plan with its own validation. The cutover window is a poor place to discover what an old maintenance script actually does.

Switch Clients Deliberately

Change the application connection string, listener, DNS name, or routing configuration in the documented order. Restart or recycle clients that hold pooled connections where needed. Test from each major application host. Check that background workers and scheduled jobs use the new endpoint too. A front-end screen can reach the target while a queue processor still writes to the source.

I record the exact switch time and the observed endpoint from the client. If the test reaches the wrong server, stop before allowing new writes. The server name in a configuration file is less useful than the server name returned by an actual application connection.

Validate Business Work

Run prewritten checks for critical records, recent changes, writes, reports, and scheduled tasks. Compare results against the source snapshot or cutoff used for the migration. Check data values and keys, not only row totals. Have the business validator perform one normal workflow and sign off on the result. Record failures with owner and resolution.

I keep a short priority order for validation. The payment or order path should not wait behind a cosmetic report. Once the critical checks pass, expand to broader monitoring. If the source and target disagree, pause new writes until the team understands whether the difference is expected lag, a missed change, or a transformation error.

Make the Final Decision Visible on the Migration Cutover Checklist

At the agreed point, the owner records go or no-go with evidence: backup, final sync, client target, critical tests, and open issues. If no-go, follow the rehearsed reversal procedure and account for any target writes. If go, keep heightened monitoring through the next business cycle. Do not delete the source or backups as part of the applause.

A migration cutover checklist is useful because it preserves small facts under time pressure. Put the current timestamp and the person who signed each gate beside the check mark. I update it after every rehearsal and real cutover. The next migration then starts with a better list, not with a story about how the last one felt. Keep the signed decision and validation outputs together so later support can reconstruct the exact switch.

Related reading on this blog: What is Tail-Log Backups? and Query to List All Jobs with Owners.

A cutover is not the moment DNS changes, it is the point when data and users work on the verified target.

Published by Pinal Dave on SQLAuthority. More of my work at pinaldave.com.