Recent advances in SharePoint Online have helped improve collaborative experiences for people at Microsoft. Adopting modern sites—including the SharePoint Framework, communication sites, and hub sites—has strengthened our intranet, improved search and collaboration, and reduced development and design costs. By default, our intranet sites created in SharePoint Online are accessible and responsive—and they carry a consistent look and feel across the company.


At Microsoft Core Services Engineering and Operations (CSEO), we’re responsible for providing and maintaining the infrastructure and technology that enables effective collaboration throughout the intranet for over 200,000 Microsoft users. Our primary platform for content-driven collaboration is SharePoint for Office 365 and its ability to integrate with the rest of the Office 365 suite provides immediate integration into our cloud environment.

Recent advances in SharePoint have dramatically improved the quality, accessibility, performance, and usability of the platform for our users and publishers. New features—like communication sites, SharePoint hub sites, and modern groups—are now combined with foundational elements—like the user profile store, search, and taxonomy—to build the backbone of the Microsoft intranet.

Improvements in the platform, new development capabilities enabled by the SharePoint Framework (SPFx), and client-side web parts mean that it’s never been easier for us to develop and publish attractive, highly functional intranet sites. In less than a year since we started using communication sites internally, more than 55 percent of our internal publishing sites have switched over to communication sites in SharePoint for Office 365. And it’s all accessible from your pocket by using the SharePoint mobile app.

The SharePoint landscape at Microsoft

SharePoint has been the primary collaboration platform for our intranet and extranet solutions that have served our users for years. SharePoint has been our default platform for intranet sites at CSEO since building our first corporate communications portal in 2003. Historically, we hosted on-premises SharePoint Server infrastructure in our on-premises datacenters and perimeter networks, but since the internal rollout of SharePoint Online in 2011, we’ve gradually converted all our major sites for internal functions such as HR, Finance, Communications, Sales, and Learning to run in the cloud on SharePoint Online.

Traditional design and deployment

For years, SharePoint was designed to provide a robust platform on which interesting sites could be built. Although powerful, the default sites had some shortcomings:

  • The default site template was very nondescript and basic. If our developers wanted to build an attractive site, they had to go above and beyond the default template. This meant customization and extra work for developers and an extra step in the publishing process.
  • Customization was developer intensive. Customization of site functionality, navigation elements, and design required developer involvement. Achieving a user experience that the business would be happy with required a heavy investment in master pages, CSS, JavaScript, and web parts.
  • Sites were not responsive by default. The traditional site types were designed for a PC browser, and the mobile rendering of traditional sites often produced unattractive or partially non-functional results on mobile devices.
  • Sites were not accessible by default. Accessibility in the default templates wasn’t up to the standards we wanted. Our intranet sites didn’t provide proper interaction with tools like screen readers or high-contrast color schemes by default. It took design and developer effort on each site to make it accessible.

To mitigate some of these challenges, CSEO engineering teams developed SharePoint site design packages that gave site owners a head-start on building an attractive, useful, accessible, and responsive site experience. By applying site designs, we could jumpstart the build process while saving businesses time and development budget. The site designs were effective, but they required ongoing development and maintenance.

Our move to the cloud

Microsoft has been a cloud-default organization since 2015. Our organization runs on cloud computing—that’s reflected in how we’ve treated our SharePoint infrastructure. We’ve moved our SharePoint infrastructure out of our on-premises datacenters and into Microsoft Azure and Office 365 to take advantage of cloud agility, scalability, and reliability across our IT infrastructure.

Cloud-based collaboration provides several basic advantages to our organizations:

  • All sites and tools are in one service, from one vendor.
  • Personal and business sites are all within the same administrative and functional scope.
  • All sites are designed, developed, and managed with the same toolset and in the same environment.

Hybrid cloud content management

Our current environment is still hybrid by design, but the vast majority of our SharePoint infrastructure is now hosted in SharePoint Online. The list of reasons for us to retain data and apps in the on-premises environment decreases every year, but they include:

  • Keeping content in a geographic region to meet regulatory requirements. We expect the new Multi-Geo feature will allow us to retire this requirement in 2019.
  • Maintaining functionality with older business information systems and apps.
  • Large org-to-org extranet scenarios.
  • Keeping highly customized content that needs further development or restructuring before being migrated to the cloud.

Thanks to advances in SharePoint Online, nearly 98 percent of our SharePoint site collections are now hosted in the cloud.

Enabling self-service and creative collaboration

Our primary goal in our move to the cloud and adoption of SharePoint Online is to create an environment where our users can embrace creative collaboration and feel empowered to do so in the best way for them. Our move to the cloud has enabled a greater level of self-service for our users, and as we move toward the modern SharePoint experience, our self-services capabilities and creative collaboration opportunities are increasing.

As part of our governance and security procedures, we manage site creation capabilities very closely. With SharePoint Online, we can let our users create and administer their own sites, determine what kind of sites they can create, and specify the location of the sites.

The journey to modern SharePoint sites

SharePoint Online has continued to evolve into a complete and modern collaborative tool, and we’re using the latest features of SharePoint Online to drive collaboration and a better user experience across all our sites. Our approach to modernization consists of the following key elements:

  • Shift to modern sites as our default site types. Though we enable self-service site provisioning for our end users, we now only allow the provisioning of modern site types: groups-connected team sites and communication sites.
  • All of our development is SharePoint Framework (SPFx) first. This allows customizations to be reused across both classic and modern site types, easing the transition to modern by reducing future rework.
  • Hub Sites. This enables us to aggregate sites by purpose, division, region, or business unit.
  • Site Designs. Advances in Site Designs allow us to automate the site-provisioning process to build sites appropriate to the business need faster than ever before.
  • Audience targeting. The new audience-targeting feature lets us target content to relevant audiences, improving the value of our internal sites.
An illustration showing CSEO's five key elements to site modernization.

Figure 1. The CSEO approach to site modernization

Our move to modern sites

For Microsoft, moving to modern sites means putting greater capabilities into our users’ hands while removing the traditional IT barriers to a truly self-service and user-friendly SharePoint experience. With SharePoint Online, we now have user experiences that out of the box:

  • Are accessible by default. Modern sites offer built-in support for ideal color contrast, alternative text, and other features that make them accessible to as many of our users as possible.
  • Are responsive by default. Modern sites are designed to accommodate a wide range of devices and platforms, so that they’re attractive and useful—regardless of how our users access them.
  • Are attractive without needing a power user or developer. Modern sites are simple to design and deploy. We don’t need to enlist developers or additional IT support to get our sites up and running the way we want them.
  • Enable our self-service culture. Any user can create a useful, attractive, responsive site without requiring services from IT or a developer

The following screenshots are examples of SharePoint team sites, both classic and modern.

A screenshot of the default classic team site experience.

Figure 2a. The improved default team site experience, classic sites versus modern sites

A screenshot of the default modern team site experience.

Figure 2b. The improved default team site experience, classic sites versus modern sites

Communication sites and site designs

We’re using communication sites in SharePoint Online as the default building block for sites that host our major internal business functions now and going forward. Communication sites provide a great place to share information with others. We can share news, reports, statuses, and other information in a modern, visually compelling format. Coupling hub sites with site designs offers some major benefits to the sites that use them and to the content creators that are working with the sites:

  • Look and feel is consistent and attractive throughout a collection of sites. Modern templates already offer an attractive design out of the box. The association to hub sites ensures consistent hub-wide navigation and search functionality across all sites in the hub, along with consistent branding and design. As a result, it’s much easier for our businesses to maintain an attractive and consistent user experience.
  • Site designs can be applied at creation or after creation. Users can easily create an on-theme, on-brand communication site by selecting a site design at Site Creation time or by clicking Create Site within an existing hub. They can also apply a site design manually after creation by selecting an available site design from Settings > Site Information.
  • Easing provisioning by automating repetitive tasks. Site designs can be used to install web parts, create lists and libraries, apply conditional formatting, kick off a Microsoft Flow automatically, and much more. Application of Site Designs is cumulative—a newly applied site design that changes a value set by a previous site design will overwrite the value set.
  • Admins manage site design permissions at the team and user level. Admins on the CSEO team decide which site designs and settings are shown to each team. Using security groups, we can control which site designs are visible to our users. We’ll use this to ensure proper branding and theming for our major business sites, and we’ll soon use it to ensure consistency of sites across our divisions.
  • Any team or developer can submit new site designs to CSEO. After a review to make sure the site designs are taking approved actions, we upload them and set all necessary permissions, making them available in the site design gallery for our users.
  • Cost savings thanks to modern templates and site designs. The new modern templates have democratized the SharePoint site-building experience. The design and implementation process for a modern site is much simpler in that building an attractive, responsive site that solves a business need no longer requires a developer in most cases. Where development resources are needed, the combination of hubs and site designs with other new features such as the SharePoint Framework mean faster build times for our users.

The following screenshot shows our internal corporate communications site, MSW, which takes advantage of many of these features:

A screenshot of MSW,  an internal communication site for employees.

Figure 3. MSW, an internal communication site for employees, was built using mostly out-of-box features

SharePoint Framework web parts

We’re using the SharePoint Framework (SPFx) to create web parts and pages across all our SharePoint installations. SPFx provides an open-standards-based development model, so our engineers already familiar with common web development approaches can, with minimal relearning, design and implement functionality that works well with SharePoint. In addition, both modern and classic SharePoint site types can use SPFx web parts, which reduces the amount of rework needed when transitioning from classic to modern. There’s no need to relearn, retrain, or rewrite.

Embracing an agnostic, open platform

That SPFx is platform agnostic is a huge advantage for us. We can have our best engineers developing for SharePoint regardless of their preferred development platform. They don’t have to learn a new integrated development environment (IDE) or toolset. Although we default to using REACT for development internally, we can use other approaches in our solutions (e.g., JavaScript, TypeScript, Angular) if needed.

SharePoint Framework web parts provide several specific development advantages, including:

  • It runs in the browser in the context of the current user.
  • The controls are responsive and accessible by nature.
  • It is framework-agnostic.
  • Performance is reliable.
  • End users can use SPFx client-side solutions on all sites, including self-service team, group, or personal sites.
  • SPFx web parts can be added to both classic and modern pages.

The biggest tangible benefits that the SharePoint Framework web parts brought to us are money and time savings. Specifically:

  • When we need a web part, nearly every web developer can now be a SharePoint developer with limited ramping up of skills needed.
  • Common patterns used across the internet work in the SharePoint world saving a lot of time in building our solutions from scratch.

Hub sites and site designs

Using SharePoint hub sites, we can apply and maintain a hierarchical structure to carry design elements across sites with related purposes. Hub sites help us meet the needs of our organization by connecting and organizing sites based on project, department, division, region, or other factors, making it easier for our employees to:

  • Apply common navigation and branding across the hub and associated sites.
  • Search across all associated sites.
  • Aggregate news content and events across all sites.

To achieve these results, we’re using a couple of key features of hub sites:

  • Shared navigation. Hub sites are connected back to the parent site with the hub site navigation bar. It provides comprehensive navigation across a set of hub sites. We frequently customize the hub site navigation bar to fit the specific needs of each hub.
  • Search across the hub. When users search at the hub level, results are sourced from every site associated with the hub, with one important caveat—users cannot see content from sites they are not permitted to access.

The following graphic shows an example hub site that’s built around a major business function—in this case, Microsoft CSEWeb. CSEWeb serves as the hub and aggregation point, while major IT-related areas (e.g., collaboration, meetings and voice, finding) are represented in associated team or communication sites.

A graphic showing a hub site built for CSEWeb. Attached to the hub site are team sites and communication sites.

Figure 4. An example of a hub site built around CSEWeb, our internal IT landing page.

Sites attached to a hub inherit its branding and navigation by default. Default site designs can be configured at the hub level to ensure that when new sites are associated to the desired elements, the following can be applied (but are not limited to):

  • Creating lists and libraries, including the application of conditional formatting
  • Setting permissions
  • Installing web parts
  • Updating local navigation
  • Applying site columns

These changes to the attached site’s design function as an overwrite, not an uninstall or reinstall of previously applied site designs. Creators can also work backwards and apply existing communication site designs to their hubs.

As it improves the usability of sites across the hub, this feature has already made it much easier for users to reorganize sites around new hubs when teams reorganize or when projects change. There’s no longer any need for a cutover or a loss of visibility because site owners or IT can reassociate their sites to meet the changes in organizational structure. When they’re ready, they detach existing sites from the old hub or classic parent site and attach them to the new hub, automatically inheriting the new hub’s design and settings.

Building intranet sites on a reliable and agile foundation

Our approach to modern design and functionality in SharePoint Online is dependent on a number of foundational features and functions within SharePoint Online and the greater Office 365 landscape. We’re taking advantage of several aspects of modern SharePoint functionality to make the intranet site experience even better for our users.

Personalizing the experience with audience targeting

Thoughtful audience targeting puts the right content in front of the right people. It results in smoother, more reliable communication for site owners and a more useful experience for site users. Audience targeting helps us deliver the most current content, improve search and taxonomy, and provide a better sense of how and how much our users are consuming content.

Classic audience targeting

Classic audience targeting pulls data from the user profile store. The user profile store is a repository of user data that can power workflows or customize the content displayed to end users. Three sources for the data are found in the user profile store:

  • Azure Active Directory (Azure AD). Azure AD serves as the default directory source for data in the user profile store. By default, 24 Azure AD account attributes are imported to the user profile store.
  • User-supplied data. All licensed users can provide data from their Delve user profile page, which stores its data in Azure AD.
  • Bulk import API. Most powerfully for our internal sites, we’re also using the bulk import API to populate an additional 30 attributes of user profile information from internal HR and retail store data sources into the user profile store. The imported attributes are a combination of both raw data (such as the store number that a retail employee works in) and calculated data (such as which top-level organizational manager a user reports to in the org chart). With this additional information, we can ensure that all the user data that’s relevant to our organization is in one place for SharePoint Online to access.

Here are some examples of how this data enables classic audience targeting:

  • New user onboarding. We can use an attribute in the store that contains the date on which a user started at Microsoft to determine whether that user is a new user. Based on this information, we can provide tutorial content on certain pages, provide new-hire task lists for certain sites, and make sure the user is exposed to exactly the information on our sites that a new user would want to see.
  • Local content. We can use calculated fields to create a field that combines users’ regions with their departments to direct them to relevant workshops or training opportunities in their area.
Modern audience targeting

In addition to accessing the original audience targeting features, SharePoint sites can now access a powerful, new suite of modern audience targeting features. This extended access enables users to further fine-tune the audience without help from a developer. They can use existing email lists, building-occupant lists, regional employee lists, or even product domain lists. This added functionality enables site creators to show the right content to the right group at all times.


The modern SharePoint site enlists comprehensive aggregation for search. When connecting sites together and implementing hub sites, search for hub sites aggregates to the parent site—this provides an aggregation of content that can be organized to best fit our needs.

Learning from our migration

Enabling modern SharePoint as the default platform within our Office 365 tenants for new sites was a straightforward process, but more consideration needed to be given to existing sites that weren’t using the modern design. Migration of these sites was examined on a site-by-site basis. Our tenancies contain thousands of site collections, and we needed to determine which sites were good candidates for immediate migration and which ones required more preparation before migration was an option.

Our migration approach

In planning for our migration, the user experience took precedence. We wanted our migration tasks to provide the environment that would best facilitate the best collaborative experience for our users and interfere as little as possible with that experience. The first part of the migration was establishing the best candidates for migration and how we would facilitate migration.

Using the SharePoint Framework in migration

The SharePoint Framework foundation was critical in allowing us to provide a firm cutover point for using the modern interface and communication sites as the defaults for our sites. Because SPFx is backward-compatible, web parts created using SPFx could be used in sites that aren’t built on the site design or converted to the modern user interface. We didn’t need to lose any creation time keeping legacy sites current before migration. When we needed a new web part in a legacy site, we simply used SPFx and brought over the web part when the migration occurred. Because of this, we were able to establish SPFx web parts as the default before we migrated a single site and many of the web parts that required changes were moved to SPFx while still in their legacy state. This greatly simplified migration of the site as a whole.

Migrating complex sites

For some of our larger and more complex sites, we had to consider and adopt a refactoring of the site and site collection as part of the migration. Refactoring allowed us to take a look at each site and how sites were connected and related before migration. If we wanted those relationships or connections to change, we built that process into the migration, so our migrated sites and hub sites were properly organized after the migration completed. For example, when we migrated MSW, our internal company site, refactoring was built into the migration. The process included important tasks that should be carried out on all large or complex sites:

  • Determine which site collections and related components are essential to the site.
  • Build out larger subsites as hub sites to allow more autonomy and control.
  • Use the hub site model to aid migration. Leave older content in the previous site and build out new content as hub sites.
  • Link together hub sites to aggregate content and search. Branding and navigation can float down to child sites while searchable content floats up to parent sites.
  • Consider a loosely federated and aggregated design rather than a design that is more rigid and monolithic.

Creating components designed for reuse

When necessary, we create web parts to suit our needs in SharePoint. Custom web parts help us provide a directed and comprehensive user experience without sacrificing user experience or design elements. We always consider reusability when we create new web parts. If a web part can be used for other parts of the organization or fulfill a need in other sites, we want to design it in a way that enables it to be reused. We have many web parts that are built with a more general and broad approach in mind that are reused and potentially customized in different places throughout our SharePoint site landscape.

Benefits and looking forward

The greatest benefit for us has been reduced requirement for development and IT intervention. Our users can now create attractive, useful, accessible, and responsive sites using default tools and site creation processes. Our business groups are driving their own site creation and design, and they’re able to maintain more current and complete sites with less effort. We don’t have to enlist extra IT resources or incur additional development delays or extra costs, which saves us time and money.

We’re continuing to migrate our intranet publishing sites to SharePoint in Office 365. In the coming months, we’ll move closer to converting all our publishing sites to SharePoint—this will increase cost savings, save time, and provide our organization with attractive, useful, accessible, and responsive intranet sites.

For more information

Microsoft IT Showcase

A foundation for modern collaboration: Microsoft 365 bolsters teamwork

Microsoft 365: A foundation for modern collaboration

SharePoint and Office 365: Securely sharing, managing, governing, and protecting content at Microsoft

Deploying Microsoft Teams streamlines collaboration and improves teamwork

Microsoft Teams increases collaboration in the modern workplace at Microsoft


© 2019 Microsoft Corporation. This document is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS OR IMPLIED, IN THIS SUMMARY. The names of actual companies and products mentioned herein may be the trademarks of their respective owners.

You might also be interested in

Implementing a Zero Trust security model at Microsoft
August 06, 2019

Implementing a Zero Trust security model at Microsoft

Read Article
Microsoft Teams era takes flight inside Microsoft
July 18, 2019

Microsoft Teams era takes flight inside Microsoft

Read blog
Upgrading to Microsoft Teams from Skype for Business at Microsoft
July 11, 2019

Upgrading to Microsoft Teams from Skype for Business at Microsoft

Read case study
Microsoft Teams adoption strategy prepares employees for a new culture of work
July 11, 2019

Microsoft Teams adoption strategy prepares employees for a new culture of work

Read case study