SharePoint has a long, twenty-year legacy. Over that period, organisations and third-party developers have developed and implemented a range of solutions and options across SharePoint. Many of these have been in place for a long time.
The arrival of the new look, ‘modern’ SharePoint Online (SPO) in the last five years has created a dilemma for organisations – migrate to SPO and lose the older functionality, or retain some of the functionality by creating ‘classic’ sites in SPO?
This post was inspired from discussions with a number of organisations that were either creating or using classic site templates in SPO – sometimes as the default option – or indicated a resistance to moving to SPO because of the ‘loss of functionality’.
What are modern sites in SPO?
The default options to create in SharePoint Online are either (a) modern team sites linked with a Microsoft 365 (M365) Group (most common) or (b) communication sites.
Modern team sites linked with M365 Groups are created:
- From the SP Admin portal (first option ‘Team site’ – above)
- By end users from their SharePoint portal (if that feature is not disabled)
- When a new Team is created via MS Teams or the MS Teams admin portal
- When a new Group is created from Outlook or from the Microsoft 365 admin portal
- When a new ‘shared folder’ is created from OneDrive
Modern team and communication sites are almost identical in terms of core functionality. The primary visible difference is that: (a) team sites have the navigation bar at the left and are usually used to store documents and other digital objects; whereas (b) communication sites have the navigation bar along the top (which can be made into a mega menu easily) and are usually used to store information on pages. They may also store documents in document libraries.
The default page web parts are the same on both; for more information about web parts, see this Microsoft guidance ‘Using web parts on SharePoint pages‘.
For more information about the modern experience see this Microsoft page ‘Guide to the modern experience in SharePoint‘.
The PowerShell script to create a new Group-based site uses the command ‘New-SPOSiteGroup’, which creates both the Group, the SharePoint site, and a Group-based mailbox in Exchange Online.
- New-SPOSiteGroup -Site https://example.sharepoint.com/sites/GroupSiteExample -Group “GroupSiteExample Owners” -PermissionLevels “Full Control”
Note that M365 Group-based sites use the template ‘GROUP#0’.
What are classic sites in SPO?
Other, ‘classic’ SharePoint site templates can be created from the ‘Other Options’ section of the SP Admin portal.
The options, as grouped, are as follows. Note that for all of them, the SharePoint 2013 experience (look and feel) is used.
- Collaboration: Team site (classic experience), Developer Site, Project Site, Community Site
- Enterprise: Document Center, eDiscovery Center, Records Center, Team Site – SharePoint Online configuration, Business Intelligence Center, Compliance Policy Center, Enterprise Search Center, My Site Host, Community Portal, Basic Search Center, Visio Process Repository
- Publishing: Publishing Portal, Enterprise Wiki
- Custom: (if a custom template exists)
SharePoint sites, including using classic templates, can also be created using PowerShell and the ‘New-SPOSite’ command (with additional configuration details, see this Microsoft docs page). The PowerShell command will needs to include the template to be used:
The PowerShell script to create a new classic site is slightly different from a modern Group-based siste, using ‘New-SPOSite’:
- New-SPOSite -Url https://example.sharepoint.com/sites/ClassicTeamSite -Owner peter.smith -StorageQuota 1000 -CompatibilityLevel 15 -LocaleID 1033 -ResourceQuota 300 -Template “STS#0” -TimeZoneId 13 -Title “A classic team site”
Why create SP sites using the classic templates?
Organisations may have genuine technical reasons to want (or need) to create and continue to create some SharePoint Online sites using one of the classic templates. For example:
- They may have many sites that were created in the legacy on-premise environment. Upgrading these sites will take time, so it may be easier simply to migrate from one to another ‘as is’.
- A site or sites may have integration points with other systems that require the older functionality.
Classic sites should not normally be created simply because of loss of (or changed) legacy functionality (e.g., a preference for older style web parts), or simply a preference to continue to use older functionality.
As much as possible, organisations should aim to create modern sites. In some – or many – cases, this may require the organisation to adopt the new modern options.
Classic to modern functionality changes
Examples of broader-level functionality that has largely been replaced with new functionality, or may be deprecated in the future, include:
- Publishing sites were often used for customised intranets, often with multiple levels of sub-sites. These have been replaced by communication sites and hub sites.
- Publishing features, including features sometimes used for navigation purposes and linked with terms in the Term Store were a common ‘classic’ option. These have been replaced by new mega menu functionality.
- Older web parts on pages have been replaced by modern web parts.
- The Document Center and Records Center templates are more or less now superseded by in-place records management functionality, leaving records where they were created or captured.
- The Business Intelligence Center has mostly been replaced by PowerBI or similar tools and interfaces.
- Community Sites and Community Portals have been replaced by communication sites, Teams and Yammer.
- The need for sub-sites has been replaced by creating one or more sites as hub sites and linking other sites to the hub.
Many of these classic options have been around for at least a decade, making it sometimes hard to move to the newer options.
Functionality differences between classic and modern sites
Possibly the most common of the classic sites that continue to be created, however, are classic team sites (‘STS#0’). In some cases, these site templates are the default option. It is not clear why these continue to be created when the STS03 (non M365 Group) template has the same basic functionality:
- The same Site Settings.
- The same ways to add a page, library or list (from Site Contents or from the gear icon – Add an app).
- The same library and list settings (including the ‘Information management policy settings’).
One key difference is the look and feel, something that may become less of an issue with Teams becoming the primary UI to SharePoint.
It is still possible on classic (STS#0) sites to create classic style pages using classic web parts, as can be seen in the screenshot below from a classic (STS#0) site:
What’s the problem with creating new classic sites?
As noted above, however, just because it remains possible to create and use classic functionality isn’t a reason to keep it in face of newer and often better options – especially when end-users won’t even see the site.
From my own experience, anything that remains in an older version of any technology becomes (or is likely to become) technology debt.
It may be appropriate – temporarily – to migrate some older on-premise sites to the classic template until they can be upgraded, but there is no valid reason in my opinion to create new classic sites as a default option for all new sites.
What do you think? Do you continue to create classic sites?
Featured image: A classic VW Combi.