Although most Microsoft 365 customers have a flat SharePoint Architecture, my consulting experience has revealed a surprising number of customers don’t have one. This post will address the downstream effects this causes across Microsoft 365.
It’s the preferred architectural model from Microsoft (and me) where all sites in your SharePoint environment are top-level sites (formerly referred to as site collections) with no subsites created underneath. All the ways to create sites within the Microsoft 365 UI today (SharePoint, OneDrive, Teams, Planner, etc.) automatically enforce a flat SharePoint Architecture because they all create (top-level) sites, not subsites.
You may be asking… why are organizations still using subsites? There are a few reasons I still see subsites in a fair number of my customers’ SharePoint environments:
Over time, organizations should look at addressing all 4 reasons above, but at a minimum, my top-level guidance is to disable the option for end users to create subsites in the first place (reason 4). End users will see the option to create a new subsite on the SharePoint Site contents page under the New button. Unfortunately, organizations must explicitly turn OFF the ability for users to create subsites as that feature is ON by default (even in new tenants).
A SharePoint administrator can set this in the classic settings page in the SharePoint Admin Center (https://<domain>admin.sharepoint.com/_layouts/15/online/TenantSettings.aspx).
An environment containing subsites may, over time, start to see some undesirable downstream effects. Here’s my top 10…
The storage quota is shared between all subsites and the top-level site. There is a hard limit on this space, so you may encounter this issue at some point. Compounding this issue is the fact that many Purview controls use a special (hidden) library on the top-level site (and subsites if you have them) called the Preservation Hold Library (PHL) to retain content. All of this contributes to the site storage quota. Beware!
Link: https://learn.microsoft.com/en-us/sharepoint/manage-site-collection-storage-limits
If you ever need to *move* a subsite from one parent site to another, it will require a migration (either manual or automated) which will change the subsite’s URL as a result causing links to break. An example of this is if you have built a subsite structure to mimic your organizational hierarchy, a common approach I see in legacy SharePoint environments particularly in small organizations.
The modern way of establishing a virtual hierarchy across sites is to identify a site as a SharePoint Hub and connect other sites to it—no subsites are required.
Link: https://learn.microsoft.com/en-us/sharepoint/planning-hub-sites
Subsites add to the length of a URL. Exacerbating this is the fact that subsites can also be nested. The combination of the folder path (includes the site and subsites) and file name can therefore become a constraint (400 characters as of June 2025). Different apps and Office versions also have different limits.
Note: URL lengths can also be a problem in a flat SharePoint architecture if there are many nested folders in a document library causing the final URL length to a file to exceed the limit.
Link: Restrictions and limitations in OneDrive and SharePoint – Microsoft Support
Most sites, particularly collaboration sites, have a start, a middle active period, and an end. Governance processes put in place across these lifecycle stages is critical for ensuring the content within is appropriately protected and retained and, in some cases, deleted when it is safe to do so. Having a well-established site lifecycle process in place can significantly reduce an organization’s data risk while ensuring they remain compliant.
Many features in Microsoft 365 can help manage a site’s lifecycle, but they are all built with the assumption of the lifecycle of a site and not a subsite. A few examples that help with the middle active period and the end:
Applying the appropriate protection and retention controls to content during the middle active period of a site involves integrating some Microsoft Purview solutions, which brings me to the remaining downstream effects of subsites.
These effects are perhaps the biggest ones to be aware of and may be the tipping point to moving toward a flat architecture if you don’t already have one. Many organizations are looking to improve their data security posture across their Microsoft 365 environment, and by not having a flat SharePoint Architecture, they may struggle implementing some of these compliance controls targeting SharePoint in a flexible and scalable way.
Simply put, Purview works best with a Flat SharePoint architecture. Here are some effects to demonstrate.
A Purview container sensitivity label controls important site data security controls such as external sharing, guest access, site privacy, and numerous conditional access controls. They are a critical part of an organization’s holistic data security strategy. These sensitivity labels are applied at a site level and will automatically include any subsites that may exist under it. Although this may be what you want at times, it may not always have the desired effect.
Example where subsites may be a challenge for container sensitivity labels: in the Legal subsite example I gave earlier, there may be cases where you want to collaborate with an external law firm on some of the legal matter subsites. You can control external sharing and guest access at a site level to accomplish that requirement; however, you CANNOT control external sharing and guest access at a subsite level. All subsites within a site will always adhere to the settings configured on the top-level site’s container sensitivity label if there is one.
Link: https://learn.microsoft.com/en-us/purview/sensitivity-labels-teams-groups-sites
A DLP policy can target SharePoint as a location and even specific sites (not subsites) for more granular control.
Example where subsites may be a challenge for DLP policies: With a DLP policy, if you wanted to block sensitive information from being shared externally from all sites while allowing it for 1 subsite if users of that subsite had a legitimate business reason to share certain sensitive information, you couldn’t do this.
Link: https://learn.microsoft.com/en-us/purview/dlp-learn-about-dlp
Retention policies retain/delete content and can only be published to a site and not a specific subsite. If there is a retain component to the retention policy, it will also use the PHL to retain changes and deletions on the site. This means there is a dual negative side effect to a subsite structure.
Example where subsites may be a challenge for Retention policies: If you had a retention policy configured to Retain for 7 years then automatically delete and published to a site that had subsites, the retention would holistically apply to everything including all content on the subsites, no exceptions. There is no way to exclude it. This also has the effect of contributing to the site’s storage quota which may be problematic if there is high data volume and activity on the site and subsites within.
Link: https://learn.microsoft.com/en-us/purview/create-retention-policies?tabs=teams-retention
Like a retention policy, retention labels can also retain/delete content, but they do it at an item level. They can be applied to content in many ways, but the most common ways are to either publish the labels to sites so they can be defaulted/manually applied to content within or auto-apply the label to items on sites.
An example of where subsites may be a challenge for published Retention labels is that they can only be published to sites and not subsites, so all subsites will receive the same published retention labels. This may be the desired effect; however, if you had one subsite that needed to have a different set of published retention labels, this is not possible.
Note: The good news for subsites is an auto-applied retention label will find matching content in the parent site as well as all subsites under it by simply targeting the parent site.
Link: https://learn.microsoft.com/en-us/purview/create-retention-labels-data-lifecycle-management
Purview’s Insider Risk Management (IRM) solution can prioritize specific sites as holding higher risk content than others by increasing the risk score for activity done on that site. The identification of these SharePoint sites does not allow for a specific subsite to be specified.
Example where subsites may be a challenge for identifying priority content in IRM: If there was a single subsite that had higher risk content than others (a sensitive project subsite, for example), the subsite cannot be singled out in IRM as a priority site when checking for risky activity. The entire parent site is the only option when targeting SharePoint. There are other ways to prioritize content that may need to be considered, such as sensitive information types, trainable classifiers, sensitivity labels, or file extensions.
This is a relatively new but very important Purview feature that allows for the classification of historical data in SharePoint sites. The effect of executing an on-demand classification is to ensure the content within the SharePoint site (and all subsites within) are reclassified with the built-in and custom sensitive information types (SITs) that are currently defined in your tenant. This then allows for policies to take effect on this content: DLP policies, IRM policies, Sensitivity label auto-labeling policies, and Retention label auto-apply policies.
One very important thing to know about on-demand classification is the additional cost associated with it (a Pay-as-you-go service). The more files that are evaluated and classified, the more it’s going to cost you.
Example where subsites may be a challenge for on-demand classification: If you have a subsite structure and you need to reclassify only 1 subsite under the parent site, you will not be able to do this. You would have to classify the entire site which would automatically include all subsites within (see the cost comment above). Although there is an option to only classify content for a date range, this will still apply to all subsites as well if there are any.
Link: https://learn.microsoft.com/en-us/purview/on-demand-classification
It’s hard to argue with the advantages of a flat SharePoint architecture. They provide the most flexibility and granularity for permissions, features, storage, lifecycle management and Purview features.
Depending on the number of subsites and the complexity of the structure, moving from a subsite to a flat architecture can vary from a minor to a major effort and, in some cases, can be a full-on migration project.
Hopefully, this post has provided some sound reasoning for moving away from subsites as soon as possible so you can take advantage of the capabilities of a flat architecture.