Take the go or no-go on signed lines, and move write authority at one recorded instant

Chapter 33 wrote each wave's window and stop criterion before the first wave, and Chapter 34 ended with every line of the wave's acceptance record signed by the owner of what it protects. This chapter spends both: the decision to point people at the new estate, the timed sequence that does it, and the instant after which going back stops being a refusal to start. Chapter 36 owns the way back after that instant, and Chapter 37 the days that follow it.

Who says go, on what evidence, and at which instant does write authority move?

The decision this chapter leads to is go or no-go for one wave's cutover, taken on the day by the decider Chapter 1 named, against criteria written before the wave.

Which cutovers this chapter is for

First, and in most depth, a SharePoint Server 2016 or 2019 farm attached to Subscription Edition as Chapter 23 sets out. The new farm keeps every address, so this cutover moves an address from one farm to another. A copy into SharePoint Online changes every address and moves none; Chapter 9 already holds its sequence, and a short section near the end says what differs.

On an attach, this chapter starts from a state other chapters produced. The 2016 or 2019 content databases have been read-only since before their backup (Chapter 23). Every database behind the address is attached to the Subscription Edition farm with Chapter 23's three readings clean. The full crawl has run, and the validators have tested at the real addresses from their own machines (Chapter 34). Nothing here repairs any of that: a cutover that begins with a repair belongs to a wave nobody accepted.

What must already be signed

The previous values matter more than they look. Each runbook step has a way back, and a way back is a value somebody wrote down while the old state still existed.

The go or no-go

One person decides. We recommend that the decider is not the person running the runbook, has a named deputy, and takes the decision at a roll call whose time is in the calendar entry. The decider reads the signed lines, never a summary of them (Chapter 34), and four more things:

The decision is written down with its time, the name of who took it and the evidence read. A no-go at the roll call changes nothing in either farm. It costs the window, and it starts a second decision that is not this chapter's: whether the 2016 or 2019 farm stays read-only until a new date or is reopened to writes, which the rollback plan's owner takes under Chapter 36.

What Microsoft documents about the switch, and what it does not

Microsoft's Subscription Edition upgrade pages end at the verified attach. The overview's last administrator step before site collections is that the administrator "confirms that the upgrade is successful" (overview of the upgrade process, checked on 10 November 2026). None of the four phase pages describes pointing people at the new farm.

The nearest text is on Microsoft's page for installing an update by database attach, which applies to SharePoint Server 2013 to Subscription Edition: "Enable the new farm as the production farm by configuring DNS to point to the new farm or by making sure that the new farm is load balanced. Verify that users can access the new farm", then "Allow time for users to switch from cached DNS, and then decommission the old farm". A note in the same procedure says its steps 4 through 13, these two among them, "do not apply" to SharePoint Server 2016, 2019 and Subscription Edition (install a software update, checked on 10 November 2026). The 2013 guidance asks you to coordinate with the network teams "especially if you must switch DNS to point to your new farm" (communication plan for 2013, checked on 10 November 2026), and applies to 2013 only.

So Microsoft does not document the address move for an upgrade to Subscription Edition. The runbook below is our recommendation, assembled from the pages that document each of its parts, and every part carries its source. Rehearse it as a whole before you trust it.

The runbook for an attach to Subscription Edition

Every duration is yours: time each step in Chapter 31's rehearsal and write it beside the step. We give none, because none would be reproducible on your farm. Print the table; each row takes the time it was done and the initials of who did it.

Step 2: the final state of the databases

Microsoft's overview has the administrator set the 2016 or 2019 farm "to read-only so that users can continue to access the old farm while upgrade is in progress on the new farm" (overview, above). At cutover you change none of it. You read it, on both sides:

Sources for the table: copy databases to the new farm, which says "Don't set search databases to read-only at this point" and "You do not have to back up the configuration or admin content databases", upgrade content databases, and upgrade service applications, whose steps are "Pause the Search service application", set its administration database read-only for the copy, and later "Resume the Search service application in the SharePoint Server environment", all checked on 10 November 2026. The second row is Chapter 33's consequence: a term, profile or stored credential changed on the old farm after the service databases were copied stays there unless somebody re-enters it.

On the old farm's SQL Server, read each content database. The example is illustrative and was not run against a farm:

-- Old farm's SQL Server (2016 or 2019). Reads only: it changes nothing.
SELECT [name], user_access_desc, is_read_only FROM sys.databases
WHERE [name] = '<ContentDatabaseName>';

Expected: is_read_only is 1. The query is the one Microsoft's reference gives to verify the option, and it defines READ_ONLY as "Users can read data from the database but not modify it" (ALTER DATABASE SET options, checked on 10 November 2026); in SQL Server Management Studio the same fact is "Database Read-Only" set to True (copy databases, above). A read-only content database also sets its site collections read-only, unless they were at No Access, and people see it: "A statement at the top of the home page states that the site is read-only" (run a farm that uses read-only databases, checked on 10 November 2026). That statement is the cheapest way to tell which farm a browser has reached.

Step 3: the new farm's readings

Illustrative, not run against a farm:

# New farm (Subscription Edition). Reads only: it changes nothing.
$url = "https://<address>"
Write-Host "Reading the databases, mappings and certificates of $url. Nothing is changed."
Get-SPContentDatabase -WebApplication $url | ft Name, NeedsUpgradeIncludeChildren
Get-SPAlternateURL -WebApplication $url
Get-SPCertificate -InUse -DaysToExpiration 30

Expected, in order: every database false; the mappings Chapter 23 built, equal to the list taken from the old farm; and nothing, since the last line returns certificates "that are in use and will expire within the next 30 days". The cmdlets are documented at Get-SPContentDatabase, Get-SPAlternateURL, Get-SPCertificate and Write-Host, all checked on 10 November 2026; Get-SPCertificate exists on Subscription Edition only.

The mappings decide what address the farm writes into its own pages. Microsoft asks for the default zone's public URL to be "a domain URL that is appropriate for all users to see", because otherwise "the names of web servers or their IP addresses might be displayed", and it requires the mappings wherever a load balancer sits in front. Host-named site collections "can't use alternate access mappings", and for them "the URL of the request must not be changed between the user and the server" (plan alternate access mappings, checked on 10 November 2026). For those, the address to move is every host name in Chapter 12's list, one record each.

On Subscription Edition a certificate assigned to a web application sits in SharePoint's own store with its private key (assign certificates to web applications), and SSL connections succeed only when "the entire certificate chain, from the end entity (leaf) certificate to the root certificate" was imported (import certificates, both checked on 10 November 2026). Where a load balancer ends the SSL connection instead, the certificate is that device's, and no SharePoint page covers it.

Do not repair a binding here. Microsoft states that "you can't use IIS Manager or other IIS metabase tools to modify the bindings" of a SharePoint web application, and that changing them means unextending and reextending it (update a web application URL and IIS bindings, checked on 10 November 2026). A wrong binding found at step 3 is a no-go.

Step 4: lock the new farm before the address moves

Microsoft does not describe this step in an upgrade; it is our recommendation. Once the address moves, anybody whose machine has the new answer can write on the new farm, before a single check has run. A read-only lock on every site collection closes that gap. Microsoft's description of it is "Prevents users from adding, updating, or deleting content" (manage the lock status for site collections, checked on 10 November 2026). People who arrive early see what the old farm showed them, a site they can read.

Illustrative, not run against a farm:

# New farm (Subscription Edition). Locks every site collection that is unlocked now.
$url = "https://<address>"
Write-Host "Site collections already read-only on $url, to leave as they are afterwards"
Get-SPSite -WebApplication $url -Limit All -Filter {$_.LockState -eq "ReadOnly"} | Format-Table -Property Url
Write-Host "What the lock would change"
Get-SPSite -WebApplication $url -Limit All -Filter {$_.LockState -eq "Unlock"} | Set-SPSite -LockState ReadOnly -WhatIf
# Read both lists into the cutover record. Then run the last line again without -WhatIf.

-Filter runs on the server and accepts LockState, whose values are Unlock, NoAdditions, ReadOnly and NoAccess; -Limit All matters because the default returns 200 site collections (Get-SPSite and Set-SPSite, checked on 10 November 2026). The first list is the one to keep: a site that was read-only before the cutover, for a reason of its own, is locked again by hand after step 9.

Microsoft does not document what a read-only lock does to a workflow in flight, a timer job or a crawl. We do not know, and the rehearsal is where you find out. If you choose not to lock, the instant of step 9 moves up to step 6, and the minute-after checks run with people already able to write.

Steps 5 to 7: move the address

The service principal name. Where a web application signs people in with Kerberos (Chapter 21) and the new farm's application pool runs under a different account, the name registered for the address has to follow. A given SPN belongs to "only one account", and when the account changes "the SPNs must be re-registered under the new account" (service principal names, checked on 10 November 2026). Left on the old account, the server "can't decrypt the ticket" and the person is denied; setspn -Q <SPN> reads which account holds it (SPN on the wrong account, checked on 10 November 2026). No Microsoft page says when, in an upgrade, to move it. We would move it here, next to the address, and rehearse it.

The record or the pool. The network owner changes the DNS record to the new farm's address, or replaces the old farm's servers with the new ones behind the load balancer's existing address. Which of the two applies is a fact about your network, recorded with the previous values. Then ask each DNS server directly. Illustrative, not run:

# Any domain-joined machine. Reads only.
$name = "<host name of the address>"
Write-Host "Asking each DNS server for $name, by DNS alone and without the hosts file"
Resolve-DnsName -Name $name -Type A -Server "<DnsServer1>" -DnsOnly -NoHostsFile
Resolve-DnsName -Name $name -Type A -Server "<DnsServer2>" -DnsOnly -NoHostsFile

Expected: the new farm's address from every server (Resolve-DnsName, checked on 10 November 2026). Clients follow later. Microsoft's own text allows "time for users to switch from cached DNS" and gives no figure (install a software update, above). We would ask the DNS owner, days before, how long a changed record takes to reach every desk, and plan the second message around the answer.

The validators' entries. Chapter 34 pointed the validators' machines at the new farm by a recorded name-resolution entry, to be removed at cutover. Remove each one now: the client's resolver cache holds "entries preloaded from the local Hosts file", ipconfig /displaydns shows it and ipconfig /flushdns empties it (ipconfig, checked on 10 November 2026). A machine that keeps its entry will keep working whatever DNS says, and will hide a failed move from the person best placed to see it.

Step 8: the minute after

All of these are reads, because the farm is still locked. Each has an expected result, and one that differs sends the runbook back through steps 6, 5 and 4.

• From a machine with no name-resolution entry, a named user of each sign-in method opens the root site and one site in every content database. Expected: each opens, without the read-only statement of the old farm, and the new farm's web servers log the request.
• The same users try to add an item. Expected: refused, by the lock.
• The readings of step 3, again. Expected: unchanged.
• Chapter 34's search queries, by the people who ran them. Expected: the same results, each trimmed to what that person may open.
• A link from Chapter 12's list and a bookmark saved on the old farm. Expected: both open, since the address is the one Microsoft tells you to keep: with a different URL, "all bookmarks to the old URLs will not work" (upgrade content databases, above).

Steps 9 and 10: the instant, and the first writes

On the decider's word, the farm administrator runs step 4's last line with the two states exchanged, -Filter {$_.LockState -eq "ReadOnly"} into Set-SPSite -LockState Unlock, first with -WhatIf and then without, locks again the sites of step 4's first list, and writes down the time. That time is the cutover: the instant Chapter 9 asks for, at which write authority moves. The 2016 or 2019 farm stays read-only from then on.

Then the first writes, by the people Chapter 34 named: a test item created and read back, a new instance of a kept workflow, and each integration switched to the new farm by the owner of its other end (Chapter 22). Chapter 9 says a cutover is the day integrations switch, never the day they are first tried.

Tell people twice

Chapter 9 sends two messages, and on an attach the first went out before the read-only period began. Microsoft asks you to "set expectations for tasks that users can complete on the site" while it is read-only (run a farm that uses read-only databases, above). The second goes at step 11, after the first writes, and we would keep it to five facts:

• the sites are open for work again, from a stated time;
• the address has not changed, and bookmarks and links still work;
• what looks or behaves differently, taken from the pilot's questions (Chapter 31);
• anyone who still sees the read-only statement has reached the old farm: close the browser, try again later, and call if it persists;
• who to call, and until when the migration team is on hand (Chapter 37).

Microsoft's 2013 guidance lists the same subjects, when the upgrade happens, how it affects people and "How to obtain help", and wants the helpdesk to "know about the timing for the upgrade" and be "prepared for questions after upgrade" (communication plan for 2013, above). That page covers 2013 only; the advice has outlived the version.

Where a no-go ends and a rollback begins

Before the instant, every step has its way back in its own row. Taking one is a stop, not a rollback: the new farm has accepted no business write, which is the first of Chapter 9's states, and the old farm never stopped being the place the content lives. What the stop leads to is Chapter 36's: Microsoft's 2013 page says you can "restore the read-only farm to read-write and restore access to users while you rework your plans" (determine strategy for upgrade to 2013, checked on 10 November 2026), and the Subscription Edition page keeps the backups so that the data is "in a safe state if you must enable the original farm again" (copy databases, above).

After the instant, there is no step back in this chapter. Every return is a rollback under Chapter 36, in whichever of Chapter 9's states the new farm's own logs establish. This chapter hands it four things: the recorded instant, the previous value of every step, the list of who could write since, and a 2016 or 2019 farm nobody has touched.

One interval needs saying aloud, because the two chapters meet in it. Between steps 6 and 9 the address has moved and the instant has not come: people can reach the new farm and nobody can write on it. A stop there is still a stop, and its way back is this runbook's.

Before the recorded instant, a stop is a no-go. After it, the only way back is a rollback, and somebody else's work is inside it.

Common failures

The New-SPAlternateURL reference was checked on 10 November 2026.

Risks and limits

• The sequence is ours. Microsoft documents each part and not the whole. A step that behaves differently on your farm is a finding of the rehearsal, and the rehearsal's version wins.
• One address, one farm. Chapter 33 found no documented way to serve one address from two farms, so every database behind an address crosses in the same cutover.
• The lock's side effects are not established. See step 4.
• Cached names outlast the runbook. For as long as some machines resolve the old farm, people there read a farm that is going stale. It is read-only, so they lose no work; they can still act on an old document.
• Service data has a gap. Whatever changed in terms, profiles or stored credentials since the copy is re-entered by hand or lost, and the list is only as good as whoever kept it.
• Nothing here brings an upgraded database back. Chapter 9 records that we have found nothing establishing that it can return to 2016 or 2019. The fallback is the untouched old farm.

A copy into SharePoint Online: what differs

Chapter 9 holds this sequence, and this chapter's go or no-go applies to it unchanged. What differs is the act:

• No address moves. Every address changes, so there is no DNS record, mapping, certificate or service principal name to move. The work is Chapter 12's address map, the redirects and the second message, which carries the new addresses.
• The source closes; the destination was never locked. Microsoft describes "a cutover event in which you disable SharePoint Server team sites" and directs users to the new environment, and recommends "a single cutover event for all users" (team sites migration guide, checked on 10 November 2026). It does not say how to disable them. Chapter 9 uses the read-only lock on the 2016 or 2019 site collections, never No Access, and Chapter 33 chose between one cutover and one per wave.
• The instant is the message. The source is already read-only for the final delta and the verification. We would treat the moment people are told the new address as the instant write authority moves, and record that time.
• The minute after checks that redirects resolve, that named people open the new sites, and that integrations switched. Chapter 8's record against the final state came before the decision, not after it.

What is true when it is over

The cutover ends when these hold, and Chapter 37 begins from them:

• one estate accepts writes, since one recorded time;
• the 2016 or 2019 farm, or the source sites of a copy, is read-only, untouched and still running. Microsoft's update procedure ends by decommissioning the old farm; this book does not, and Chapter 38 decides when;
• the cutover record holds the decision, the runbook with its times and initials, every reading before and after, both messages and the previous values;
• the rollback option is open until the expiry its plan wrote, and Chapter 36 has what it needs to use it;
• each acceptance line left not established, performance under real load being the usual one, has its owner and its date inside hypercare.

Out of scope

The rollback procedure and its rehearsal are Chapter 36; hypercare is Chapter 37 and decommissioning Chapter 38. Building the web applications, their mappings and their sign-in is Chapters 23 and 21, and accepting the wave Chapter 34. Configuring a particular load balancer, DNS product or certificate authority, cutting over services other than SharePoint, and zero-downtime designs are not covered.

Before you continue

• The go or no-go criteria, the decider and a deputy were written before the wave, and the decision is recorded with its time and the evidence read
• The decider read the signed lines, the stop criterion, the window remaining, the last rollback rehearsal and the roll call
• Every runbook step has an owner, a check, a way back and a duration timed in the rehearsal
• The old content databases read as read-only, the new ones as read-write and upgraded, and every service data change since the copy is listed
• The previous DNS record or pool, the mappings, the service principal names and the lock states were recorded before any step
• The address moved with the new farm locked, and every check of the minute after gave its expected result from a machine with no name-resolution entry
• Write authority moved at one recorded instant, on the decider's word, and the old farm stayed read-only
• People were told twice, and Chapters 36 and 37 received the cutover record

Download chapter 35 (PDF)Same text, same tables, same sources as this page.