Content Type Hub vs Content Types in Features

Question

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.

Answer 1

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.

Answer 2

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.

Answer 3

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!