The paths to modern

In our architecture planning, we need to understand the reasons why we need to migrate and the business value it can provide the organization. Considering the following points will help us ascertain who is involved in using modern sites, what they want to accomplish, and how they will use the features of modern SharePoint to collaborate:

• The number of content creators versus content consumers:
  • If a site is for a set of people who will be authoring and co-authoring content together, we should choose a team site
  • If a site is for a few content creators to communicate broadly across departments, to a region, or to the entire organization, we should choose a communication site
• The intended audience – invitation only or an open-door policy:
  • Team sites can either be private or public. Private sites can be extended to new members by having an owner invite them in. Public sites are open to everyone in the organization, but they have to walk in the door on their own. They’re not automatically added.
  • Communication sites are more like classic sites in the way their permissions are managed, so the concept of owners, members, and visitors is essentially unchanged.
• The business needs to be met by creating a site:
  • What is the value and ROI of the site? Who will mainly benefit from the existence of the site? Who will be the content owner and caretaker of the site ensuring timely, accurate, and useful information?

These questions may help us to decide on a template. We can get these templates from the look book mentioned earlier, but applying a template after a site is made is now baked into the UI (https://support.microsoft.com/en-us/office/apply-and-customize-sharepoint-site-templates-39382463-0e45-4d1b-be27-0e96aeec8398). Microsoft provides a base set, automatically filtered to our site template, or custom templates unique to the organization.

The following figures show the UI for browsing for and adding a template to a site after it has already been created:

Figure 1.9 – Choosing a template when a site is created

Once we click Browse templates, we see the list of choices.

Figure 1.10 – Selecting a Microsoft site template

We have a couple more things to consider...

• The type(s) of interaction and collaboration expected:
  • While team sites are better suited for collaboration, the same capabilities exist between either site template type. As such, our choice is largely a matter of intent.
• The biggest exception to that is if you want to add real-time chat interaction via Microsoft Teams. In that case, we must choose the team site backed by an M365 group, so we can add that Teams workspace later on.

1. The role of this site in the larger organizational structure:
   • Is there a site that already exists that serves the same purpose? Does this site logically fit in with another that has similar people and purposes? For example, a Benefits site could likely accompany an HR site.
   • The real action we take from this information is to avoid duplication but also to plan our hubs. Sites that should logically work together can retain their individuality but join a hub to share resources. There will be more to come on that in Chapter 7, Up with Hubs, Down with Subs – Planning Hub Sites.

With responses to these points in mind, let’s turn our attention to the options we have to move from classic to modern. We can start from scratch, migrate/convert a classic experience to modern, or quickly swap our root site to a modern alternative.

Modern from scratch

So, let’s walk through this process of modern site creation end to end. As admins, we can create a new site in the SharePoint admin center. Any user, by default, can create a site from the SharePoint home page. To lock down that capability, we can modify the Pages setting in the admin center. The top checkbox in the following figure would need to be unchecked to disable page creation:

Figure 1.11 – Org-level settings from the SharePoint Online admin center

Once we choose our template, the site will be provisioned within seconds. We then have the option to apply an additional template/site design that contains branding and content. That can be applied when we first visit the site or later in Site Settings. The template can be changed as many times as we need; this will impact the look and feel, but may also add list and library content. Any existing content won’t be impacted or deleted. It will most certainly add a new home page and set it as the default.

Next, we can verify where our home page lives and where any additional pages will be created. Visiting site contents reveals the site pages library. It’s here that we can also create classic pages as well as modern ones. In the following figure, we see that the modern Site Page and the classic Web Part Page and Wiki Page content types live together, allowing us to choose either when creating additional pages on our site:

Figure 1.12 – Menu when adding a new page from a site home page

The ideal experience, however, is to use the Add a page link from the gear settings icon or to use the New menu on the home page to create a new page. This option will allow us to choose a page template to scaffold our new creation. We can either use one of the Microsoft defaults, or we can save pages as templates, for use within the same site collection, back in the site pages library:

Figure 1.13 – Choosing a page template for a new site page

To explore further in the settings, we navigate to Site Information (seen in the following screenshot) to change the logo, title, description, and privacy settings for team sites that may need to go from open to closed or vice versa. The classic site settings page with all the usual configuration options still exists for all site types and is accessible by clicking the link shown at the bottom of the screenshot (View all site settings):

Figure 1.14 – Site settings for a modern site

Site usage takes us into an analytics page, which provides a view into the amount of traffic, popularity of the content, types of devices, and how long people spend on our sites. This data can show up to the last 90 days. Site performance is a relatively new addition that provides some instruction and a download link for the Page Diagnostics for SharePoint tool, which is an add-on for Microsoft Edge browsers. This tool provides deeper technical debugging and performance information. It is available at https://aka.ms/perftool.

Modern from classic

For sites that contain classic pages, we can choose to leave them in place for now or plan to modernize them. These pages will be based on classic Wiki or Web Part content types and contain classic web parts. For a time, the root site collection in our tenants was a classic site, though that default would later change. As such, many organizations built classic sites as the root of their intranets in SharePoint Online. Many organizations have also migrated from SharePoint on-premises to the cloud, leading to sites remaining in classic mode.

If we do plan to modernize classic pages, we can choose between three options:

• Recreate the page from scratch
• Rely on automatic home page modernization
• Use the Page Transformation UI detailed in this reference from Microsoft: https://docs.microsoft.com/en-us/sharepoint/dev/transform/modernize-userinterface-site-pages-model

Automatic modernization only works within a narrow set of parameters defined here: https://docs.microsoft.com/en-us/sharepoint/disable-auto-modernization-classic-home-pages. If your home page is classic, it can be modernized automatically for classic team sites, but no other template. The page has to be called home.aspx and must only contain default web parts with no other content or customization. I see this being most useful in migration scenarios. We can also leverage PowerShell to turn classic team sites into communication sites, complete with full-width pages: https://docs.microsoft.com/en-us/powershell/module/sharepoint-online/Enable-SPOCommSite.

Recreating pages from scratch may seem daunting but it can be a very positive approach. Doing so gives us a great excuse to excise technical debt (to stop holding onto things created in the past that no longer work well or fit the need). It can also give us a chance to revisit the purpose and desired content of the page with business stakeholders. Their needs may have changed or the stakeholders themselves may have changed since the site and pages were first created, and starting from scratch gives us a moment to start fresh with updated requirements.

The Page Transformation UI is not an out-of-the-box product from Microsoft already available in your tenant. It is instead a part of the SharePoint PnP Modernization solution built on the PnP Framework: https://github.com/pnp/pnpframework. The solution essentially takes web part mapping in an XML format and programmatically translates web parts from classic to modern using PowerShell or .NET. The process is that a transformation model file is read, a classic page is analyzed, selectors are made to find impacted page elements, and the mapping is applied, resulting in a new, saved page (https://docs.microsoft.com/en-us/sharepoint/dev/transform/modernize-userinterface-site-pages-model).

This may be a solution for an environment where there is a large volume of sites and pages. The effort is done more up-front by developers to reduce the burden on content owners or creators who may not have the time to do the work of building from scratch. In addition to page mapping, there are also options to map users, metadata terms, page layouts to sections, and so on. Should you choose to go down this route, Microsoft provides a library of scripts to get you started quickly: https://docs.microsoft.com/en-us/sharepoint/dev/transform/modernize-sample-scripts.

Swapping to modern

As noted previously, your home site may have been created using a classic site template. This is likely true if your tenant was created prior to April 2019. While it is easy enough to modernize it by adding the elements we’ve talked about so far, we may have spent time building a modern site elsewhere. A pretty common scenario I’ve seen is for a site, essentially serving as an intranet site, to have been created separately from the root in the /sites path. There has often been some type of JavaScript or another redirect to load that site when someone visits the root URL.

If that is the case in your tenant, you can run a site swap, either through PowerShell or in the SharePoint admin center, to modernize the home site by replacing the root with a site in a different location. The old site is migrated to a new location, which can serve as an archive until we’re sure everything is good to go. This is also a great way to refactor your home site in chunks over time while still keeping a single big-bang reveal. The following figure shows us a screenshot from the SharePoint admin page allowing us to swap a new, modern site into a classic root site:

Figure 1.15 – A screenshot of site swap in the SharePoint admin center

Essentially, we are backing up the current root site (at the root URL for the SharePoint tenant) and then migrating a different site into that URL. To make that happen, our new soon-to-be-root site cannot be connected to an M365 group, can’t already be a hub site (or must have associated sites removed), and shouldn’t contain subsites. On the active sites page of the SharePoint admin center, we would need to select our root site and provide the URL for its proposed replacement, as in the preceding screenshot.

We’ve seen three possible options for moving from classic to modern. These options make sense if we plan to wholly replace classic with modern. That is a solid long-term goal, but we may want or need to have our on-premises farm connect to services running in the cloud.