How we did it: upgrading +1700 classic SharePoint sites to modern Office Groups

This article is translated in English. The original article in Dutch can be found here.

It is a struggle that many Office 365 administrators have to deal with: what do we do with all those classic SharePoint sites? For years we have thought that we optimally used SharePoint with sub sites, custom permission models and all sorts of linked elements.

There are not many classic SharePoint sites that have remained 100% using default configurations. Many are ‘enriched’ with embedded javascript code or image maps. Also, homepages have been modified to ensure that the branding of a site matches the house style as much as possible.

a classic SharePoint site

But then Microsoft introduced a switch to so-called ‘modern sites’, connected to Office Groups, so that the management, policy and lifecycle on sites (groups) would be improved. This did not happen immediately; for a while there has been a transition where modern sites have been of limited use due to lack of functionality, support for certain list types and, for example, document sets. However, modern sites have now developed so well that the step can be taken, with some consideration.

It’s possible for some time now to ‘groupify’ and modernize a site collection. In fact, it means that a modern homepage is created and the lists are converted to the modern layout. An Office Group is also created which is connected to the site.

But it’s not that simple: many things cannot be transferred 1-to-1, with a result that choices have to be made here, which mainly have an impact on end users:

  • The permission model is changing. When dealing with an Office Group it is wise to align with the model of Members and Owners.
  • Custom homepages can continue to exist, but the default will be a new, modern homepage.
  • You can start using Office Group functionality with the site such as Teams, Planner, etc.
  • Not all old functionality is (already) available. Think of modern documentsets (coming soon), calendar lists and, for example, content editor webparts.
  • Subsites are questionable in the modern SharePoint world. It is recommended to use a so-called ‘flat information architecture’.

In short: a challenge! Its nevertheless wise to continue the transition, since we want to take advantage of the developments that Microsoft is doing and not to get stuck in old ‘stuff’.

modern SharePoint site

We went through this process for one of my clients, but not without a struggle. I would therefore like to share the experiences and approach with you. Use it to your advantage!

The fear for end-users

The ideas (and discussions) for modernizing around 5,000 SharePoint sites (with 6,200 users, excluding many external users) date back to a year or two ago. At the time it was still difficult because of the many limitations and bugs in the modern lists. That is why we waited until a year ago with this transition. With the ability to ‘groupify’ (connecting an Office Group to a SharePoint site) we started looking seriously at the options.

With this, there are some technical challenges, but the biggest obstacle was the (fear for) end users. For them, the site changes, sometimes to a large extent. How would this fall and how much support would be requested after a site has been converted. Much of this ‘fear’ comes from the idea that users find it difficult to change. The process in which they work is going to change. And thus the continuity of the organization can be affected.

And yes, this is something that needs to be taken into account. However, this same user is the first to buy a new iPhone, exchange the newspaper for a tablet, drive electrically and switch over to Microsoft Teams without any problems! Why? Because it’s easier, because it’s faster,
because it’s good for the environment or just because it’s cool. In short, users want to change, as long as it provides benefits!

And it is precisely this that can be optimally utilized when modernizing a SharePoint site. Because let’s be honest, who still wants to work in such an old-fashioned, slow and hard-to-use classic site? Exactly, except for a small percentage, NO ONE!

Design choices

When converting classic sites, we had to make a number of design choices. These choices are not always fun, sometimes concessions have to be made and end users are sometimes limited in their current way of working. However, so the idea is, with modern sites you get so much new functionality that this should outweigh the missing of old functionality. Consider, for example, the deployment of Microsoft Teams or tools such as Flow and Planner.

Our old sites were set up globally as follows:

  • Site collections with possible subsites. Think of phases in a project or process steps.
  • Custom permission models, where there are key users (owners with limited permissions) and members (contribution permission in SharePoint).
  • The homepage is often adapted with content editor web parts (read: javascripts and css) and images with image maps.
  • Extensive use of document sets for file creation, folders were first prohibited, later allowed to use.
  • Many content types with metadata, where attempts have been made to provide a generic set of metadata to all documents (owner, labels, status, type of document, etc.).
  • ‘Open information policy’, where non-confidential sites are open to all employees.
  • Confidentiality is expressed in permissions on the site.

In collaboration with security and CIO, we wanted to position the modern Office Group sites differently. For example, access is set up based on the classification of the site (in Dutch). Settings such as external sharing and retention labels (in Dutch) are set up based on this classification. A clear shift of responsibility (in Dutch) has taken place; for example, the key users become ‘owners’ of the site and members receive editing rights instead of contributions. This way lists and views can also be adjusted.

In recent years we have received a lot of feedback on the old SharePoint implementation. For example, speed is an issue, the fact that metadata is difficult (especially if it is mandatory) and the findability is poor. The adoption of SharePoint has long been an issue, with the result that a lot of ‘shadow IT’ has been created. Modern sites must offer a solution to these problems.

We decided to redesign modern sites. In essence, the user can determine how the site is set up and we remain very close to the standard when it comes to permissions and functionality. New, modern sites are therefore set up as follows:

  • Flat architecture, no more breaches of rights within a site collection. Do you need other rights? Then a new site collection. Subsites are not prohibited but strongly discouraged.
  • Key users become owners. Members with ‘contribution’ rights receive ‘edit’ rights. So more responsibility to users and the team in which they work together!
  • Everything becomes modern, so also a new (empty) homepage. Users can decide for themselves how this will look like. A conscious decision was made not to transfer the ‘old’ web parts to the modern homepage. The biggest reason is that the layout and working of modern web parts differs from the old ones to such an extent that it simply cannot be done properly. In addition, the users have such different layout and layout options that it is worthwhile (possibly together with support) to redesign.
  • Existing subsites continue to exist, we take this effect for granted.
  • ALL sites must be classified according to the organization’s information classification.
  • Policy is going to be enforced on the sites (so no more exceptions). Think of external sharing, conditional access, etc.
  • Labels are used for retention and archiving.
  • All sites may link / create a Microsoft Team if desired, and use Planner. This way Office Groups are optimally used.

The plan

Of course, a plan is needed to modernize all team sites, project sites, meeting sites. We initially made a distinction between three types of solutions:

  • The default collaboration sites. These include the goal of collaborating in groups where access is determined based on the classification of the information contained in the site.
  • Publishing sites. These are SharePoint sites that are used to share (or publish) information and documents with others (often the entire organization). Think of the traditional document centers or publication portals. We have chosen not to link these types of sites to an Office Group. These sites are, however, modernized in separate processes to. For example, communication and / or hub sites.
  • Solutions for specific target groups. These are collaboration sites that are specifically designed for a target group or process. New releases of these templates (including modernization) are included in the LCM of these specific solutions.

This article is about the modernization of the first group, in this case about 1800 in total. In this process, an approach was chosen with key users who would like to participate in a ‘first release’, and users who do not want this, or who no longer actively use the site. This first release also serves as a pilot for the large bulk promotion.

We have also chosen to start the modernization announcements in an early stage, and to repeat them several times. The nature of this announcement is compelling: you MUST upgrade, whereby you can choose not to go along with the first release immediately.

Talking about the ‘MUST’: we really want to have all collaboration sites upgraded, because this offers great benefits in management with Office Groups and AAD. The policy also states that in terms of security, retention and LCM we want to join in with the possibilities that modern sites and Office Groups offer. In addition, as Office 365 admins, we also want to keep up with developments Microsoft is doing and to maintain as little legacy as possible.

Summarized, the plan is as follows:

STEP 1: Communication to all key users of a collaboration site with the announcement and the option to sign up for the first release. This is done via an e-mail which clearly explains what will happen and what consequences it will have for users.

STEP 2: Second communication moment for the first release. This e-mail is a second announcement and more detailed planning of the transition.

STEP 3: Create & test scripts for modernizing and groupifying a site collection. These scripts are discussed later in this article. The goal is to have a PowerShell script that completely takes care of modernizing the site and links the site to a new Office Group.

STEP 4: Convert first release. The first batch with first release sites are converted, about 80 in total. This concerns enthusiastic users, so that the ‘cooperation’ should be optimal.

STEP 5: Request and process feedback. After the first batch, it turned out that 79 of the 80 sites were transferred correctly. There appeared to be a problem with creating an Office Group at the one site that had failed and where the problem is not clear. It was therefore decided to park this site for a while and to pick it up later. There also appeared to be a caching problem with the use of Internet Explorer 11 after a site had become modern. Various elements were not shown. Emptying the browser cache solves the problem. However, since IE 11 is the standard browser for a few months, this is an issue that can bother many users.

STEP 6: Lessons learned, evaluation and processing results. The PowerShell script worked well, but was made more efficient. We have also written articles about the most common problems (IE cache, user questions, etc.), so that they could be addressed immediately. We have also instructed the first line service desk to be able to handle these questions. It has also been found that by far the majority of users from the first release were particularly happy with their new, modern site! In short, perhaps the fear of users’ reactions is not entirely justified.

STEP 7: Communication moment for other key users. It was decided to transfer the remaining 1700 sites in one go. This would allow us to complete the upgrade quickly, possibly provide a lot of support for a short time and prevent the process from taking (even) longer. The idea is therefore to transfer the rest in a weekend and to be fully standby the following week. This has been communicated to the other key users via e-mail.

STEP 8: Write and publish help articles. To make the process, impact and problems quickly and clearly accessible to users, articles have been written and published on a SharePoint help site. This makes it possible to quickly and easily refer to online background information in communication.

STEP 9: Inform and involve the service desk (1st line). Because possible users contact the help desk when using the modern sites, the first-line service desk is informed and involved in the process.

STEP 10: Announcements via Yammer and SharePoint. The week before the sites were modernized, it was announced again via the Yammer network and SharePoint.

STEP 11: Convert the other sites. The more than 1700 classic team sites were subsequently modernized on Friday evening and connected to an Office Group. In this process, members and owners of a site receive a standard email from Office 365, in which they are introduced to the new Office Group. The effect of this is that some users receive multiple emails. This is sometimes experienced as negative, but it also provides insight into which (old) sites a user is a member of. A trigger to clean up or archive a site!

STEP 12: Plan a week for support. The week after the modernization, a week is scheduled for resolving calls that cannot be handled by the service desk. The expectation was that we would be flooded with questions. However, the first few days this happened to a limited extent, to a few dozen. Much less than expected.


The technical conversion of a site is one thing, but communication is everything! Although users are not waiting to be overloaded with emails and messages, it is wise to announce clearly and repeatedly what awaits them.

In the time to the moment of conversion, we had several communication moments. We expect that different key users have not read the e-mails, or that they have missed the communication. It is therefore important to do this at multiple times.

In addition, we have chosen to use multiple channels: e-mail, SharePoint and Yammer to reach as large a group of users as possible. Provide clear explanations and supporting articles, so that the most frequently asked questions are answered.

The key in this communication is: be positive about what’s coming. The user gets so much more convenience and tools to support their process. Use this! Every new feature in SharePoint can be brought as a moment of success and contact with the end user. Again, make good use of this!


In addition to the process of modernization, it is also good to look at the technology. The approach we have taken is to ensure that a site can be fully and quickly converted, including connecting an Office Group.

The mechanism for doing this (in this case) consists of 5 steps:

STEP 1: Create a .csv with all sites that need to be converted. In our case, the classification of a site is also included here.

csv with sites (template)

STEP 2: Put the users in the right permission group. In our case, owners and members were set to adjusted permission levels. When a site is connected to an Office Group, the default SharePoint groups for Owners and Members are linked to the Office Group permissions for owners and members. So it was necessary to put the users in the right, default groups and to clean up the old permission levels.

STEP 3: Configure the library settings for using modern layout. In the past we have converted all lists in every classic site to use the classic layout. This is because the user would otherwise be confronted with a mixed way of modern and classic. We have therefore converted all lists, so that the settings at the tenant level are used.

classic view or modern view

STEP 4: Groupify! The script to connect the sites to an Office Group

STEP 5: With the modernization a new modern homepage is created. We have placed a modified introduction text on this to inform the user.

All supporting scripts (steps) and .csv template can be found below (with thanks / credits to Kimberly Pothuizen and Albert-Jan Spiegelenberg).

By splitting the sites into 5 batches and starting them simultaneously, we succeeded in completing the modernization in 8 hours! It should be noted that of the more than 1700 sites, around 15 were not immediately successfully completed.


We are now one week after the upgrade process, with no significant events. Some users have reported that the site was still in the process of setting up the Office Group, but in general the conversion went very well.

The process prior to modernization took quite a long time, mainly due to the impact on users. In retrospect, this appears to have been partly unnecessary. As a result, communication and awareness have been implemented over a longer period of time. The final modernization of the 1700 sites took about 8 hours, all preparations (articles, extra communication, improving scripts and inventory sites) in around 8 days.

My advice in this: take a pragmatic approach and do not limit yourself too much with requirements you cannot meet (transfer content, migrate web parts, etc.). In addition, it is wise to match the permission model to the permissions within Office Groups. In addition, indicate to the user that they play a role in the process and are ultimately responsible for the content of the site. Make it fun! Users are generally enthusiastic about the new possibilities, make full use of it!

Geef een reactie

Vul je gegevens in of klik op een icoon om in te loggen. logo

Je reageert onder je account. Log uit /  Bijwerken )


Je reageert onder je Twitter account. Log uit /  Bijwerken )

Facebook foto

Je reageert onder je Facebook account. Log uit /  Bijwerken )

Verbinden met %s