Copy each term group once, then edit it only in Microsoft 365

Hybrid taxonomy and hybrid content types are two movements in opposite directions. A cmdlet copies the term groups and content types you name from the farm to SharePoint in Microsoft 365, once. From then on a timer job on the farm fetches changes from Microsoft 365: "The shared taxonomy is mastered in SharePoint in Microsoft 365 and a read-only copy is kept updated in SharePoint Server" (plan hybrid taxonomy, checked on 13 November 2026). This is replication one way. It is not synchronisation in both directions, and no documented setting makes it so.

Which term groups and content types become shared, who edits them once Microsoft 365 is the master, and how does the farm learn of each change?

The decision this chapter leads to is a named list of term groups and content types to share, each with an owner in Microsoft 365, taken before the copy.

What this chapter settles

It settles what is copied and what is replicated, in which direction, on which schedule, and who may change a term afterwards, because the product does not enforce that on the farm.

It takes from Chapter 1 the farm's version and update level, and from Chapter 2 the synchronised accounts and the server-to-server trust. It hands Chapter 6 the question of whether your terms may be held in Microsoft 365, Chapter 7 the watching of the timer job, and Chapter 8 the removal of the trust.

It leaves out the design of the taxonomy. Which term sets survive and which content types are merged are information architecture decisions, made first, in the first book's Chapter 12.

Applies to

Sources for the table: minimum update levels, Copy-SPTaxonomyGroups, Copy-SPContentTypes and Stop-SPTaxonomyReplication, all checked on 13 November 2026.

For Subscription Edition the banner on the planning and configuration pages ticks it. Their bodies say the features "are available in SharePoint Server 2013 and SharePoint Server 2016" (plan hybrid taxonomy). The minimum update page has tables for 2019, 2016, 2013 and 2010 and none for Subscription Edition. On the other side, the wizard page names "SharePoint Server Subscription Edition" among the servers the wizard is launched from, and Hybrid Taxonomy is one of its options (Hybrid Configuration Wizard, checked on 13 November 2026).

We do not know whether hybrid taxonomy and hybrid content types are supported on Subscription Edition, or from which build: no sentence in the pages we read says so. The first test is whether the cmdlets exist on your farm:

# Farm server, Windows PowerShell as a farm administrator. Changes nothing.
Write-Host "Listing the hybrid taxonomy cmdlets this server has"
Get-Command Copy-SPTaxonomyGroups, Copy-SPContentTypes, Stop-SPTaxonomyReplication, Stop-SPContentTypeReplication -ErrorAction SilentlyContinue | Format-Table Name, Source

Parsed, not yet run: try it on a test farm first.

Four rows are expected. A missing row means that step cannot be run on that build. Four rows prove presence only: the second test is the whole procedure on a test farm, with one throwaway term group, against a test tenant.

Chapter 1 covers the support state of 2016 and 2019, the versions these pages do name.

Architecture

Two movements

Sources for the table: plan hybrid taxonomy, Copy-SPTaxonomyGroups and configure hybrid taxonomy, checked on 13 November 2026.

"Replication is done at the term group level." The copy keeps identity, "maintaining the IDs of the terms, term sets, and term groups in those taxonomies" (plan hybrid taxonomy); the page states that for taxonomy and not for content types.

The term store on each side

What can and cannot be shared, as the planning page writes it:

• "System and special groups (the System, Search, SearchDirectories, and People groups) can't be replicated, but any other groups that you create can be."
• Local term sets "remain local and aren't affected by hybrid SharePoint taxonomy. These local site-specific terms can't be replicated."
• "Be sure you're not reusing terms between groups that you replicate and groups that you don't replicate."

On who can still edit a replicated group on the farm, the same page gives three sentences that do not agree:

• "Groups that are replicated via hybrid SharePoint taxonomy are set to read-only in SharePoint Server and can only be updated in SharePoint in Microsoft 365."
• "(A term store administrator can still update the SharePoint Server groups, but such updates will be overwritten during the next replication.)"
• "Farm Administrators can modify Term Groups on-premises. These changes will not replicate to SharePoint in Microsoft 365. It is important that Farm Administrators be notified to not make changes on-premises."

We would plan on the second and third: an administrator can still change a replicated group on the farm, and the change never reaches Microsoft 365 and is lost. The pages do not say whether "the next replication" means the daily update of changes or only the weekly full replication. We do not know. The test: change a test term on the farm, run the job by hand, look, and look again after the next full replication.

The copy does not carry everything. It "preserves most user information associated with term sets - such as owner and stakeholders", but "the copy process doesn't work with Active Directory groups". Copy with those groups in place and "You'll see a PowerShell warning and the Active Directory group assignments are lost if you proceed" (configure hybrid taxonomy).

Content type publishing

For content types the direction is the same. The feature "propagates updates made to your SharePoint in Microsoft 365 content types to your SharePoint Server site collections" (plan hybrid taxonomy), and it "replicates the published content types in Microsoft 365 to on-premises" (Hybrid Configuration Wizard).

The copy has a fixed destination: "The content types are copied into https://contoso.sharepoint.com/sites/contentTypeHub. If this site doesn't exist, it's created for you, and the Site Collection Feature Content Type Syndication Hub is enabled. The site URL is hard coded and can't be changed" (configure hybrid taxonomy; contoso is Microsoft's example).

No page we read says:

• what happens to the content type hub on the farm: whether it keeps publishing, and which source wins when both publish the same content type;
• the name or schedule of whatever replicates content types;
• whether a content type keeps its ID, and whether its columns and their term set bindings travel with it;
• whether a content type can be copied a second time.

We do not know any of the four. One test answers them: a content type with one managed metadata column, copied from a test farm, then changed and republished in Microsoft 365.

Prerequisites

The trust, the realm change it brings and the Hybrid Allow List are in Chapter 2.

The roles, and where the pages disagree

To run the wizard you must be a member of the Farm Administrators group, hold Full Control on the User Profile Service and be "A Microsoft 365 Global Admin, either with or without multi-factor authentication (MFA) enabled for the account" (Hybrid Configuration Wizard). The configuration page's own steps say only "an account that has admin permissions in Microsoft 365". We would follow the wizard page, which names the role.

For the credential given to Copy-SPTaxonomyGroups, two pages name two roles:

• The configuration page lists "Your Microsoft 365 global admin credentials."
• The cmdlet page says of -Credential: "Specifies the Taxonomy Term Store administrator credential of remote SharePoint Online Term Store. Writes data to remote Term Store, so a Term Store Administrator's credential is needed to perform the operations."

We would try the cmdlet page's role first, on the throwaway group: it gives its reason, and the wizard page says Global Administrator "should be limited to emergency scenarios when you can't use an existing role". Neither page says that a term store administrator without Global Administrator succeeds, so that is a test and not a fact. Either way use a cloud-only account: "If you receive an HTTP 400 error when attempting to use the Copy-SPTaxonomyGroups cmdlet with correct credentials, switch to a cloud-based global admin instead of an Active Directory synchronized account" (configure hybrid taxonomy).

For -LocalTermStoreName the pages disagree again:

• The configuration page asks for "The name of your managed metadata service application in SharePoint Server", with the example "Managed Metadata Service".
• The cmdlet page's example passes "Managed Metadata Service Application Proxy", and the configuration page's own Copy-SPContentTypes example passes "managed metadata service application proxy".

We do not know whether the cmdlet wants the service application's name or its proxy's. Read both from Manage service applications in Central Administration, and record which one the cmdlet accepted on the throwaway group.

What the wizard option brings with it

The wizard's description of Hybrid Taxonomy ends: "Choosing this option sets up OneDrive and user profile redirection, sites features, and hybrid app launcher" (Hybrid Configuration Wizard). The configuration page does not mention it. We do not know whether choosing Hybrid Taxonomy turns redirection on for your users. Run the wizard on the test farm and read the Configure hybrid OneDrive and Sites features page in Central Administration afterwards (Chapter 4).

Decision criteria

Use hybrid taxonomy when sites on both sides will be tagged with the same terms for long enough that two term stores would drift, and term management can move to Microsoft 365. Do not use it when the owners of the terms cannot work in Microsoft 365, or when the farm is about to be emptied: there the migration's information architecture decides.

Conditions that stop it until resolved:

• The cmdlet test or the test farm run has not passed on your Subscription Edition build.
• A group you want to share reuses terms with a group you will keep local.
• Term sets carry Active Directory groups and nobody has chosen between the two documented options: replace them with individual users first, or accept the loss and "assign a Microsoft 365 group in place of the Active Directory group" afterwards.
• A person or code on the farm writes to a group you plan to replicate.
• The tenant already has a site at /sites/contentTypeHub that somebody else owns.

Name the groups. The wizard's default is wide: "If you don't specify groups, then all groups except system and special groups are configured for replication" (configure hybrid taxonomy).

Ownership after configuration

The product facts in this matrix are the documented ones above. The roles are what we would put in place; replace them with your own.

Content type consistency follows the same rule. What a later replication does to a farm-side change to a shared content type is not established. We would freeze the farm-side definition of each copied content type on the day of the copy, and compare the two sides after each published change.

Procedure

The documented order is copy, then the wizard, then the timer job: "We recommend that you copy your taxonomy to SharePoint in Microsoft 365 before you set up hybrid SharePoint taxonomy" (plan hybrid taxonomy). If you copy a group later, the planning page says "you'll have to rerun the Hybrid Configuration Wizard"; the configuration page says "you may need to". We would plan on having to.

1. Back up the term store. "We also recommend that you back up your term store before you proceed" (configure hybrid taxonomy). The page does not say how.

2. Resolve the Active Directory groups on the term sets you will copy.

3. Copy the term groups. The syntax, as the configuration page writes it:

   PowerShellCopy code

   $credential = Get-Credential
   Copy-SPTaxonomyGroups -LocalTermStoreName "<ManagedMetadataServiceApplication>" -LocalSiteUrl "<OnPremisesSiteURL>" -RemoteSiteUrl "SharePointOnlineSiteURL" -GroupNames "Group1","Group2" -Credential $credential

   Microsoft's documented commands, quoted as its page prints them. Not run by us: try them on a test farm first.

   The mandatory parameters are -Credential, -GroupNames, -LocalSiteUrl, -LocalTermStoreName and -RemoteSiteUrl; the optional ones are -AssignmentCollection, -AuthEndpoint and -GraphApiEndpoint (Copy-SPTaxonomyGroups). This step cannot be repeated for a group, so the throwaway group goes first.

4. Copy the content types, if you use hybrid content types. Microsoft's example:

   PowerShellCopy code

   Copy-SPContentTypes -LocalSiteUrl http://localsite/ -LocalTermStoreName "managed metadata service application proxy" -RemoteSiteUrl https://contoso.sharepoint.com/ -ContentTypeNames @("ContentTypeA", "ContentTypeB") -Credential $credential

   Microsoft's documented commands, quoted as its page prints them. Not run by us: try them on a test farm first.

   Here -Credential is "the administrator account credential of the target SharePoint Online site", and -LocalSiteUrl "Can be a local site or a local hubsite" (Copy-SPContentTypes).

5. Make the timer service account a term store administrator. "To find this account, check the Log On As account for the SharePoint Timer Service on your server." In Central Administration, under Manage service applications, open the Managed Metadata service application and "Add the timer service account to the Term Store Administrators box, and then select Save."

6. Run the wizard. From a browser on a farm server, signed in as the farm administrator, go to More features in the SharePoint admin center and, "Under Hybrid picker, select Open". Select Hybrid Taxonomy and provide the URL of the farm's root site, the name of the managed metadata service application, and "The names of the taxonomy groups that you want to replicate (for example, Engineering;Marketing)."

7. Let the timer job run. "By default, this timer job replicates taxonomy on a daily basis." You can run it on another schedule or manually "by searching for it in the timer job list in Central Administration."

The quotations in steps 5 to 7 are from configure hybrid taxonomy. To change the list of replicated groups later, "there's no need to stop replication": run the wizard again with the new list.

Verify

Microsoft documents no verification procedure for this feature. These checks are assembled from the behaviour the pages state. Run them on the throwaway group first.

When it fails

The documentation covers failures in the copy and in stopping. It says nothing about failures in replication.

What the pages do not say:

• How a failed run of Taxonomy Groups Replication shows itself. We found no health rule, error text or troubleshooting page for it. We do not know. The test: on the test farm, remove the timer service account from the Term Store Administrators box, run the job, and read its history and the logs. Chapter 7 takes it from there.
• Which Microsoft 365 endpoints the job and the cmdlets call. Read them from the proxy log during the test run and compare them with the published Microsoft 365 endpoints.
• Whether the copy cmdlets work against today's Microsoft 365. Their optional parameters name "the Azure Active Directory Graph API authentication endpoint" (Copy-SPTaxonomyGroups), and no page says what they depend on now. The throwaway group answers this.
• What a copy does when the tenant already holds a group of the same name.

Security

What authenticates. "The SharePoint in Microsoft 365 APP Identity is used to authenticate to Microsoft 365" (configure hybrid taxonomy). The pages do not say what that identity may read or write in the tenant, or how it relates to the trust in Chapter 2.

What leaves the farm. What you name in the copy: the term groups with their term sets, terms and IDs, "most user information associated with term sets", and the content types you list. No page describes a term going from the farm to Microsoft 365 after the copy, and none states where in Microsoft 365 the copied terms are held. If a term set is itself sensitive, take it to Chapter 6 before the copy: no undo is documented.

Who can change terms. In Microsoft 365, whoever administers the term store there. On the farm, term store administrators and farm administrators still can, and the timer service account is now a term store administrator by requirement. Keep the Term Store Administrators box to the names the matrix allows. Global Administrator, which the wizard asks for, we would grant for the run and remove afterwards.

Rollback and recovery

The removal page gives this feature one line, "See Stopping replication of taxonomy groups" (removing hybrid scenarios, checked on 13 November 2026). That section of the configuration page documents two cmdlets:

$credential = Get-Credential
Stop-SPTaxonomyReplication -Credential $credential
Stop-SPContentTypeReplication

Microsoft's documented commands, quoted as its page prints them. Not run by us: try them on a test farm first.

Stop-SPTaxonomyReplication does more than stop. "The Taxonomy Groups Replication timer job will be killed and a full replication from SharePoint Online Taxonomy store to local SharePoint on-premises store will be performed" (Stop-SPTaxonomyReplication). The farm ends with the Microsoft 365 state of that moment. On the credential the page disagrees with itself: its example says "a SharePoint Online tenant administrator credential", its parameter says "the Taxonomy Term Store administrator credential of remote SharePoint Online Term Store". We would follow the parameter text, as for the copy.

Stop-SPContentTypeReplication is shown with no parameters, and its link leads to an archived wiki list, not a reference page. Its behaviour is not documented. To start again, "you must run the Hybrid Configuration Wizard again". The wizard "doesn't uninstall features".

What stays, as far as the pages go:

• In Microsoft 365: the copied groups, the copied content types and the /sites/contentTypeHub site. No page documents removing them or copying a group back to a farm.
• On the farm: no page says the stop removes anything, so we expect the replicated groups, the content types already received and the timer service account's place in the Term Store Administrators box to remain.

Not established: whether the replicated groups become editable again once replication stops; what the stop leaves of the replicated content types; and whether a group copied once can be shared again from a rebuilt farm. We do not know. Stop replication on the test farm and read the state of both sides.

The removal page's last step, for removing hybrid as a whole, deletes two service application proxies the wizard created. That step, the trust, and whether replication survives a database attach to a new farm belong to Chapter 8.

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.

• Taxonomy Mapping Workbook (Excel): one row per term group, with whether it is shared, local or not replicable, and its owner. Its content types sheet lists each content type to copy; its governance sheet holds the matrix above.
• Validation Checklist (Excel), the taxonomy rows: each check in Verify with its expected result, who ran it and when.
• Configuration and Validation Runbook (Word), the taxonomy part: the seven steps in order, with the account for each and the evidence to keep.

Sources

• Plan hybrid SharePoint in Microsoft 365 taxonomy and hybrid content types, checked on 13 November 2026
• Configure hybrid SharePoint taxonomy and hybrid content types, checked on 13 November 2026
• Copy-SPTaxonomyGroups, checked on 13 November 2026
• Copy-SPContentTypes, checked on 13 November 2026
• Stop-SPTaxonomyReplication, checked on 13 November 2026
• Hybrid Configuration Wizard in the SharePoint admin center, checked on 13 November 2026
• Minimum public update levels for SharePoint hybrid features, checked on 13 November 2026
• Set up SharePoint Server services for hybrid environments, checked on 13 November 2026
• Removing SharePoint hybrid scenarios, checked on 13 November 2026

Related pages on this site

• Chapter 2 of this guide: identity, authentication and trust, which the wizard configures for every option.
• Chapter 4: hybrid OneDrive and sites, for what the Hybrid Taxonomy option also sets up.
• Chapter 6, Chapter 7 and Chapter 8: governance, the timer job in operation, and the exit.
• Chapter 12 of the SharePoint Migration Field Guide: the information architecture decisions this chapter assumes.
• Hybrid Architecture Advisor, for the working documents above.

Before you continue

• The four cmdlets are present on your build, and the procedure has passed on a test farm with a throwaway term group
• Every term group is classified as shared, local or not replicable, and no shared group reuses terms with a local one
• Each shared group and content type has a named owner in Microsoft 365
• The Active Directory groups on the term sets to copy are replaced with users, or their loss is accepted in writing
• The effect of the Hybrid Taxonomy option on OneDrive and profiles has been read on the test farm
• Stop-SPTaxonomyReplication has been run on the test farm, and the state it left on both sides is written down

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