Migrating a highly available instance is not one job, it is two different jobs that people frequently confuse. An Availability Group migration adds replicas and fails over. A Failover Cluster Instance migration builds a new cluster and cuts over. The sequences are different, the rollbacks are different, and the outage profile is different.
The advantage of migrating an AG is that the cutover is a planned failover, measured in seconds. The cost is that everything before it has to be correct.
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.
- Port 5022 between every replica pair, in both directions. The mirroring endpoint is its own listener with its own firewall rule. A new replica that can reach the primary while the primary cannot reach it back will join the AG and then never synchronise.
- The listener itself. Confirm the listener name resolves and answers on its port from the application servers, and in a multi-subnet cluster confirm an IP exists for the subnet the new nodes live in, before the failover rather than during it.
- 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.
Availability Group Migration
Install SQL Server, join the nodes to the Windows Server Failover Cluster, enable the Availability Groups feature and restart, then configure the mirroring endpoint. If the new nodes run a different service account, the endpoint login has to exist on the current primary too.
Back up on the current primary and restore on the new replicas WITH NORECOVERY. This is the long part, and it happens well before any window.
Join them and let synchronisation begin.
Do not proceed on “it looks synchronised”. Check the send and redo queues, because redo queue is what decides how long a failover actually takes.
Confirm the application teams are ready for a brief interruption, update the listener IP first if the new node is in a different subnet, then fail over and verify.
Only after validation. Remove old replicas from the AG, remove old nodes from the cluster, then update external DNS if the listener name is changing.
A health check against the new primary, and a confirmation of replica sync state.
If you are failing over to a node in a different subnet, the listener IP has to be updated before the failover, not after. Clients resolving the listener to an address that no longer hosts it produces a very confusing ten minutes.
Failover Cluster Instance Migration
An FCI migration cannot fail over to a new cluster, so it is a build, sync and cut over instead. Build the new FCI, seed it with a full and differential restore, then keep it current with log shipping while you wait for the window. The window itself is a final log backup, a restore, and a cutover.
That log shipping step is what makes the window short. Without it the whole restore happens inside the outage.
The full version, with every command, is in the repo. Both playbooks, both rollback procedures, and timing estimates for each.
Frequently Asked Questions
Which is less risky, AG or FCI migration?
An AG migration, because the cutover is a planned failover you can reverse by failing back. An FCI cutover is a commitment, which is why its rollback procedure is a separate document rather than a paragraph.
Can I add replicas running a newer SQL Server version?
For a rolling upgrade the direction matters: you upgrade secondaries first, then fail over. What you cannot do is leave a mixed-version AG running as a permanent state.
How do I know synchronisation is really finished?
Look at the redo queue on the secondary rather than at a green health icon. Data that has arrived but not been applied is exactly the data that extends your failover time.
Do I have to update DNS?
Only if the listener name is changing. If it is, do it after validation and remember the TTL, because clients will keep the old record for as long as you told them to.
Clustered migrations borrow most of their steps from the simpler cases. These are the ones they borrow from.
- SQL Server Migration Runbook: Standalone, the standalone version of the same move, and the base procedure.
- SQL Server Version Upgrade Runbook, when the migration is also an upgrade.
- SQL Server Change Management, the change order this belongs to, which matters more the more replicas are involved.
Leave a Reply