Classic SharePoint is on target to be officially unsupported in 2026, which means more organizations are looking to move their SharePoint document management repositories, knowledge bases and intranets into the modern space.
They often want to take a lift and shift approach, because it feels like it would cause the least amount of friction. Unfortunately, modern SharePoint has a different site structure from classic, so it’s not so straight forward.
In this post, we explain the key differences between classic and modern SharePoint site structure and share our recommendations for moving your content to the new, supported SharePoint platform.
Classic vs. modern SharePoint site structure: What has changed?
Moving from subsites
The hierarchical site and subsite structure of classic SharePoint is no more. If you dig deeply, you may find a way to enable the creation of subsites, but they’re not supported by Microsoft, so any functionality that works today could break tomorrow.
In many organizations we work with, we see deeply nested subsites in their SharePoint environments both in collaboration spaces and in intranets. People use subsites to break up content into more granular topics, which often leads to hundreds of sites and a small amount of content in each one. In classic SharePoint, navigation is tied to this hierarchical structure and so there’s a way for people to navigate from site to site reasonably easily.
Modern SharePoint has a flat site structure where each site is its own entity, its own site collection. With a lift and shift approach, you would need to build new sites for each subsite, which could mean hundreds of new sites. There’s also no automatically created navigation in modern, you’d need to develop some way of organizing the experience that would enable people to make their way around those hundreds of sites. Even if you consider creating hubs for your content, the navigation will still need to be manually created for any sites attached to a hub.
Permissions inheritance with sites
In mature SharePoint environments, we often see sites with unique permissions that were created on multiple libraries or lists within a site. Over time, these sites were used for a variety of things they were never originally intended for.
Departmental-based sites become difficult to transition. Organizational changes affect who is responsible for what, so site owners often make the choice to break the inheritance on the site permissions and parse out content into libraries based on who needs to author or access the materials. We also often see a library or two in a collaboration site with permissions that are configured to share content across an organization.
Although you can create these same permissions in a modern site, Microsoft doesn’t recommend it. When you use the built-in SharePoint groups in a communications site or the M365 group created with a team site, the reporting and management of the permissions is easily done using either the Entra ID or SharePoint Administration Centre. When permissions are broken on libraries within the sites, you lose the ability to report and manage the permissions natively and need to start looking at third-party governance tools to report on and manage your permissions. This complicates the ongoing management and governance of your SharePoint environment.
The best way to structure your SharePoint sites
Although you may be tempted or pressured into doing a like-for-like transition, we recommend adopting new information architecture best practices for your SharePoint environment. You may not be able to shift all your existing sites, but the more you lean into topic-based sites and permissions at the site level, the better off your environment will be into the future.
Recommendation 1 – Design collaboration sites for people doing work together
For collaboration spaces, ensure you are focusing your sites on teams doing work together or, in cases of cross-disciplinary work, on projects. Also, ensure internal service teams have spaces for sharing content that is ready to be pushed and shared more broadly, such as an intranet or a workstream- or location-focused publishing/communication site.
For example, during a recent client project, an HR team built themselves new working sites based on the key areas of Total Compensation, Recruitment and Retention and Learning and Development, where they had HR teams managing the work. They also built out separate sites for content related to Workplace Health and Safety Training and specific learning programs, because this work was done in collaboration with people outside of HR. All their published content was moved to an employee-specific area of their intranet and a communication site used by everyone who worked at their manufacturing facility.
Recommendation 2 – Build sites for content with the same purpose
Build out specific sites for managing content that should have the same template, reporting, metadata, or compliance and retention requirements applied to much of it.
We often recommend a contracts-specific site. Contracts are often managed by a smaller group of people in a procurement or supply chain team; however, many people may need access to review the contracts, which likely have retention lifespans and reporting that should be managed and potentially automated.
Similarly, we often see specific sites for managing invoices, job applicant information and health and safety incidents. Separating these sites from the working sites of support teams, such as supply chain, finance and HR, helps with long-term management and hygiene of the information stores in these sites.
For intranet projects, we often suggest putting news in its own site(s), so it can be authored by different groups of people across the organization. This brings a more representative approach to news without compromising permissions on content that may need tighter controls.
Recommendation 3 – For published content, group content by topic or defined audience
When designing information architecture for an intranet we often lean into the recommendation for topic- and audience-based content. This is a different approach than the recommendation for collaboration-based content, where sites are set up for the individual who creates the content. With this approach, end users don’t have to seek out and remember who takes care of what within a company. A social media policy is a good example – would you look to HR, communications or maybe technology for this?
If content is different for different operating locations or roles then it may be optimal to split out sites for that type of content so permissions can be properly managed, or content can be targeted if needed. Otherwise, organize under topics that are widely acceptable and easy to understand, such as Compensation and Benefits, Expenses and Travel, Health and Safety and Technology.
Recommendation 4 – Use hub sites to support navigation and search
Hub sites are a way to connect sites to each other in modern SharePoint. They are more flexible than the classic subsite model, which allows for the purpose of sites to morph over time. A site can only be connected to one hub at a time, but you can remove a site from one hub and attach it to another with a simple configuration change in the SharePoint administration centre.
Sites connected to a hub can share a theme, hub navigation and, if you choose, a search scoped to the hub and all its connected sites.
A couple of key differences that you should consider when using a hub are:
- Hub navigation is manually curated – Added or removed sites need to be managed in the navigation.
- Permissions are not controlled by the hub – Each site has unique permissions.
With our intranet projects, we often rely on a single hub with all the sites of the intranet connected to it. It brings the power of a common look and feel, unified navigation and the creation of a natural boundary for search.
In some cases, where sites have a lot of content, site navigation can be used in addition to the hub navigation to help people who prefer to browse through content.
For collaboration environments, we often suggest hubs for multiple project sites that are run under a greater program of work or sites that are used for teams with a lot of participant cross-over. For example, we would recommend a hub for a greater HR team site but connected sites for the work of the team managing benefits, one for the payroll team and another for the recruiters.
The benefits of good information architecture
Rethinking and strategically planning your SharePoint information architecture can greatly enhance the efficiency and effectiveness of your organization's collaboration and content management. Information architecture is both a science and an art and so it requires work and rework to get it just right. But getting it right will not only serve immediate needs but also scale and evolve with your organization's future demands, ensuring long-term success and sustainability.
