Edit

Share via

Planning your portal launch roll-out plan in SharePoint in Microsoft 365

  • Article

A portal is a SharePoint site on your intranet with many site viewers who consume content on the site. Large organizations could have several portals. For example, a company portal and an HR portal. Typically portals have relatively few people who create and author the site and its content. Most visitors to the portal only read and consume the content.

This article describes how to plan your deployment and roll-out plan to SharePoint in Microsoft 365. It also provides approaches to follow as traditional load testing isn't permitted on SharePoint in Microsoft 365. SharePoint in Microsoft 365 is a cloud service and the load capabilities, health, and overall balance of load in the service are managed by Microsoft.

To help in creating a successful portal, follow the basic principles, practices, and recommendations detailed in Creating, launching, and maintaining a healthy portal.

Portal Launch Scheduler

Use the portal launch scheduler to release your portal to users in your organization in scheduled phases. Learn more:

Calendar icon. Portal Launch Scheduler

Overview of capacity planning in SharePoint in Microsoft 365

In order to efficiently use capacity and deal with unexpected growth, in any farm, we have automation that tracks certain usage scenarios. While exact growth is unpredictable for any one tenant in any one farm, the aggregated sum of requests is predictable over time. By identifying the growth trends in SharePoint in Microsoft 365, we can plan for future expansion. For more information, see Capacity planning and load testing SharePoint.

A key part of a successful launch is the "wave" or "phased roll-out" approach.

Can I load test SharePoint in Microsoft 365?

SharePoint in Microsoft 365 is a shared multi-tenanted environment that is balanced across farms and scale is adjusted in an ongoing basis. Load testing an environment, like SharePoint in Microsoft 365, whose scale changes continuously won't only give you unexpected results but it isn't permitted.

Learn more: Capacity planning and load testing SharePoint in Microsoft 365

Pages from an on-premises deployment shouldn't simply be moved as they are onto SharePoint without reviewing them against recommended guidelines for SharePoint. The best approach is to always optimize any home page for any site or portal in SharePoint, as this is where most users in your organization will access as the starting point for your sites.

A few basic factors should be considered:

  • On-premises deployments can use traditional server-side caches like object cache, output cache, and blob cache. With the topology differences in the cloud, these options aren't necessarily available as the sheer scale differences make them less viable approaches.
  • Any pages / features / customizations used for cloud consumption should be optimized for higher latency and the distributed locations of users, so that users in different areas or regions have a more consistent experience. Cloud offers optimizations like Content Delivery Networks (CDN) to optimize for a distributed user base and for modern SharePoint, the last known good (LKG) is utilized by our out of the box (OOTB) web parts.

What to do:

  • For all site pages in SharePoint, use the Page Diagnostics tool, which is a Chromium extension that assists with analyzing and providing guidance. This tool can be used by site owners, editors, administrators, and developers as it is designed to be a starting point for analysis and optimization.
  • Developers should also use development tools like F12 browser developer tool and CTRL-F12 in the browser on modern pages. Fiddler can also be used to review the size weight (how large the page is in megabytes) of the page and the number of calls and elements impacting the overall page load.

This section was a brief summary for optimizing pages. To learn more, see: Creating, launching, and maintaining a healthy portal.

Follow a Wave / Phased roll-out approach

The traditional big bang approach for site launches won't allow verification that customizations, external sources, services, or processes have been tested at the right scale. This approach doesn't mean that it takes months to launch, but it's recommended over at least several days dependent on your organization size. Following a wave roll-out plan therefore gives you the option to pause and resolve issues before proceeding with the next phase and therefore lowers the potential number of users impacted by any issues. SharePoint as a service scales your capacity based on usage and predicted usage and while we don't need you to notify us of your launch, you should follow the guidelines to ensure success.

As shown in the following image, often the number of users that are invited is higher than those that actually use the site. This image shows a strategy about how to roll out a release. This method helps identify ways to improve the SharePoint site before most the users see it.

Graph showing invited and active users.

In the pilot phase, it's good to get feedback from users that the organization trusts and knows will be engaged. This way it's possible to gauge how the system is being used, and how it's performing.

During each of the waves, gather user feedback around the features and the performance during each wave of deployment. Collecting feedback has the advantage of slowly introducing the system and making improvements as the system gets more use. This also allows us to react to the increased load as the site is rolled out to more users and combined with following the guidelines for page optimization ensures a positive experience for your users.

What to do:

  • Decide on the timing of each phase and ensure that you have a contingency / pause opportunity, should you need to make adjustments before continuing
  • Plan your first group of users that you want to enable, to ensure you receive the feedback you need to move forward. Where possible, select an active group of users that will provide feedback in a timely fashion
  • As you plan each wave, try to start with a small user base (less than 5,000 users). Increase the group sizes as you proceed with each wave. By creating a staggered approach, it allows for easier pause opportunities as needed.