Modernize a Classic SharePoint Site Safely: Governance Checklist

Modernizing a classic SharePoint site to a modern communication or team site can break features, permissions, and workflows if done without a plan. Classic sites rely on custom master pages, web parts, and site definitions that modern sites do not support. This article provides a governance checklist that covers pre-migration auditing, stakeholder communication, content validation, and rollback procedures. Following this checklist helps you avoid data loss, broken links, and user disruption during the transition.

Why Classic Sites Require a Governance Checklist for Modernization

Classic SharePoint sites were built on a publishing infrastructure that supports custom master pages, HTML-based page layouts, and sandbox solutions. Modern sites use a flat architecture, a modern page model, and a limited set of web parts. When you connect a classic site to a Microsoft 365 group or switch its template to a modern team site, several components may stop working:

Custom master pages and alternate CSS files are ignored. Web parts that rely on server-side code, such as the Content Query Web Part or the Summary Links Web Part, are replaced or removed. Subsites lose their inherited navigation. Custom permission levels that were set at the subsite level may not transfer cleanly. A governance checklist forces you to document these dependencies before making changes, which reduces the chance of a failed migration.

What Happens When You Connect a Classic Site to a Microsoft 365 Group

Connecting a classic team site to a Microsoft 365 group changes the site’s owner, membership, and storage model. The site becomes group-connected, which means permissions are managed through the group rather than through SharePoint groups. Classic sites that had unique permissions on lists or libraries may lose those permissions after the connection. The governance checklist must include a full permission audit before the group connection is made.

Governance Checklist: Pre-Migration Audit and Preparation

Before you modify any classic site, complete these audit steps. Use SharePoint Admin Center, PnP PowerShell, or third-party tools to gather the data.

1. Inventory all classic sites and subsites
   Run a SharePoint Admin Center report to list all site collections that use the classic team site template (STS#0) or classic publishing template (BLANKINTERNET#0). Record the URL, template ID, storage used, and last modified date for each site.
2. Document custom master pages and page layouts
   Check the Master Page Gallery for any custom .master files. If the site uses a custom master page, note its URL and whether it is set as the site master page or system master page. Modern sites do not support custom master pages.
3. Audit web parts on all pages
   Export the list of web parts from each classic page using PnP PowerShell Get-PnPClientSideWebPart. Identify web parts that are not available in modern pages, such as Content Query Web Part, Summary Links Web Part, and Silverlight Web Part.
4. Check custom scripts and sandbox solutions
   Review the site assets library for JavaScript files and user custom actions. Sandbox solutions must be converted to SharePoint Framework extensions before the site can be modernized.
5. Map all custom permission levels
   Export the site permission report from Site Settings > Site Permissions > Check Permissions. Note any permission levels that were created manually rather than inherited from the parent site.

Migration Execution: Applying the Modern Template Safely

After the audit is complete and all dependencies are documented, you can proceed with the modernization. Use the built-in SharePoint experience toggle or PnP PowerShell to switch the site to a modern template.

1. Create a full site collection backup
   In SharePoint Admin Center, select the site, then click Backup. Alternatively, use the Export-SPOSite PowerShell command to create a .cmp file. Store the backup in a secure location that is not on the site itself.
2. Notify all site users and owners
   Send an email at least one week before the migration. Include the date, expected downtime (usually 2 to 4 hours), and a link to a read-only copy of the site if needed.
3. Remove custom master pages and page layouts
   Reset the site master page to the default Seattle.master or Oslo.master. Delete any custom page layout files that are no longer needed. Modern sites use the modern page model and ignore these files.
4. Replace unsupported web parts
   For each unsupported web part, create a modern equivalent. For example, replace the Content Query Web Part with the Highlighted Content web part. Replace the Summary Links Web Part with the Quick Links web part.
5. Convert sandbox solutions to SPFx
   If the site uses sandbox solutions, extract the code and package it as a SharePoint Framework extension. Deploy the SPFx package to the App Catalog before switching the site template.
6. Enable the modern experience
   Go to Site Settings > Site Information > Site Features. Deactivate the SharePoint Server Publishing Infrastructure feature if it is active. Then, in Site Settings, click Change the look and select a modern template. If the site is a team site, connect it to a Microsoft 365 group by clicking Settings > Site Information > Connect to a new Microsoft 365 group.
7. Validate all lists, libraries, and pages
   After the template switch, open each list and library to confirm that columns, views, and permissions are intact. Open the top 10 most visited pages to verify that web parts render correctly.

Common Issues After Modernizing a Classic Site

Broken Navigation After Template Switch

Classic sites often use structural navigation that shows subsites in the top navigation bar. Modern sites use hub navigation or a flat left navigation. After the switch, subsite links disappear. To fix this, create a hub site and associate the modern site with the hub. Then, add the hub navigation to the modern site’s left navigation using the Edit Navigation option in Site Settings.

Missing Content from Publishing Pages

Publishing pages that use custom page layouts may not render at all after the switch. The content is stored in the Pages library but the page model is no longer supported. To recover the content, open each publishing page in edit mode, copy the content, and paste it into a new modern page. Delete the old publishing page after the content is migrated.

Permission Errors on Group-Connected Sites

When a classic site is connected to a Microsoft 365 group, the group becomes the primary owner. Users who had direct access through the classic site’s Members group may lose access if the group does not include them. Run a permission comparison report before and after the group connection. Add any missing users to the group manually.

Item	Classic Site (Before)	Modern Site (After)
Master pages	Custom .master files supported	Not supported; uses default modern theme
Page layouts	Custom .aspx layouts allowed	Modern page model only
Navigation	Structural or managed navigation with subsites	Hub navigation or left navigation
Web parts	Content Query, Summary Links, Silverlight	Highlighted Content, Quick Links, no Silverlight
Permissions	Unique permissions per subsite or list	Group-based permissions; unique lists may lose settings
Custom code	Sandbox solutions, user custom actions	SharePoint Framework extensions

After completing the governance checklist and migration steps, you can verify that the modern site functions as expected. Run a full content audit using the SharePoint Admin Center Content Explorer to confirm that all files, versions, and metadata are present. If any issue appears, restore the site from the backup you created earlier and reapply the checklist steps. For future modernization projects, use the SharePoint Modernization Scanner tool to automate the dependency mapping process.