Microsoft describes hybrid in two ways. One page calls it "a staged migration path" (Hybrid for SharePoint Server, checked on 13 November 2026). Another says you can configure the features "to improve your users' experience during a migration from on-premises to the cloud, or you can use them in the long term if you plan to continue using SharePoint Server" (hybrid OneDrive and SharePoint, checked on 13 November 2026). Both are legitimate. A feature that is neither, switched on for a migration that ended and still holding a trust open, is not.
For each hybrid feature this farm runs, is it there to stay or there to bridge a move, what ends it, and can you take it out in the documented order?
The decision this chapter leads to is a transition plan: each feature recorded as an end state with a review date or a transition with an exit condition, and a removal sequence rehearsed on a test farm.
What this chapter settles
It settles what migrates content, what a database attach to Subscription Edition does to hybrid, the coexistence patterns, what each migration wave changes in each feature, and the order of removal with what it leaves behind.
It takes the feature list from Chapter 1, the trust and the realm from Chapter 2, each feature's procedure and removal steps from Chapter 3, Chapter 4 and Chapter 5, what each feature sent across the boundary from Chapter 6, and operations from Chapter 7. It is the last chapter.
It leaves out how to plan waves, cut over and roll back a migration: that is the SharePoint Migration Field Guide at /guide/, whose Chapter 23 has the attach.
Applies to
| Fact | SharePoint Server 2016 | SharePoint Server 2019 | Subscription Edition |
|---|---|---|---|
| Database attach to Subscription Edition | Supported source, from "RTM version" | Supported source, from "RTM version" | The destination |
| SharePoint Migration Tool source | Listed | Listed | Not listed: not established |
| Power Automate SharePoint connector tables | Named | Named | No column: not established |
| Support | Ended 14 July 2026 | Ended 14 July 2026 | Depends on the build: each public update is supported for one year |
Sources for the table: overview of the upgrade process, SharePoint Migration Tool, SharePoint connector in Power Automate and the Subscription Edition servicing policy, all checked on 13 November 2026. Chapter 1 has the support dates.
Architecture
Two states for one feature
The farm does the same work in both states: while one feature runs, somebody keeps a trust, its certificate, directory synchronisation and a supported build (Chapters 2 and 7). What differs is how the work ends.
| Aspect | End state | Transition |
|---|---|---|
| The need | Content or people that stay on the farm | A move that is under way |
| What ends it | A review that finds the need gone | A named event: the last wave, the last My Site |
| What is recorded | The need, the owner, the next review date | The need, the owner, the exit condition and who declares it met |
Nothing in hybrid migrates content
Stated once: search indexes and does not move (Chapter 3); a redirect means "existing data in SharePoint Server is not automatically migrated" (Chapter 4); the taxonomy copy carries term groups and content types, not the items tagged with them (Chapter 5).
What does migrate content
The SharePoint Migration Tool. "SPMT supports migration from the following on-premises sources to SharePoint, OneDrive, and Teams: SharePoint Server 2010, 2013, 2016, and 2019", SharePoint Foundation 2010 and 2013, and file shares (SharePoint Migration Tool). Its feature page is headed the same way (SPMT-supported features, checked on 13 November 2026). Subscription Edition is on neither page.
A third page disagrees. The OneDrive configuration page says the tool "is only supported for SharePoint Server 2013" (configure hybrid OneDrive, checked on 13 November 2026). We would follow the tool's own pages, as Chapter 4 does.
Whether the tool supports Subscription Edition as a source, we do not know. The test has two halves: run it against one site and one My Site on a test farm at your production build, and ask Microsoft Support in writing. A run that works proves that it works, not that it is supported.
Migration Manager does not. It "supports the migration of file shares and cloud sources including Google, Dropbox, and Box. It doesn't support the migration of content from SharePoint Server" (Migration Manager FAQ, checked on 13 November 2026).
Coexistence patterns
| Pattern | Features used | What the user sees | What the team keeps running | Exit condition |
|---|---|---|---|---|
| Side by side, with redirection | Hybrid OneDrive, profiles, site following, app launcher, self-service site creation | Farm links that open the Microsoft 365 equivalent | The trust, the User Profile and App Management service applications, the audience | Every My Site is moved or disposed of, and nobody creates sites on the farm |
| One search across both | Cloud hybrid search | One set of results, from the Microsoft 365 index | A cloud Search service application and its crawls | No farm content needs to be found from Microsoft 365 |
| Two result sets | Outbound federated search | Two blocks of results in the farm's Search Center | A result source, a query rule, the trust | The farm's Search Center is retired |
| Taxonomy mastered in Microsoft 365 | Hybrid taxonomy and content types | The same terms on both sides | Managed Metadata and the Taxonomy Groups Replication job | No farm site uses a shared group |
| Content moving in waves | Any of the above, plus a migration tool | Some sites on the farm, some online | All of the above, and the migration | The last wave is accepted |
What Microsoft documents for each is in the chapter that owns it. The last column is ours: no page we read gives a condition for ending a pattern.
One limit binds every rehearsal: "crawling the same source content from multiple Cloud SSA farms connected to the same Microsoft 365 organization is not supported" (cloud hybrid search FAQ, checked on 13 November 2026). Point a test farm at a test tenant.
Dependencies that stay on the farm
| Dependency | What Microsoft documents | What is not established |
|---|---|---|
| Add-ins | The wizard changes the realm and "existing SharePoint in Microsoft 365 add-ins fail to authenticate" (Hybrid Configuration Wizard, checked on 13 November 2026); see Chapter 2 | What a second realm change, on a new farm or on exit, does to add-ins registered since |
| Business Connectivity Services | Retired in Microsoft 365, "Business Connectivity Services hybrid solutions" included; "This announcement has no impact on Business Connectivity Services in SharePoint Server" (BCS retirement, checked on 13 November 2026) | A route into Microsoft 365: there is "no direct migration from Business Connectivity Services to Power Apps" |
| Power Automate through the on-premises data gateway | The SharePoint connector's tables cover "SharePoint On-Premises 2013, 2016, or 2019. Any actions or triggers that aren't mentioned are unsupported" | Subscription Edition: it has no column |
| Power Apps and Power Automate commands | They appear "when a SharePoint Server Subscription Edition farm is connected to a Microsoft 365 tenant through hybrid" (new in Subscription Edition, checked on 13 November 2026) | Whether they disappear when hybrid is removed |
Custom farm solutions are part of no hybrid feature and stay on the farm (the first book's Chapter 23). The gateway is its own running cost: it "initiates outbound connections to the cloud, but requires no inbound connections", and "Microsoft actively supports only the last six releases" (on-premises data gateway, checked on 13 November 2026). It is not a hybrid feature. For Subscription Edition we do not know which connector actions are supported: build one flow per action you depend on against a test farm, and ask Microsoft Support.
Prerequisites
- The feature list from Chapter 1, with an owner for each feature and one for the trust.
- The farm's hybrid state, read with the script in Procedure before any change.
- A test farm at the production build, and a test tenant, where every "we do not know" here is settled.
- A supported build. "To remain supported, you must be running a supported build of SharePoint Server Subscription Edition" (Subscription Edition servicing policy). The exit needs a support ticket.
- For an upgrade from 2016 or 2019, the old farm's settings written down. Microsoft's list includes "Self-service site management settings" and "Settings and schedules for timer jobs" (create the farm for a database attach upgrade, checked on 13 November 2026).
Decision criteria
Decide per feature, never for hybrid as a whole.
| Record it as | When | What the record must hold |
|---|---|---|
| End state | What it serves stays on the farm, and somebody can say why | A review date, in our view no more than a year ahead |
| Transition | It exists because of a move | An exit condition that can be observed, and the person who declares it met |
| Remove now | Nobody can name the need, or the move has ended | The removal date |
When keeping hybrid stops being defensible. This is our opinion, not Microsoft's. We would stop defending a feature when any of these is true:
- its owner cannot confirm the need at the review;
- the farm has fallen behind the one-year servicing rule and nobody has a date for catching up;
- the trust, the certificate or directory synchronisation has no named owner;
- Microsoft has retired the service side and the replacement is not proved on your farm;
- the farm runs mainly so that hybrid has something to connect to.
The standing cost is the same in every case. Subscription Edition "follows the Modern Lifecycle Policy" with no end date (Subscription Edition lifecycle, checked on 13 November 2026), and "each PU build will be supported for one year from its release date" (Subscription Edition servicing policy). A hybrid farm is updated at least once a year for as long as it runs; the first book's Chapter 42 shows how. A farm still on 2016 or 2019 is out of support and has lost cloud hybrid search (Chapters 1 and 3): hybrid there is a transition by definition.
Procedure
1. Read the state, then classify
# Farm server, SharePoint Management Shell. Reads hybrid configuration; changes nothing.
Write-Host "Writing the hybrid link settings, the realm, the trusted token issuers and each Search service application's CloudIndex value to hybrid-state.txt. Nothing is changed."
Get-SPO365LinkSettings | Format-List * | Out-File .\hybrid-state.txt
Get-SPAuthenticationRealm | Out-File .\hybrid-state.txt -Append
Get-SPTrustedSecurityTokenIssuer | Format-List * | Out-File .\hybrid-state.txt -Append
Get-SPEnterpriseSearchServiceApplication | ForEach-Object { "$($_.Name) CloudIndex=$($_.GetProperty('CloudIndex'))" } | Out-File .\hybrid-state.txt -AppendParsed, not yet run: try it on a test farm first.
Keep the output, and run it again after an attach and after each removal step. Then give every feature a row of the table in Decision criteria.
2. Upgrading 2016 or 2019 to Subscription Edition
The supported path is one: "you use the database-attach method", from the "RTM version of SharePoint Server 2019 and SharePoint Server 2016", and "All databases must be upgraded to version 16.0.4351.1000 or higher, otherwise upgrade to SharePoint Server Subscription Edition will be blocked" (overview of the upgrade process). Earlier versions "must first be upgraded to either SharePoint Server 2016 or SharePoint Server 2019 via database attach" (new in Subscription Edition).
What the attach carries: "you upgrade only the content for your environment and not the configuration settings", and "You must manually reapply configuration settings" (create the farm for a database attach upgrade). Five service applications have databases that can be upgraded: Business Data Connectivity, Managed Metadata, Search, Secure Store and User Profile; "Settings for other services will have to be reconfigured" (services upgrade overview, checked on 13 November 2026).
What that means for hybrid. No page we read says that hybrid must be configured again after the upgrade, and none says it survives: the upgrade pages do not mention hybrid, the wizard, the trust, the realm or taxonomy replication. We do not know which hybrid settings a new farm keeps. We would treat every one as absent until read:
- Record the old farm's state with the script, and its replicated term groups and audiences.
- Attach as the first book's Chapter 23 describes, with the Subscription Edition migration pack.
- Run the script on the new farm. Whatever is missing is made again: the trust (Chapter 2), then each feature (Chapters 3 to 5).
- Do not copy the term groups again: "Once a Taxonomy Group is copied, it cannot be re-copied" (Chapter 5). Run the wizard with the same group list and confirm that the timer job exists.
- Onboard cloud hybrid search on the new farm. It "requires patching for SharePoint Server and reonboarding the Hybrid Search Service Application (Cloud SSA) in the on-premises farm using a PowerShell script" (Version 25H1, checked on 13 November 2026). Chapter 3 has the procedure. Whether an old cloud Search service application's database can be upgraded is not established: we would create it new and plan a full crawl.
- Run each feature's Verify section, and the add-in tests of Chapter 2.
3. What each wave changes
A wave leaves each feature pointing at something that has moved. Microsoft documents no procedure; the actions are ours.
| Feature | What a wave changes | What we would do |
|---|---|---|
| Cloud hybrid search | The farm copy is still crawled into the index that holds the migrated one, so we would expect both in results | Take the migrated start addresses out of the content source and crawl; for single addresses, "use the crawl log in the on-premises Cloud search service application server" (cloud hybrid search FAQ) |
| OneDrive and profiles | Whose My Sites have moved | Add people to the audience after their content has moved, not before (Chapter 4) |
Taxonomy has no row because we have no action to give. Migrated items carry terms from shared groups; "By default, managed metadata migration is turned off" in the tool (SPMT-supported features), and those groups are already in Microsoft 365 with the farm's IDs (Chapter 5). No page says how the tool treats a term that is already there. We do not know. The test: migrate one test library tagged with a replicated term, and read whether the column points at the existing term or at a duplicate.
Waves, cutover and the way back for the content itself are in the SharePoint Migration Field Guide.
4. The exit, in order
The wizard is not the way out: it "doesn't uninstall features" (Hybrid Configuration Wizard).
Microsoft's removal page has five sections (removing hybrid scenarios, checked on 13 November 2026). It fixes the position of one only: "The final step to removing hybrid is to delete" the two proxies. We would keep the page's order for the rest. It has no section for federated search.
- Cloud hybrid search. Delete the content sources first: "This ensures that SPO results won't include documents from your on-premises environment." Then delete the cloud Search service application in Manage service applications; "You may then create a new non-Cloud Search Service Application." For what remains in the index, "contact the support team for further guidance" (Chapter 3).
- OneDrive and sites. In Central Administration, Microsoft 365, Configure hybrid OneDrive and Sites features, select None. This "also removes the Hybrid app launcher feature" (Chapter 4).
- Taxonomy and content types.
Stop-SPTaxonomyReplication -Credential $credential, which performs a last full replication, andStop-SPContentTypeReplication(Chapter 5). - Self-service site creation. Per web application, the check box in Chapter 4's step 5.
- Federated search, if you have it. Not on the page: we would delete the query rule and then the result source (Chapter 3).
- The two proxies, last. In Manage service applications, delete "the Service Application named ACS" and "the Service Application named SharePoint App Management Proxy", then "Perform an iisreset on all SharePoint Servers in the farm."
Verify
Microsoft documents no check that hybrid is gone. Before the exit, every row of this table has evidence or the exit waits.
| Go only if | Evidence |
|---|---|
| Every feature's exit condition is declared met by its owner | The signed row in the transition plan |
| Each My Site behind a redirect is moved or has a disposition | The migration report, per user |
| No farm site uses a shared term group, or its owner accepts a frozen copy | The list of sites, and the acceptance |
| Nothing registered on the farm depends on the two proxies or the realm | Add-in tests on the test farm after step 6 |
| The whole sequence ran on the test farm, with the script before and after | Both outputs |
| The tenant's owner has decided on the certificate and service principal name | The decision, either way |
Afterwards: compare the script's two outputs, query IsExternalContent:true in the tenant (Chapter 3), and run Chapter 4's Verify matrix.
When it fails
| Symptom | Cause the pages give | What to look at |
|---|---|---|
| On-premises items still in Microsoft 365 results | The content sources were not deleted first, or the index needs Support | The ticket; Chapter 3 |
| OneDrive still opens in Microsoft 365 after None | "the link may be stored in the user's browser cache" (configure hybrid OneDrive) | Wait 24 hours (Chapter 4), then test again |
| Add-ins fail after an attach or after step 6 | A realm that differs from the one their tokens were issued for (Chapter 2) | Get-SPAuthenticationRealm on both farms |
| The migration tool will not sign in to the farm | Windows authentication beside another provider "is not supported" (SharePoint Migration Tool) | The web application's authentication providers |
For any other failure we do not know the documented cause: reproduce it on the test farm, and open a ticket from a supported build.
Security
An unused trust is still a trust. A feature that outlives its move leaves a certificate on the tenant's SharePoint principal and a trusted token issuer on the farm, with nobody watching either (Chapter 6).
Removal does not recall what was sent. Index entries, copied term groups and content types, files saved to OneDrive in Microsoft 365 and followed sites stay there after the farm's side is switched off (Chapter 6). No page we read states how long those copies are retained.
The migration account reads broadly. The tool needs "SharePoint credentials that have Read access to the SharePoint Server content you plan to migrate" (SharePoint Migration Tool). Treat that account as privileged while waves run.
Rollback and recovery
Rolling back a wave changes only what the features point at: put the start addresses back and crawl, and take the wave's users out of the audience.
Rolling back the exit is configuring again. For taxonomy, "you must run the Hybrid Configuration Wizard again", and a group already copied is not copied again (Chapter 5). A cloud Search service application is created new, onboarded and crawled in full (Chapter 3). The proxies come back with the wizard or the manual steps in Chapter 2.
What stays behind, and is not documented. In Microsoft 365: the certificate and service principal name on SharePoint's principal; whatever the search onboarding consent created; the copied term groups, content types and /sites/contentTypeHub; files, profiles and followed sites lists; index entries until Support removes them; and the tenant's place on the Hybrid Allow List. On the farm: the authentication realm; the trusted security token issuer; the replicated term groups; the timer service account among the term store administrators; the audience; and the service applications hybrid required. We do not know that the six steps remove any of these. The test is the script and the term store, read after a full rehearsal.
Working documents
The Hybrid Architecture Advisor generates these from your answers about the farm; what you did not answer is left as unknown, not guessed.
- Transition Plan (Excel): one row per hybrid feature, as end state or transition, with its owner and its review date or exit condition. Its Migration Decision Matrix sheet holds, per group of sites, what moves, with which tool, and what that changes in each feature. Its Go/No-Go sheet is the table in Verify, with the evidence and who signed each row.
- Architecture Decision Record (Word): the decision per feature from Chapter 1, now with the state this chapter adds and the reason for it.
- Operations Runbook (Word), its recovery and switching-off part: the six removal steps in order, the script's output before and after, and what stays behind with the decision on each item.
Sources
- Hybrid for SharePoint Server, checked on 13 November 2026
- Hybrid OneDrive and SharePoint in Microsoft 365, checked on 13 November 2026
- Overview of the upgrade process to SharePoint Server Subscription Edition, checked on 13 November 2026
- Services upgrade overview for SharePoint Server Subscription Edition, checked on 13 November 2026
- Create the SharePoint Server Subscription Edition farm for a database attach upgrade, checked on 13 November 2026
- New and improved features in SharePoint Server Subscription Edition, checked on 13 November 2026
- New and improved features in SharePoint Server Subscription Edition Version 25H1, checked on 13 November 2026
- Overview of the SharePoint Migration Tool (SPMT), checked on 13 November 2026
- SPMT-supported features, checked on 13 November 2026
- Frequently Asked Questions: Migration Manager File Share, checked on 13 November 2026
- Configure hybrid Microsoft OneDrive, checked on 13 November 2026
- Cloud hybrid search service (Cloud SSA) FAQ, checked on 13 November 2026
- Hybrid Configuration Wizard in the SharePoint admin center, checked on 13 November 2026
- Removing SharePoint hybrid scenarios, checked on 13 November 2026
- Business Connectivity Services (BCS) retirement in Microsoft 365, checked on 13 November 2026
- Microsoft SharePoint Connector in Power Automate, checked on 13 November 2026
- What is an on-premises data gateway?, checked on 13 November 2026
- Updated Product Servicing Policy for SharePoint Server Subscription Edition, checked on 13 November 2026
- SharePoint Server Subscription Edition lifecycle, checked on 13 November 2026
Related pages on this site
- This guide: Chapter 1 for the feature list and the support dates, Chapter 2 for the trust, Chapter 3, Chapter 4 and Chapter 5 for each feature's removal, Chapter 6 for what stays in Microsoft 365, and Chapter 7 for operations.
- The SharePoint Migration Field Guide at /guide/: Chapter 23 for the attach, Chapter 25 for the features an estate keeps, and Chapter 42 for staying supported.
- Subscription Edition migration pack, Hybrid Architecture Advisor and end of support dates.
Before you continue
- Every hybrid feature is recorded as an end state with a review date, a transition with an exit condition, or a removal with a date
- The content behind every redirect has a plan and a tool whose documented sources include your farm's version, or Microsoft Support's written answer
- For an upgrade to Subscription Edition, the old farm's hybrid state is recorded, and each setting is made again and verified on the new farm
- Each wave says what it changes in content sources, audiences and taxonomy
- The six removal steps were rehearsed on a test farm against a test tenant, with the state script run before and after
- What stays behind is listed, and the tenant's owner has decided on the certificate and service principal name
- The farm is on a supported public update, and the date its support ends is in the plan
Download chapter 8 (PDF)Same text, same tables, same sources as this page.
Send us a message
or write to hello@ph7x.com