I'm trying to work out the benefits of Content Type Hub(s) vs. deploying Content Types via custom features, and struggling to find much online to help me compare them.

The way we are designing the system, we will have 8 content types (that number is unlikely to change, the metadata for each content type is also unlikely to change), and will be replicating them to multiple site collections as part of an extended records management system (one new site collection per year, to keep the content databases a manageable size).

Since we are creating the content types initially with a Feature in a Visual Studio solution, it would seem to make sense to me to just activate that feature in each site collection. However I have been asked to also explore the possibility of using a Content Type Hub for it, and while I can find a lot of information about Content Type Hubs, I cannot find anything that directly compares the two approaches.

  • In the meanwhile you should move away from the feature framework and start exploring a remote provisioning strategy. What we do, we have Office-dev-pnp xml files in TFS and publish them towards the content type hub and kick off the replication. Jan 8, 2016 at 8:34

3 Answers 3


I have only worked in SP2010, so not all of this may apply to SP2013. But at least in SP2010:

A content type hub provides a centralized place to manage your content types (which I'm sure you've read about). You say that the number of content types you are using and the metadata for those content types is unlikely to change, but... what if they do? By using a content type hub, you can ensure that the changes you make get propagated correctly everywhere in your system.

Content types published through a hub are read-only on the subscribing sites. Meaning, no one would be able to make an unwanted change on one site that would get that content type definition "out of sync" with it's sibling definitions on the other sites.

Maybe that's something you want, though. If you want to be able to make slight changes to the content type definitions on different site collections, then activating the feature on each site collection is the way to go.

Also, publishing content types through a hub means that they will be immediately available on any new site collections that get created, so you won't have to remember to activate the feature. In your situation this may not be much of a factor, because you're talking about adding one per year, but in other situations where site collections may be getting added and removed more frequently, it's one less thing to have to remember when setting up a new one.


There is always the possibility of doing both. Create a feature to deploy, then activate it on the content type hub site collection. You get the benefit of managed code and deployment and using the hub to syndicate them throughout the farm.


This certainly depends on a variety of factors from my experience:

  1. The maturity of the business. (Will their content types evolve, will new content types be added?)
  2. Who will be maintaining the content types (a non-technical employee)?
  3. Will there be more site collections in future?
  4. Will workflow be attached to some of these content types? (with both site feature and CTH, provisioning complexity increases)
  5. Will a content type on the hub need to contain external columns?

If yes is the answer for questions 1 through 4, then I wouldn't hesitate to recommend a content type hub. It provides for a non-technical user to easily maintain content types across the farm.

If external columns are required on a content type, this is where you may hit a road block as they aren't supported on content types in a content type hub. You could treat this content type as separate to the hub and manage it manually. Hopefully this helps you a little!

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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