Migrating our on-premises sub-sites to be modern site collections. how we will be managing the content types and site columns

Question

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...

Answer 1

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.

Answer 2

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.