I have an on-premises sharepoint team site collection, and it has 25 sub-sites. now i want to migrate this on-premises site collection and its sub-sites to be inside sharepoint online. and i want to follow the new Flat structure, so instead of having sub-sites, i will have 25 modern site collections linked to a hub-site. so i am planning to follow this migration appraoch:-

  1. migrate our on-premises root site, to be a modern hub site.
  2. migrate all the 25 sub-sites to be modern team site collections linked to the modern hub-site.

but one of the challenges i will be facing is how i will be managing the site columns and content types for my 25 site collections?. where in the on-premises case, i always create the Site Columns and Content Types on the root site, and re-use them on the sub-sites. but with the flat structure, i can not do the same. and i will need to use the traditional Content type hub site. But my question is:-

If we should invest in Content type hub sites, which can be considered as an old/traditional approach? and is it a future proof appraoch to use CT hub sites with modern sites and flat structure? OR if we want to follow the flat structure then it is better to manage the site columns and content types separately inside each modern site collection, and not to depend on CT hub sites? and seems the flat structure is not supporting content type and site columns re-usability...

This question has an open bounty worth +50 reputation from SharePoint TestDev ending in 20 hours.

This question has not received enough attention.

  • 1
    Interesting question I wonder what other people will say. I was never an fan of the content hub. I plan for my move to the SP Online to mainly relay on PowerShell and remote provisioning to ensure all the necessary columns\content types will be available by default. Then as well if the update is necessary in the future to add the column to one of the content types again I plan to use PowerShell to iterate through the sites and CTs to add necessary columns. Our Governance forbids removal of the existing columns in this way to prevent data loss. – Marek Sarad Dec 5 at 15:15
  • @MarekSarad same applies here .. and i can not find any documentation from Microsoft on how content type and site columns can be re-used and managed inside the new flat structure... in the on-premises case, i have never used CT hub, as they have a lot of problems and issues... now in my case i have a feeling that i will end up managing the CT and site columns manually (using power-shell) on each site collection.. but i asked this question to check if the flat structure provides any features which can facilitate CT and site column re-usability (as in the sub-sites cases) – SharePoint TestDev Dec 5 at 15:20

This will largely come down to personal preference. Content type hubs are designed for this purpose: copy content types and site columns to target site collections. If a content type is added or updates, wait an hour(?), and it will be on the other site collections. This will work if you are using modern sites in a flat hierarchy.

However, it's been a long time since content type hubs have ever been mentioned at a conference. So following are a few other options:

Site scripts: site scripts can create content types and site columns when a site is created. Also, site scripts can be re-applied (via powershell) to an existing site to update them with changes.

Powershell (without site scripts): Powershell can certainly create content types and site columns, and it's even easier if you use the pnp powershell commands

3rd party tools: many 3rd party tools can deploy content types, ShareGate is one.

Regardless of the method you choose, sharing content types among multiple site collections is really creating multiple, independent copies of the content type. Unlike the managed metadata service, where copying terms between environments is problematic due to the fact that the terms are really identified by guid and not name, content types are identified by name, and so having a content type in several different site collections, with the same name and site columns, will make it look like there's a single content type for the user.

Personally, I currently like the powershell route, but I find the possibility of applying deltas with site scripts to be a very interesting possibility that I need to work with further.

  • site scripts and power-shell are always valid approaches to apply repetitive tasks on multiple site collections (even we can use them in the sub-sites structure). but we did not need these approaches in the sub-sites structure, because subs-sites support CT & site columns re-usability out of the box.. my question if the flat structure provides any approaches to facilitate site columns and content types re-usability... – SharePoint TestDev Dec 7 at 16:54
  • and i agree with you that relying on CT hub in the modern world, does not look a correct way. specifically if we take into consideration that in the future, modern Hub sites might provide some appraochies to facilitate CT and site columns re-usability. then if we are replying on CT hub, then moving to the new approach will be a disaster, as all our site collections will be having a solid association with CT hubs. while if we have things open then adopting any future support for CT and site column re-usability in the flat structure will be much easier – SharePoint TestDev Dec 7 at 16:55
  • .... of couse i am talking about my own thoughts.. – SharePoint TestDev Dec 7 at 16:55
  • 1
    Modern hubs do not impact content types at this point, and it's difficult to imagine MS ever adding that capability. One of the hallmarks of modern hub sites is that sites can be connected/disconnected at will. Using this mechanism to establish content types would seem to go against this model. – Mike2500 Dec 7 at 17:02
  • good point actually.... – SharePoint TestDev Dec 7 at 23:22

Mike's answer is as good as you're likely to get but here's a rule of thumb that I suggest:

If you're managing your content types by hand, then use the hub. If you're managing content types in code, then deploy them to each site collection.

My preference is to deploy them in code as part of an automated site provisioning process but either approach is valid.

  • thanks for the reply. site scripts and power-shell are appraochies we can follow to manage content types on multiple site collections, but this is not my real question.. My question if about if the Flat structure support any type of CT and site columns re-usability.. and seems currently it does not .. so at this stage should we invest in CT hub?, and create a solid association between our modern site collections and the old/traditional appraoch of having CT hubs? – SharePoint TestDev Dec 9 at 2:18
  • .. Or it is better not to create any association with CT hubs, and manage our CT and site columns manually (using power-shell, site scripts or add them manually ), till Microsoft announce a modern appraoch to facilitate CT and site columns re-usability.. as if we start using CT hubs, then removing the association will be a big issue...what do you think? – SharePoint TestDev Dec 9 at 2:19

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.