1. T-minus checklist
| When | Task |
|---|---|
| T-14 days | Full rehearsal on a copy; time every step; RTO agreed with the business |
| T-7 | Logins, users, jobs, linked servers, certificates created on the target; firewall and DNS ready |
| T-2 | DNS TTL for the database alias lowered to 60–300 s |
| T-1 | Replication or log shipping healthy and current; change freeze on the app; comms sent |
| T-0 | Bridge call open; roles: cutover lead, DBA, app owner, network, testers |
2. Cutover steps (with times recorded)
- Stop the application (or put it in maintenance mode). Stop SQL Agent jobs that write.
- Confirm no writes:
SELECT * FROM sys.dm_exec_sessions WHERE is_user_process = 1shows nothing from apps. - Final sync, depending on the method:
- MI link / AG: wait for synchronised, then fail over (planned, no data loss).
- LRS / log shipping: take a final tail-log backup (
BACKUP LOG ... WITH NORECOVERYkeeps the source in restoring state, which protects against accidental writes), restore it, recover. - AWS DMS / CDC: wait for CDC latency 0, then stop the task.
- Backup/restore: final differential or log, then restore
WITH RECOVERY.
- Row counts and checksums on key tables (source vs target).
- Switch connections: update the DNS alias / connection strings / Key Vault or Secrets Manager values.
- Start the app against the target; enable jobs on the target.
- Smoke tests by app owners: login, read, write, a report, a batch job.
-- quick row count comparison (run on both sides)
SELECT s.name + '.' + t.name AS tbl, SUM(p.rows) AS rows
FROM sys.tables t JOIN sys.schemas s ON t.schema_id = s.schema_id
JOIN sys.partitions p ON t.object_id = p.object_id AND p.index_id IN (0,1)
GROUP BY s.name, t.name ORDER BY tbl;
3. Go/no-go points
| Point | No-go if |
|---|---|
| Before stopping the app | Sync lag above the agreed limit, or a key team member missing |
| After final sync | Row counts differ on critical tables |
| After smoke tests | Any critical test fails and can't be fixed in 30 minutes |
4. Rollback
Plan this before the night:
- Before the app writes to the target: just point back to the source and start it. (This is why the source stays intact and read-only.)
- After writes to the target: you need reverse sync (MI link with SQL Server 2022 supports failing back; AWS DMS can run a reverse task; otherwise export the changed data). Decide the "point of no return" time with the business.
5. After cutover
- Hypercare for 1–2 weeks: daily performance checks, Query Store regressions (see the validation post).
- Backups on the target verified (restore test).
- Source kept read-only or offline for an agreed period, then decommissioned and its licences released.
Tip
Rehearse with production-sized data. The rehearsal gives you real timings, and almost always finds a missing login, job or firewall rule.