Moving a standalone SQL Server instance to new hardware is the most common migration there is, and the one most often done from memory. The databases are the easy part. What catches people is everything around them: logins that arrive with new SIDs, Agent jobs nobody scripted, a target server left on defaults, and a firewall rule discovered at two in the morning.
This runbook front-loads the work. By the time the maintenance window opens, the target is configured, the artifacts are generated, and the window itself is backup, restore, validate.
Network Pre-Flight
Run these days before the window, from the machines that will actually make the connections. Every check here is a five-second test that has, at some point, cost somebody their maintenance window.
- Port 1433 to the target from the source server, from every application server, and from your own workstation:
Test-NetConnection new-server -Port 1433. A named instance needs its fixed port instead, plus UDP 1434 if clients rely on the Browser service. Walkthrough: testing remote port connectivity with PowerShell. - Port 445 to the backup share, from both sides. The source writes the backups and the target restores them, so test the share from each server, not just the one you happen to be logged into.
- Firewall rules in both directions on the new host. Inbound 1433 is the rule everyone remembers; outbound to the backup share, monitoring, and any linked servers is the one that turns up mid-window. Reference: SQL Server default ports.
- Line of sight from the applications, before cutover. Every app server and VM that will connect must reach the target before the window opens, tested from those machines rather than from the DBA workstation. A connection that fails at pre-flight is a task; the same failure after cutover is an incident.
- After cutover: DNS and SPNs. Repoint the CNAME and respect the TTL, because clients keep the old record for exactly as long as you told them to. Then re-register the SPNs for the new host so Kerberos keeps working; miss that and connections either fall back to NTLM quietly or fail with the pre-login handshake error.
The Phases
Run against the source while there is still time to act on what it finds. This is the phase that turns surprises into decisions.
Match sp_configure settings to the source, configure TempDB properly rather than accepting installer defaults, create the backup share, and verify firewall and connectivity end to end.
Login scripts with SIDs preserved, Agent job scripts, linked servers. Generated before the window, reviewed before the window.
Set the backup path, run the generated script, and note the timestamp. The timestamp is what tells you later whether a database came from the right backup.
Configure and run the restore script, then confirm every database actually came online rather than assuming the absence of errors means success.
Logins first, then Agent jobs. Order matters: a job that runs as a login which does not exist yet fails in a way that looks like a job problem.
Recreating a SQL login by name gives it a new SID, so the database user it should map to is orphaned and the login appears to have no access. Script the logins with their original SIDs, and keep Fix Orphaned Users to hand for anything that still does not line up.
What To Check Before You Call It Done
- Every database is online, and at the compatibility level you intended rather than the one it arrived with
- Logins map to their database users, with no orphans left
- Agent jobs exist, are enabled, and are scheduled, which are two different states
- Linked servers resolve, and someone has checked whose credentials they run as
- The configuration on the target matches the source where it should, and differs only where you decided it should
The full version, with every command, is in the repo. It includes the per-server checklist and the exact scripts for each phase.
Frequently Asked Questions
How long before the window should Phase 0 run?
Days, not hours. The whole point of a pre-migration assessment is that you can still act on what it finds. Running it the morning of the window turns findings into problems.
Do I need to match sp_configure exactly?
Match it deliberately rather than exactly. Copy the settings that reflect decisions someone made, and take the opportunity to fix the ones that were only ever defaults, like MAXDOP or max server memory on a server that has since grown.
What is most often forgotten?
Agent jobs and linked servers, then database mail and credentials. The data moves because moving it is the obvious task; the surroundings move because someone made a list. Add certificates to that list: if anything is TDE-protected or backup-encrypted, the certificate has to be restored on the target before the database restore will even start.
Can I use this for a version upgrade at the same time?
Yes, and that is the recommended way to upgrade. Restore onto a newer version on new hardware, which gives you a rollback that consists of pointing back at the old server.
A standalone move is the simplest shape this job takes. These are the versions of it you meet next.
- SQL Server Migration Runbook: Availability Groups and Clusters, the same move when the instance is clustered or in an AG.
- SQL Server Version Upgrade Runbook, when the move is also a version change.
- SQL Server Change Management, the paperwork and the rollback plan around the window.
Leave a Reply