For years, Microsoft has been recommending that organisations move away from SharePoint subsites and adopt a flat architecture based on independent site collections connected through hub sites. The official explanation is that this approach provides greater flexibility, better governance, easier restructuring and improved scalability. Having worked extensively with SharePoint over the years, including its APIs, data structures and underlying architecture, I have a rather different view. I believe this direction is driven at least as much by SharePoint’s historical technical limitations as by the architectural benefits Microsoft promotes.
This is not simply a preference for the way SharePoint used to work. There are fundamental architectural questions worth asking, particularly when a platform that has retained many of its original limitations starts recommending that developers abandon established design principles in favour of an entirely different structure. Are we really adopting a better architecture, or are we designing our solutions around the limitations of the platform itself?
1. Since when did hierarchical architecture become a bad idea?
Hierarchical structures have been fundamental to software engineering, security models and information systems for decades. File systems, organisational structures, directory services and enterprise applications routinely use hierarchies because they provide a natural way to represent relationships, responsibilities and permissions. SharePoint’s traditional architecture followed this principle. A site collection could represent a department or business function, with subsites representing its internal teams or operational areas. Permissions could be established at the appropriate level and inherited throughout the hierarchy, while shared resources, site columns, content types and configurations could be defined centrally and reused. For example, a department could maintain a common customer list and use reusable site-column definitions to support lookup relationships across its subsites, subject to the relevant SharePoint configuration. This was a coherent architecture that reflected the actual structure of the organisation and allowed related components to operate within a common security and administrative context.
One of Microsoft’s arguments against subsites is that hierarchical permissions become difficult to manage when inheritance is repeatedly broken. But that is a design problem, not an inherent weakness of hierarchy. If an application requires hundreds of exceptions to its permission structure, perhaps the structure was not designed correctly in the first place. More importantly, replacing those subsites with hundreds of independent site collections does not eliminate the need to manage permissions; it simply distributes that responsibility across separate security boundaries. Modern identity management and automation can certainly help, but they are additional mechanisms replacing relationships that previously existed naturally within the hierarchy. Each site collection also maintains its own user information and configuration context, meaning that logically connected resources are now distributed across independent environments. From a purely architectural perspective, I struggle to see why this should automatically be considered an improvement.
Hub sites illustrate the problem particularly well. Microsoft has effectively introduced a mechanism to recreate a logical grouping above independent site collections, providing common navigation, branding, search and content aggregation. But unlike a traditional parent site, a hub does not provide general hierarchical permission inheritance, nor does it make associated sites part of a common site collection with shared resources. We have replaced a native hierarchical relationship with an association between independent entities, then introduced additional mechanisms to manage some of the relationships we previously had. There are legitimate situations where this makes sense, particularly when sites require independent ownership or frequent organisational restructuring. But for stable departmental systems and structured business applications, I am not convinced that this represents better design. Why dismantle a hierarchy that naturally expresses the application’s relationships, only to reconstruct part of it through another architectural layer?
2. What SharePoint Online still reveals about its underlying architecture
To understand why Microsoft might prefer this approach, it is worth looking under the bonnet. SharePoint’s historical SQL Server architecture was unusual, to say the least. Rather than creating conventional relational tables corresponding to individual SharePoint lists, it used generic storage structures, including the well-known AllUserData table. Fields from different lists were mapped into predefined columns according to their data types, with names such as int1, int2, nvarchar1 and float1. When the available storage slots for a particular data type were exhausted, SharePoint could distribute a single logical list item across multiple physical rows, using row ordinals to identify them. This approach provided the flexibility to create arbitrary lists without constantly modifying the physical database schema, but it also introduced significant complexity into storage, indexing and query execution. From a conventional relational database design perspective, it was hardly elegant, and it is reasonable to question the performance implications of such a model.
What makes this particularly interesting is that SharePoint Online still exposes these same generic-column mappings today. I recently retrieved the XML schema of a SharePoint Online list through its API, using a list containing different field types to examine how they are represented. The response includes ColName attributes that map logical SharePoint fields to generic storage-column identifiers, alongside RowOrdinal attributes. For example, these are shortened extracts from the actual XML response:
<Field Type="Text"
Name="SingleLineOfText"
ColName="nvarchar4"
RowOrdinal="0" />
<Field Type="Number"
Name="Number"
ColName="float1"
RowOrdinal="0" />
<Field Type="User"
Name="PersonOrGroup"
List="UserInfo"
ColName="int2"
RowOrdinal="0" />
<Field Type="URL"
Name="HyperLinkOrPicture"
ColName="nvarchar6"
ColName2="nvarchar7"
RowOrdinal="0"
RowOrdinal2="0" />These are not logical business-field names or information that an ordinary SharePoint user needs. They are internal-style storage mappings, using precisely the terminology and conventions associated with SharePoint’s historical database architecture. The XML even retains the RowOrdinal property, which was used to identify the physical row associated with a particular set of field values. In this example the ordinal is zero, so it does not demonstrate that any item actually occupies multiple physical rows, but the mechanism is still represented in the schema. The response also references the UserInfo list, another familiar component of SharePoint’s site-collection architecture. Most importantly, this is not an extract from an old on-premises installation. It is a SharePoint Online response retrieved in October 2026.
Of course, without access to Microsoft’s internal databases, I cannot establish that SharePoint Online still uses precisely the same physical tables as earlier versions of SharePoint Server. But I find the alternative explanation rather difficult to accept without further evidence. Why would a modernised storage architecture continue to expose the exact same generic column identifiers and row-ordinal metadata that were originally tied to the physical database implementation? These properties serve no obvious purpose for ordinary consumers of the API, and they are not part of the logical data model that developers normally need to work with. Backwards compatibility could explain their continued presence, but it would also mean Microsoft has deliberately retained a detailed representation of an obsolete storage model. My interpretation is that this is a strong indication of substantial architectural continuity beneath SharePoint Online, although confirming the physical implementation would require further investigation.
This interpretation also fits with the limitations that SharePoint developers continue to encounter. The 5,000-item list view threshold remains relevant in SharePoint Online, along with restrictions on lookup operations, joins and certain complex queries. A SharePoint list can contain millions of items, but developers must still design queries and indexes carefully to avoid hitting these limits. For a modern cloud platform operating on Microsoft’s infrastructure, these are striking constraints. They are also consistent with the challenges one would expect from a highly generic data-storage model. That does not prove that every limitation originates in AllUserData, but it raises a legitimate question: if the underlying architecture has fundamentally changed, why do so many of its historical limitations remain?
3. Is Microsoft’s best practice really about scalability?
There is a well-established principle in system architecture: when a system becomes difficult to scale as a single unit, distributing workloads across smaller, independent units can improve scalability and operational management. SharePoint has historically used site collections as important boundaries for storage, administration and workload distribution. In SharePoint Server, multiple site collections could reside within a content database, and distributing site collections across databases was a standard approach to managing capacity and performance. In SharePoint Online, Microsoft must support an enormous number of sites created not only directly through SharePoint but also through Microsoft Teams and other Microsoft 365 services. From the platform operator’s perspective, independent site collections provide useful boundaries for distributing workloads, applying policies and managing resources. Large hierarchical site collections, by contrast, keep more of those relationships and resources within a single administrative and storage boundary.
This is where I believe the real explanation for Microsoft’s architectural direction may lie. A flat structure based on independent site collections is attractive when the priority is operating SharePoint efficiently at enormous scale, particularly if the underlying data architecture still carries significant historical constraints. Hub sites then provide a way to recreate a logical organisational structure without reintroducing the tighter coupling of traditional subsites. From Microsoft’s perspective, that is a sensible infrastructure strategy. But an architecture that is easier for Microsoft to operate at scale is not necessarily the architecture that is best for every application built on SharePoint. Those are two different objectives, and I think the distinction has been largely lost in the way flat architecture is presented as a best practice.
When designing a business application, I start with its functional requirements, data relationships, security model and organisational structure. If those requirements naturally form a hierarchy, I see no architectural reason to discard that hierarchy simply because the platform provider recommends independent site collections. Flat architectures are appropriate for autonomous collaboration workspaces, projects with separate lifecycles and organisational units requiring independent governance. But structured departmental applications with shared reference data, common permissions and closely related functional areas may be better served by a hierarchical model. The fact that Microsoft has developed tools to connect and govern independent sites does not automatically make that approach simpler or more coherent. It may simply mean that we have become better at managing the additional complexity.
My conclusion, based on years of working with SharePoint and examining its behaviour below the user-interface level, is that Microsoft’s preference for flat site collections is very likely influenced by the scalability requirements and technical constraints of the underlying platform. The XML evidence reinforces that interpretation: SharePoint Online still exposes the generic-column mappings and row-ordinal metadata associated with its historical storage architecture, while many longstanding query limitations remain. These observations do not establish Microsoft’s internal engineering rationale, and the relationship between the exposed schema and the current physical database deserves further verification. Nevertheless, they provide a substantial technical basis for questioning the assumption that flat architecture is inherently superior.
Are we being encouraged to adopt flat SharePoint architectures because they are genuinely better for our applications, or because they are better suited to the limitations and operational requirements of SharePoint itself?
I suspect the latter plays a much bigger role than Microsoft acknowledges.
And perhaps what is being presented as modern architectural guidance is also a rather effective way of working around some very old design decisions.
I would be interested in hearing from SharePoint architects and developers who have worked with both traditional site hierarchies and modern hub-based architectures. Have you genuinely found flat site collections simpler to manage, or have you simply moved the complexity somewhere else?
#SharePoint #SharePointOnline #SoftwareArchitecture #Microsoft365 #DatabaseDesign #EnterpriseArchitecture
