Last updated: August 2018
At the recent Microsoft Ignite conference in Orlando, there was a phrase that was bandied about by some people I trust and respect in the SharePoint space. The phrase was “[SharePoint] Subsites are the spawn of the devil!”.
A provocative statement.
The downside of subsites is nothing new for many people working in SharePoint when it comes to certain things, but I had never heard such a negative slant against them until Ignite. There are no doubt thousands of SharePoint environments out there with lots of subsites. I also believe there are people out there (as evidenced by Twitter) who are confused by this statement and want to know more.
I decided to write this post to highlight the pros/cons of a site collection versus a subsite. Although it is my general recommendation to provision site collections instead of subsites, I understand there are organizations out there with many subsites so I will try to present the pros and cons in an unbiased way. Keep in mind I’m not covering off every unique business scenario that may exist and in some cases you may feel a subsite is still the best choice.
If after reading this you have more pros/cons to add, please let me know and I’ll update the post.
[Update January 20, 2018] Twitter comment from Dan Holme regarding this blog post…
“Excellent extension of [my] strong guidance to use site collections, not sub sites. A decade of governance work with clients has *rarely* shown a subsite-based IA to sustain and serve well over time. Moving fwd, sites & hub sites, and graph/search are the way to go!”
[Update August 13, 2018] Updates around subsite creation and who can create a site collection based on recent Microsoft post: Updates to SharePoint self-service site creation.
In this post, I’ll use the word “workspace” to refer to the collaborative space we are wanting to provision whether it be a site collection or a subsite.
If provisioning a site collection, the workspace will live in the top-level root site within it.
Advantages of Subsites
- A subsite can be provisioned by anyone with at least Full Control permission (more specifically, the Create Subsites permission level) on the parent site. I.e. You don’t require a farm or tenant admin to provision one for you. (Although in SharePoint Online, anyone in a specified AD group can provision an Office 365 Group site collection; to provision a standard SharePoint site collection on SharePoint Server requires membership in the Farm Administrators SharePoint group on the machine running the Central Administration website. To provision a Classic SharePoint site collection in Office 365 no longer requires you to be a Global Admin or SharePoint Online administrator; you can now allow users who don’t have permission to create groups to create sites without an Office 365 Group thru the SharePoint UI. The site can be either a team site, communication site or a classic site)
- A subsite can automatically be added to the navigation of the parent site if you have the navigation settings configured that way.
- A subsite can automatically inherit settings from its parent site including permissions, features, and navigation (Ironically this can also be a disadvantage as well as I describe in the section below). You can optionally adjust some of the settings at the subsite level. (for example, decide not to inherit navigation settings)
- This is quick and easy to setup which is attractive for small organizations who don’t have a lot of resources to spend maintaining site collections. (although in SharePoint Online, the provisioning process for an Office 365 Group site collection is very quick and easy, it is not that easy in SharePoint on-premises)
- [Update January 18, 2018] A subsite automatically inherits content types and site columns from its parent site. This is more straight-forward to setup than a Content Type Hub which is what is required to do the same across site collections.
- [Update January 18, 2018] Managed Term sets can easily be shared across all subsites within a Site Collection if the term set is created at the site collection level. Term sets cannot be shared across site collections unless it is created at the farm/tenant level.
Disadvantages of Subsites
- If you have intentionally built a site structure that mimics your organizational heirarchy and there is a re-org, then you may need to move a subsite from one site collection to another or from one parent site to another. Although you can certainly do this, it will require a migration and change the URL to the subsite which may break links, etc.
- A subsite is part of the bigger site collection when it comes to storage allocated and so all subsites housed within a site collection are constrained to what that storage limit for the site collection is.
- URL lengths may get long if you have many nested subsites. There is a URL length limit (as of the time of this writing it is 260 for SharePoint on-premises and 400 for SharePoint Online) that you may bump into. The longer the path to get to your file (will increase as the subsite structure increases), the greater the chance of hitting that limit.
- If you need to use a site feature in your particular subsite, sometimes a site collection feature needs to be enabled/activated in order for the subsite to use it. (Document ID is an example of this). You may not always want to enable a site collection feature if it will affect all subsites.
- The new Retention Labels/Retention Policies are published at a site collection level, not a subsite level. This means if you want to only publish a label for a particular subsite, you can’t.
- If you have a subsite that is no longer being used and it happens to be a parent to another subsite that is being used, you cannot remove the parent subsite.
- If you have a site collection provisioned with the new Modern site experience, you can’t create a modern team site underneath – you can only create a Classic Team site. [Update August 13,2018 – You will soon be able to create a modern team sub site as well!]
- [Update August 13, 2018] Deeply nested subsite structures leveraging dynamic structural navigation can have performance issues due to the load required to make it security-trimmed.
Advantages of Site Collections
- Provisioning a site collection can be limited to a select group of users in your organization. I believe this is a governance advantage as it gives you an opportunity to control site collections being provisioned, provide the appropriate guidance and training and implement the required controls (protection, retention) for the site collection. If you don’t want to limit this to a select group of users, you can also allow users who don’t have permission to create sites without an Office 365 Group. The site can be either a team site, communication site or a classic site. Whether this is an advantage or not will depend on your organization’s appetite for self-service site creation.
- It is a boundary for permissions – when a site collection is provisioned you will have visitors, members, and owners SharePoint groups created for it. These groups do not cross over into other site collections.
- It is a boundary for features – you can enable/activate features at a site collection level so if each discrete workspace is within its own site collection, only the features required for it need to be enabled.
- It is a boundary for storage – the amount of storage is allocated per site collection. You can also configure a site collection to be isolated to its own database (SharePoint on-premises).
- It is a boundary for search although you can extend search results across multiple site collections and target search to a single site within a site collection with search configuration and using the new SharePoint Hub site.
- The new Retention Labels/Retention Policies are published at a site collection level. This means if you want to only publish a label for a particular workspace, then it is best if the workspace is a site collection. Conversely, if you want to exclude a label from showing in a particular workspace, then this can only be done by excluding the site collection.
- You can enable external sharing on a site collection basis.
- You can identify “stale” site collections that aren’t being used. This will give you an opportunity to archive/delete these site collections independent of any other site collection.
Disadvantages of Site Collections
- It is a boundary for navigation which means navigation is not shared across site collections. To visually tie together your site collections in a “virtual hierarchy” (i.e. navigation), you will need to handle this separately. (Code, manually configured, etc.) **See my comment about the new SharePoint Hub site below to address this disadvantage however which will turn this into an advantage where you can ‘plug and play’ your site collections into whatever kind of navigation is required.
- Content types and site columns can be defined at a site collection level but cannot be easily shared across site collections. The Content Type hub is a feature built with the intent of this, but in my experience it has some usability issues, particularly in SharePoint Online.
- If you are a small company, you may find it difficult to manage multiple site collections if you have advanced branding, navigation, feature requirements.
Let’s get back to the quote from Ignite… why are subsites the spawn of the devil?
Generally speaking, it’s hard to argue with the fact that site collections are more flexible. Each site collection can be viewed as a granular ‘unit of work’. They allow you to control permissions, features, storage, branding and target data protection and retention controls at a more targeted level. A flat architecture like this allows you to ‘plug and play’ site collections into whatever kind of navigational hierarchy is required – the announcement of the SharePoint Hub site at Microsoft Ignite is a feature being built to allow you to build this navigation thru the User Interface. You will be able to associate a site collection with a SharePoint Hub by the click of a button and easily move it from one Hub to another if required. This is great news.
From tech community Ignite announcement:
“SharePoint hub sites will let you bring together associated sites to roll up news and activity, to simplify search, and to create cohesion with shared navigation and look-and-feel. Because sites can be re-arranged as your needs change, SharePoint hub sites empower your intranet to evolve with your organization.”
[Update March 21, 2018] Rolling out to targeted release customers in Office 365, you can now identify a SharePoint site collection as a “Hub”. Link: Create a hub site in SharePoint Online. As a result, the saying “Hub before you Sub” was born. 🙂
[Update August 13, 2018] Rolled out to targeted release customer in Office 365, you can now control whether site owners can create subsites from modern sites, classic sites, both, or neither.
The main disadvantage I see of subsites are the rigid nature of where they live. Once created, it is not flexible to move them to another location if required. Additionally, if they are not being used and they are a parent to another subsite that is being used, there is no way to remove the unused site – a huge governance issue. If you’re provisioning subsites, you should understand the pros and cons of that decision.
One key feature I would like to see improved is the Content Type Hub for sharing site columns and content types across site collections. If the recommendation is to favor provisioning of site collections rather than subsites, then it is critical that content types and site columns are shareable across them. Currently, this functionality requires work.
Are there pros and cons to both site collections and subsites? Absolutely, yes. However, I believe site collections set you up better for long-term success. If you’ve already provisioned subsites and want to move to this new structure, it will take time to get there but well worth the effort in my opinion.
Thanks for reading.
Another arguement in favour of site collections. A custom list created in the root site that is used via lookup columns in subsite libraries and lists
Well thought out post, the chances of an org structure that can affect heirarchies is certainly a ‘when it happens’ rather than an ‘if’ . I’m a big fan of flat and liberal use of site collections and there are times when subsites are useful such as when you need a well defined container for information activity e.g. a contact management respisitory of which there might be a couple of hundred but you don’t need a full blown group or other features that say come with groups/ms teams. Same with projects, some projects are small tightly contained affairs where others certainly deserve the full suite of capabilities that O365 offers. What clings orgs to subsites is fear of losing some semblance of hierarchical Navigation with the site collection only flat architecture, this can be overcome but it’s bit easy for organisations to understand how. The hubs will help and so will tried and true lists of sites that point to site collections as way finding mechanisms and which can also play a role in site provisioning. Many clients aren’t sold on search alone to turn up the sites they should be working in. Lots of space here for sharing of approaches for sure.
Thanks for your insights Andrew. I agree, there are still some sidebar cases where a ss needs to be an option in the toolbelt – as long as the limitations are known. To reduce risk, I wouldn’t go any more than 1 level deep though.
An excellent article – we’ve gone down the route of only allowing one level of subsites to be created, we’ve removed the ability to nest subsites within subsites, so we’ve tried to keep our organisation reasonably flat.
Could you comment on your experiences after implementing this type of structure.
being *slightly* devils advocate here. we mustn’t forget that Microsoft has a driving technical/performance need to limit sub webs in Office 365 tenants as they’re expensive in database operations terms which, on a shared/tenanted platform, creates hyper-scale challenges.
Great article. One question, the disadvantage of a sub site is if you move it from one location to another, the links become broken. Is n’t the resolved now if you use the Document ID Service?
You are correct, if the Document ID feature is enabled, that will allow any document links to remain valid and intact (as long as they are moving within the same site collection I believe – I’ll have to verify that), there are many other things that will break (Site URL, list URLs, etc.) that may be floating around in user’s shortcuts, etc. that would break.
I will add the Document ID exception to the post. Thanks!
I found this post by Oliver Wirkus where he talks about moving a doc from one Site Collection to another each having the Document ID feature activated. Sounds like there’s a few gotchas. https://www.sharepointeurope.com/sharepoint-moving-a-document-with-a-document-id-to-another-site-collection/
I’ve never tested this in SharePoint Online.
Good article, my questions.
What issues have you found with content type hub and SharePoint online? I am currently using it and it behaves as i would expect on SharePoint On Premises. Sure there are issues when content types don’t publish as you expect, are there any other issues you can share with me?
If Content Type hub is not the way to go, what is the alternative?
I don’t mean to scare you off of the Content Type Hub, but there are some “issues” that have been blogged about by Jasper Oosterveld about a year ago. Here is a link to his post: https://www.petri.com/dear-sharepoint-online-content-types-hub-whats-going
There is also a UserVoice that talks about some of the pain-points of working with the CTH in general: https://sharepoint.uservoice.com/forums/329214-sites-and-collaboration/suggestions/14691267-better-content-type-hub-management
I’ve been hesitant to use it in SharePoint Online because of some of these issues, however I do know people that have used it and have had some success with it. I had previously found another UserVoice(can’t seem to find the link right now) that mentions Microsoft is actively working on the Content Type Hub as I suspect they also see some limitations in its current form. I fully expect good things to come from that. (Not sure what the ETA for that will be however)
There really is no alternative for farm-level or tenant-level content types unless you have some developers that can deploy the content types for you across site collections. ??
I’m confident that the Content Type Hub will get the care and attention it deserves from Microsoft in the coming months.
Hope that answered your question,
Great article Joanne! I’ve always taken the service-oriented approach to site collection topology. There is often a trade-off between IT manageability/convenience and business agility/convenience. Having everyone in the same site collection can make day-to-day ops easier but it certainly creates a governance and agility challenge when changes by one area are required and not necessarily the prerogative of another team sharing the collection. The SOA lens being that a site collection is the information management and collaboration authority representing a specific business capability (more closely tied to an organization’s given functional area rather than the employee/management org chart). The advantage is that you have tightly coupled teams working together in a collection and can authorize changes to their own site collection including simper self-management. Different org functions and cross-functional initiatives or programs would have separate site collections. This tends toward having more site collections and is bias toward business change agility. The built-in challenge and opportunity with this paradigm is that you need to really understand the collaborative relationships and core functional areas as well as what is likely to change in these regards in order to provide an optimal topology.
Thanks for your blog. The discussion site collection/subsite is still relevant for us. One thing that I can’t find adressed is how to manage permissions. One of the biggest advantages for us to use subsites is that you can manage (sub)departments or teams in a single group. With different site collections, you’ll have to manage several more or less identical SharePoint groups. As far as I can see, the SharePoint Hub sites are not going to solve that.
Great point and you are correct. To date, the SharePoint Hub is not a permission container. Managing permissions is something that definitely needs to be addressed across a flat architecture. Relying on AD groups for some of that will help, also who is administering permissions for those site collections? Many organizations are now pushing out permission administration to the business owner for lower-level sites. For example, for a team site collection within a department, get the site owner to add/remove people from the team as they join/leave the team. For larger groups (like departments, divisions, org), still leveraging an AD group.
There’s no silver bullet, but it is an opportunity to reconsider permission admin since the up-side of a flat architecture is flexibility. It’s not an easy answer though and likely one I should blog about. Strategies, pros, cons, etc.
I appreciate the feedback.
Ok, I am very new to SharePoint, but it seems that sites that are part of hubs are essentially subsites of the hub, eh? We still seem to have a hierarchy, but it is now limited to two levels. Is anyone talking about allowing all the advantages of Hubs but have “sub-hubs,” to allow a site under a hub to be a hub for other sites, but still allow the new flexibility that we have in moving them from one hub (or sub!) to another? I don’t see why a hierarchy and the hub architecture could not be melded together. Similar to the ease in moving a folder on a drive from one parent folder to another.
No, sites that are part of a hub are not subsites. They are site collections “connected” to a hub. Some settings are shared (lay out, navigation, related content) but, for instance, permissions are not shared.