The term modern in this context usually leads us to one of two places. It could simply mean that we are now using SharePoint Online (and the default sites, pages, templates, and other services it provides) rather than using SharePoint Server (SP Server) on-premises. It most likely means that we are using the modern UI components introduced in SharePoint Online and made available to SP Server 2019 as well.

The modern UI components can best be defined as the collection of responsive, client-side UI elements and the structures that support them. These elements provide us with the building blocks of mobile-ready sites that automatically adjust to the screen and device they’re on. The modern UI also provides a tremendously simple editing canvas that should enable both IT and content owners with little technical experience to quickly create and modify the content in a compelling and dynamic way.

There are five core areas where we can see this modern structure shining through:

• Sites (formerly known as site collections)
• Lists and libraries
• Pages
• Web parts
• Navigation

We will take a look at each of these structures in the following sections. Each section will dig deeper into one of the components that comprise modern SharePoint. I like to think of it as a nesting doll with one component containing another. Sites are the big doll with lists, libraries, and pages inside. Pages then contain web parts that we can configure to build our modern UI.

Sites

In SharePoint on-premises, we had a variety of site templates to choose from when provisioning a new site. Most sites were created as team sites, but we could get more specialized as the need arose. While there was a long list of site templates to choose from, they primarily differed in which features were activated by default. In SharePoint Server 2016, there were just over 50 site templates that would be returned when executing the Get-SPOWebTemplate cmdlet. You can see the full list here: https://social.technet.microsoft.com/wiki/contents/articles/52674.sharepoint-server-2019-list-of-all-templates.aspx.

For the most part, we could really just use the blank site template and enable the features we need at the site collection or site level. For example, if you wanted the capabilities of a Document Center site, you could start with a blank site template and add the Document ID and Content Organizer features.

The story is greatly simplified in SharePoint Online. While admins can create classic sites from most of the legacy templates, there are only two modern site templates – Communication site and Team site. Something to remember is that once a site is created from a template, we cannot change that template. Our only hope would be starting over and migrating data, so we must choose wisely. This is the choice we’re given as a user creating sites or the defaults in the admin center:

Figure 1.1 – Team site and Communication site template options

For admins, team sites can come in two flavors, depending on whether you want to connect the site to M365 Groups (which we’ll explore in Chapter 4). Generally, while features are still present to an admin or owner, I have very rarely bothered with feature activation in the modern SharePoint world. Generally, it is no longer needed to make modern sites behave in specific ways. The out-of-the-box configuration is sufficient in most cases.

Lists and libraries

The pages automatically created for viewing lists and libraries will be modern in SharePoint Online by default. You can change this at the site level with the activation of a feature (to be consistent with my previous statement, I’ve never had to do this) called SharePoint Lists and Libraries experience. Activating the feature turns off the modern UI for list pages. You can also use the Advanced list or library settings to change the default list experience on a one-by-one basis. The following figure shows that option:

Figure 1.2 – List experience on the List settings page

While it is possible to make that change for a particular list or even for all lists on a particular site, I wouldn’t recommend it unless you have a compelling reason to do so. These modern pages are crucial to connect our SharePoint sites to features outside the platform (such as Power Apps and Power Automate) and to take advantage of the latest and greatest from Microsoft. The modern UI for system-generated list and library pages (for everything but the calendar that is) no longer features the classic ribbon, but a new streamlined UI filled with modern features, as seen in the following figure:

Figure 1.3 – The menu seen on list and library pages in SharePoint Online

Modern views are also much friendlier to work with and change. We can do so directly on the same page as the list, rather than having to navigate to a separate screen. Therefore, views can be manipulated in place. We can then save them as public or private. We will explore these options further in Chapter 5, Magic Tool in the Toolbox – Integrating SPO with Other Collaboration Tools, when we discuss Microsoft Lists as a standalone service. Lists brings new formatting and other enhancements to a single new app experience where users can interact with list data across sites they have access to as well as their own private lists created in OneDrive for Business.

Pages

For pages that we create, including the home page of the site, we have a great leap forward in ease of use and depth of functionality with modern UI enhancements. We have an entirely new canvas providing easier editing and updating. Modern pages also render correctly whether we’re on a phone, a tablet, or viewing the page on a 49-inch wide-screen monitor. This works because Microsoft has built the underlying page structure to be responsive.

Modern pages are possible because each new modern site contains an enabled site pages feature that gives us a new Site Page content type. A modern page can include multiple sections with different layouts, without the use of the Publishing Infrastructure features or page templates. Moreover, the layout of the section can change as we build our page, so we could have a single, wide panel at the top with a three-column layout just underneath it, and back to a page width section. Section layouts can be changed even after the page is saved and web parts will adjust to fit into their container if they are moved.

On the following page, for example, we have a vertical section down the right side. A hero layout of four images is in a single-column section across the top, and a two-column section with some text and previews/links to videos is just below it. If we moved the hero images to the smaller section below, it would render as a slider, showing one image at a time. The following figure shows a hero layout rendered on a desktop monitor, displaying all four images at once:

Figure 1.4 – A modern SharePoint page from a communication site

Microsoft has created and continues to curate a tremendously valuable resource to make sure we understand and get the most benefit from modern sites. The SharePoint look book contains loads of ideas, documentation, and visual samples, and you can deploy entire sites to your tenant directly from the site as well. The look book is available at https://lookbook.microsoft.com/.

Web parts

Classic pages are built with classic web parts. Modern pages are composed of modern web parts. That may sound elementary, but it is crucial to understand that we cannot mix and match components between the two worlds. They’re both building blocks, but one is like LEGO bricks while the other is like Mega Bloks. They simply don’t fit together.

Modern web parts are responsive, just like the pages that host them. When a page is placed into edit mode, so are all of the web parts, so there are fewer clicks for our content owners. The Edit panel that opens for each web part is also simpler and more consistent with the rest of the modern UI. Just look for a pencil icon to click and the details panel will open on the right:

Figure 1.5 – Editing a modern web part

The look book noted earlier does a great job of indicating which web parts have been used with each template’s home page, with hyperlinks to the Microsoft documentation to explain how to use each one.

Navigation

In both classic and modern SharePoint, we have navigation elements that can be hosted in one of two locations on the page. Team sites still provide a left-hand quick launch, while site navigation can still be found at the top of the page. Adding and editing links becomes more streamlined with the owner’s ability to edit the navigation in place and use the Change the Look menu to decide on a more traditional Cascading look or the more updated Mega menu:

Figure 1.6 – An example of Mega menu

The biggest change to navigation in the modern world is through the use of hub sites, which we will explore in much greater depth in Chapter 7, Up with Hubs, Down with Subs – Planning Hub Sites. A hub provides a way for one site to be the logical parent of other sites. One advantage of this functionality is to provide global navigation that is at the very top of the page, above the site’s navigation, which is consistent across all sites that are connected to a given hub. We can also use that same global navigation to supply links to the SharePoint Online app bar. The app bar is designed to be sticky to the left-hand side of all SharePoint Online sites and to also drive the Viva Connections experience in Teams, referenced in greater detail at https://docs.microsoft.com/en-us/viva/connections/sharepoint-app-bar. The following figure shows us the app bar:

Figure 1.7 – SharePoint app bar

We’ve taken a look at the five core components of the modern experience in SharePoint Online. Understanding these elements will guide us through the rest of this book. However, to truly appreciate the modern world, we should spend a little time pondering the past and remember classic SharePoint.

Since we’ve defined key elements of the modern experience in SharePoint Online, we can now generally say that the classic experience is the one we find in SharePoint on-premises, especially between 2007 to 2016. For this chapter, let’s collectively refer to the UI and features associated with it as SharePoint classic. Let’s do so with the understanding that SharePoint 2016 has some of the modern features available in SharePoint Online and SharePoint 2019 has most of them.

Rather than reviewing all the templates, features, web parts, capabilities, and irritating quirks of the platform, let’s review the top 10 components that either disappear entirely or become deprecated with a move to modern SharePoint Online:

• Your own servers: This might seem obvious, but it is highly impactful. Managing the infrastructure, including search, updates, failover, and so on, is no longer necessary. That means that we no longer have a Central Administration site, can’t bump up the list view threshold, and don’t have to worry about creating site collections that consume a new content database.
• Full trust solutions: Custom server-side code deployed via farm solutions or sandbox solutions is no longer supported in SharePoint Online, regardless of whether we have classic or modern sites.
• Custom master pages and Cascading Style Sheets (CSS): Support for this resides only with classic sites. We’ll look at this in more detail in Chapter 3, Modern Options for Customizing SharePoint Online, but suffice it to say that the concept of branding SharePoint so that it’s no longer recognizable is a thing of the past.
• Content Editor and Script Editor web parts: The option to embed HTML, CSS, and JavaScript that impacts the entire containing page is no longer possible with SharePoint Online.
• Classic site templates: Specialized templates such as Document Center, Record Center, and Search Center are the exclusive domain of the classic world. Admins can create many of these in SharePoint Online, but the UI will be in classic mode.
• Pages and publishing: Wiki pages and web part pages are relics of the past and not possible with the modern UI. The Publishing Infrastructure features also remain in the classic world. We don’t really need them with modern SharePoint with page sections, SharePoint News, and Power Automate to help us with approvals, but the features are still available in SharePoint Online with classic UI sites.
• Search web parts: The ability to add search boxes, results, refinement panels, and others is limited to classic pages, so we can’t build our own search pages out of the box.
• SharePoint Designer (SPD): The link to the tool is hidden from the UI of modern lists and libraries. By default, modern sites don’t allow Custom Script, which means it wouldn’t be supported anyway. Editing site pages in SPD doesn’t really work, and workflows are now best created in Power Automate.
• InfoPath: This tool is the zombie of the SharePoint world. Officially dead (OK, deprecated, but the date of death has been announced) since 2014 but still walking around, consuming brains, and refusing to go away until support ends in July 2026. While InfoPath still works in SharePoint Online, we can’t access it from the menu of modern pages, and the future lies in Power Apps.
• Information management: This one is a little different from the others in that it isn’t part of a revamped UI, but is a function of SharePoint on-premises that goes away in favor of a richer alternative. Information management policies at the site collection, content type, or library level were built into SharePoint Server and provided retention, auditing, barcodes, and labels. This is now part of the Security & Compliance Center in M365 and provides a unified solution across content sources in the cloud, not just SharePoint.

While much of SharePoint remains intact, we can clearly see the changes Microsoft has made to frame the future for SharePoint. However, we can’t speak of SharePoint Online in terms of exclusively classic or exclusively modern. The two worlds can live together.

SharePoint Online fully supports the modern UI, but it’s not just moving to the cloud that provides its features. SharePoint Server 2016 and earlier do not support modern features or functionality. It is, however, possible to remain on-premises and have some of the modern UI elements as part of our SharePoint Server 2019 farm, which includes the following:

• Communication and team sites (though no connections to M365 Groups)
• Modern lists and libraries (though not Power Apps or Power Automate without being a hybrid)
• Site pages
• Modern web parts (though not the full list we see in SharePoint Online)
• Refreshed navigation and an M365-style app launcher (but no hub sites, app bar, or global navigation)

So, we can stay on-premises and still have some nice, new things – like watching an 8K TV from a 70s recliner. The flip side of that is we can move to SharePoint Online and still hold on to our classic treasures. The great C/M divide may be more of a blurry line than a solid one.

Maybe we can think of SharePoint sites as a mixed skyline. One of my favorite cities is Boston. Walking through the city, we can view a skyline filled with old stone churches and modern glass and steel structures. The change over almost 400 years is constantly on display, as seen in the following photo:

Figure 1.8 – Classic and modern buildings together in Boston

Microsoft tells us “The ‘classic’ experience is not being deprecated; both ‘classic’ and ‘modern’ will coexist.” That quote is taken from this guidance related to modernizing the UI: https://docs.microsoft.com/en-us/sharepoint/dev/transform/modernize-userinterface. Well…Latin is still spoken today, but there’s little new and exciting coming to the world of Latin. Our goal should be to utilize modern SharePoint whenever possible, with eyes wide open to the fact that some classic pieces may still be needed.

In SharePoint Online, both classic sites and modern sites can coexist within the tenant. As a matter of fact, it’s possible for modern sites to have classic pages and for classic sites to have modern pages. While we can’t mix and match classic and modern web parts, the two worlds can live side by side. So, what really makes a modern site modern?

The short answer is the template we start with and the features we use. Modern team sites and communication sites create a place for us to work that has all the modern amenities. Greater detail about those amenities can be found here: https://support.microsoft.com/en-us/office/sharepoint-classic-and-modern-experiences-5725c103-505d-4a6e-9350-300d3ec7d73f. Starting with a modern template enables the following, thus enabling the modern experiences in SharePoint Online:

• The site pages feature is activated by default
• The home page is a modern page built from the Site Page content type composed of modern web parts
• The list and library UI is set to the new experience by default
• Modern search is utilized by default
• Modern site management is available from the gear icon, which allows us to see site performance, usage, modern theming, easier site permissions management, and site templates

Once that modern site is created, all new pages will be modern by default. We can, however, add classic pages as well. We can also leverage site collections and site features if we really need to retain some classic functionality. So, why do we want to keep a foot in both worlds?

In some remote instances, we must. One good example is the Events (or calendar) list. While there is an events web part to display them on a page, the list itself still renders in classic mode (old UI, ribbon, and all). I assume it’s hard to get a table layout to be responsive.

We may also have invested a good deal of time and money in building out some highly customized pages that don’t have a direct one-to-one translation to modern web parts. We may have a robust master page that will either take significant refactoring or a total redesign. There are certainly valid reasons to keep classic pages in place, though modernizing should be seen as an eventual requirement.

Let’s look deeper into how the worlds can coexist from two perspectives. First, building a new modern site from scratch, and second, how to modernize a classic site.

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.

So, we have classic and modern, on-premises and online, Marvel and DC, and pizza and burgers. Sometimes it’s hard to choose just one. For those of us who still have an on-premises SharePoint farm but want to modernize, maybe we don’t have to. SharePoint Server 2013, 2016, and 2019 all provide some support for hybrid workloads, which allows us to leverage the best of both worlds. Remember, only SharePoint 2019 gives us the option to implement the modern UI, however.

Figure 1.16 – Hybrid combines on-premises and online

As part of our planning to move to SharePoint Online, we may find that certain compliance or security concerns or the need for connections to other systems dictate that we at least keep some kind of on-premises presence. Microsoft has some great guidance here: https://docs.microsoft.com/en-us/sharepoint/hybrid/plan-sharepoint-server-hybrid. A few key ideas to consider when planning for hybrid follow. These represent the most widely used and perhaps the most valuable hybrid workloads.

Hybrid search

If your content is going to live in two worlds, having a unified way to find what you need will become crucial. A hybrid search is available in SharePoint 2013–2019. Cloud hybrid search and hybrid federated search are two options for implementing this. The former indexes all your contents in the cloud. The latter creates two indexes that can feed search results from both places in response to a single search query.

So, both solutions provide results from both places. The question is whether we want to have two different search results with their own rankings, refiners, and others, or one single combined set. We may also need to make sure we plan for content that is highly sensitive that doesn’t need to be indexed in the cloud. For that, we would choose the federated route.

Hybrid OneDrive

This feature allows you to leverage OneDrive for Business for personal work-related content in the cloud while keeping your SharePoint site on-premises. This may be a great option for organizations that are slowly moving away from their farms to M365 but are not able to move everything at once.

Our users could take advantage of 1 TB of cloud storage per user, accessible from any device that can be shared externally, while we plan for SharePoint migrations over time. The configuration here would redirect the on-premises link to a user’s My Site to the cloud instead.

Hybrid app launcher

The last hybrid workload we should note at this point helps us to have a consistent user experience when navigating. The app launcher, or waffle, in M365 is a grid in the upper left that opens a list of apps and services we have access to. It is really the global navigation across the M365 toolbox.

Enabling this feature on-premises allows custom tiles you’ve pinned to exist side by side with the same list of apps your users would see if they were browsing SharePoint Online. This feature is connected to Hybrid Sites in SharePoint 2016, which includes site following and profiles as well.

There are a few additional features we need to review to understand the possibilities in modern SharePoint. These features provide a backbone for communication and corporate identity within and across modern SharePoint sites:

• News pages
• Dynamic web parts
• Headers and footers
• SharePoint domain name

News pages are just site pages with the Promoted State metadata column equal to 1 or 2 (1 is unpublished news, 2 is published, and 0 is a standard site page) and an additional metadata column of First Published Date, which identifies their purpose to SharePoint. They can be built in the same way as other modern pages, though their content is often simpler and more focused on text than images. The real power is on the receiving end.

The News web part can gather news stories from across sites in SharePoint Online, including those within a hub, or sites that we manually include. This is great for an intranet home page because content creators can generate news from their own sites (where they have edit access) and have those automatically roll up to a central location.

In addition to the News web part, we can also see that same news published on the SharePoint home page where we can see news from all the sites we have access to. The SharePoint mobile app rolls up the news in a similar way and can provide push notifications to let users know something new is available. News can also be surfaced in Microsoft Teams tabs or channel chats via a connector.

Given all the places news can surface, it certainly beats sending all-company emails and would be available historically for new employees to see, even if they joined after it was created. By the way, we can still go into a news item or the news digest and send those emails out (with links to the story) if we can’t break that habit.

Other web parts that keep our sites fresh and compelling with dynamically updated content include the following:

• Weather and Twitter web parts that connect to external data
• The Recent Documents, Sites, and My Feed web parts provide personalized content unique to each user viewing the site
• The Events web part can roll up SharePoint calendar events from across sites in a similar fashion as the News web part

Microsoft has compiled a single web resource to help us understand the entire set of modern web parts: https://support.microsoft.com/en-us/office/using-web-parts-on-sharepoint-pages-336e8e92-3e2d-4298-ae01-d404bbe751e0.

Modern headers and footers give us the option to create consistent site experiences. In addition to the logo and title we’ve always had on SharePoint sites, we can also choose to have a color or an image across the top of our pages to put our corporate branding front and center. If we prefer a more minimalist approach, we have that option too, plus the user can choose to expand or collapse the header on the fly when they view our site. In Chapter 7, we’ll look at hub sites as a way to keep the consistency of the color theme across a set of connected sites.

Figure 1.17 – Changing the look on a modern site

We can add a site footer to communication site pages created from the Site Page template (which would exclude list/library pages). This provides a band along the bottom of the page with colors matching our branding, a small logo, and some text-based hyperlinks. This would have taken some customization to accomplish in classic SharePoint.

The final feature of note doesn’t impact the UI but can have a significant role in corporate identity. When a tenant is created, the domain portion of the URL for SharePoint is the same as the tenant name. Until recently, we’ve been stuck with that unless we go through a painful tenant-to-tenant migration. Now, we can change the tenant portion of the name for SharePoint to better reflect our needs. For example, if we created our tenant as coolstuff2021.sharepoint.com, we can change it to CoolThings.sharepoint.com.

This may come in handy if the organization has gone through a rebranding, a merger with another company, or an acquired company needs to take on the new parent’s organization branding. While our tenant name, email addresses, and so on do not change, we can update the SharePoint and OneDrive URLs once every 6 months. If the need arises, the most up-to-date guidance from Microsoft may be found here:

https://docs.microsoft.com/en-us/sharepoint/change-your-sharepoint-domain-name

Now that we’ve explored some key differences between the classic world of SharePoint on-premises and the modern world of SharePoint Online, let’s take a look at some planning considerations for configuring and governing SharePoint in the Microsoft cloud.

Ask 10 people what IT governance means and you’re going to get 11 answers. Sometimes we picture a single, large, and dusty document that contains all the rules we should follow. Many erroneously think of security when governance is mentioned. Most simply glaze over or quickly change the subject.

From my perspective, governance is the gatekeeper of good adoption. One small component of any good governance plan is making sure that the service configurations are aligned with best practices and business expectations.

While SharePoint will be configured with default settings and users will automatically have a SharePoint and OneDrive license enabled as part of their M365 license entitlements, we may want to verify some of those settings to ensure it is adopted in the way we desire.

External sharing

Should our users be able to share documents stored in SharePoint or OneDrive for Business sites with those outside the organization? In the SharePoint admin center, under Policies | Sharing, we can set up the guardrails with the option to alter the setting for individual sites if the need arises. We can also decide to only let users within specific Azure AD security groups share content externally (maybe vendor management, sales staff, etc.).

Figure 1.18 – Sharing permission settings for SharePoint and OneDrive

As part of our planning, we need to decide whether our users will be able to add new guests along the way by simply entering their email, or whether guests (anyone outside the organization) should be added in advance to Azure AD by an IT admin. That is the primary difference between the second and third options in the list in the preceding figure. The last option in the list limits sharing to only licensed users in the tenant. The first option should rarely, if ever, be used, in my opinion.

Setting the default experience for sharing links can go a long way toward driving the right adoption habits as well. Though site owners can alter the defaults for their site and the options can be changed each time something is shared, changing the defaults here is a definite recommendation. By default, we have these options selected:

Figure 1.19 – Options in the sharing dialog for SharePoint and OneDrive

This is pretty much like sharing something with everyone at once. If links are forwarded, they’ll work for anyone in your organization that opens the link. Having Edit selected means that anyone who opens a document will be able to make changes to it right away. My experience has been that we are better off defining specific people with whom we want to share, and only allowing them to view by default, making co-authoring the exception when sharing. These may be better default values to start with (with a deeper dive found at https://docs.microsoft.com/en-us/sharepoint/turn-external-sharing-on-or-off):

Figure 1.20 – Same options with specific people and view options chosen

Settings

A handful of settings can make a significant impact on governance and adoption. In the admin center, when we click on Settings, we get the following view:

Figure 1.21 – Settings listed in the SharePoint admin center

We’ve already discussed the value of the Site creation setting, where we can limit whether users can create new modern sites (what we would have called site collections in classic SharePoint). We can globally limit whether users should be able to create new pages. When disabled, anyone with permissions could still create News pages, but we’ll probably be better off leaving this on and allowing it to be managed by site owners. Controlling permissions to the site pages library is likely our best bet.

There may be some value in turning off comments globally, however. These comments are unmoderated and only scratch the surface of providing the kind of engaging experience that Microsoft Teams chats or Yammer discussions could provide.

The other setting we should be mindful to plan for is the home site. The setting just takes a URL (most likely the root intranet site), but the significance behind it impacts several future capabilities. Setting the home site is going to be crucial for enabling Viva Connections later on. It is also necessary for the app bar to work and automatically gives us a site that acts as an official organizational news source (https://docs.microsoft.com/en-us/sharepoint/organization-news-site).

In this chapter, we’ve learned about the building blocks of a modern SharePoint site. The five core blocks are sites, lists and libraries, pages, web parts, and navigation. Classic pages in SharePoint use a classic set of components, while modern pages use a different set. This new set provides a responsive design that is much more user-friendly for editing and maintaining by a business user, not by IT.

We explored the classic world of SharePoint, which can still coexist with modern in the cloud. We discussed potential paths for moving from classic to modern. For environments where an on-premises presence can’t be entirely removed, we looked at the possibility of hybrid workloads. We concluded with a note about IT governance with an eye toward sharing capabilities that those new to the cloud will find exciting but possibly confusing.

At the close of each chapter, I want to distill the information we’ve reviewed while also giving you a template to create your own SharePoint architect’s planning and governance guide. This is really just a recap of the pieces we should be accounting for when moving to SharePoint Online, either from a classic past or as the first foray into a Microsoft cloud future.

Configuration and governance

The following is what we have learned about configuration and governance:

• External sharing:
  • Which business units or users require sharing outside the organization?
  • What should the global default be?
• Site creators:
  • Should everyone be able to create a site when they want it?
  • Should IT create all sites in the admin center?
  • How do users make a request if the self-service option is removed?
• Page comments:
  • Should comments be allowed?
  • Is there another tool available to capture and moderate comments and discussions?

Site planning

The following are the notes to remember about site planning:

• Home site:
  • Has a home site been created and set in the admin center?
  • Are you using the root site as the home site?
  • Do you have a classic site or modern site at the root URL?
  • Have you built a site elsewhere that should be swapped to the root URL to serve as the home site?
  • Does the SharePoint domain in the URL reflect the organizational identity or does it need to be changed?
• Departmental sites:
  • Does each department/location/organizational unit have a SharePoint site?
  • Does a site need to be available to just users inside the department or is it for org-wide consumption?
  • Does the home page of the site need to be modernized?
• Site owners:
  • Who should be the owners of new sites?
  • Will site owners and content creators be the same?
• Pages:
  • Should both classic and modern pages be allowed on new sites?
  • Are there pages in classic mode that need to be modernized?
  • Are there pages that must remain in classic mode due to the presence of and need for customizations?
  • Are important pages reflected in the site’s navigation?
  • Who is responsible for creating official SharePoint news?

Architecture

The following are the notes to remember about architecture:

• Hybrid:
  • Are there still on-premises SharePoint servers?
  • Do we need to keep any workloads or data on-premises?
  • Do we have a production M365 tenant with other workloads configured?
  • Can any of those workloads be integrated with our on-premises farm?
  • Do we need to configure a hybrid search? If so, where should the index reside – on-premises or cloud?
• Personal sites:
  • Do all users have a OneDrive site that has been provisioned?
  • Are all users aware of their OneDrive for Business storage?

In the next chapter, we will explore the process and tooling that will help us plan to migrate our content from on-premises to the cloud. This will give us a complete picture of the steps needed to get into the modern SharePoint world, which will set up the remainder of this book and allow us to focus on deeper details to build our planning guide for SharePoint and Office 365.

• Learn more about Sharepoint here: https://docs.microsoft.com/en-us/viva/connections/sharepoint-app-bar
• Details about classic and modern amenities are available here: https://support.microsoft.com/en-us/office/sharepoint-classic-and-modern-experiences-5725c103-505d-4a6e-9350-300d3ec7d73f
• More details about SharePoint site templates are available here: https://support.microsoft.com/en-us/office/apply-and-customize-sharepoint-site-templates-39382463-0e45-4d1b-be27-0e96aeec8398