Classic SharePoint pages go read-only in October 2028. What it means and how to prepare

In our September overview it was a single row in the deadline table: 1 October 2028 — classic SharePoint pages become read-only. It looks distant and harmless. But classic pages are not a fringe topic. You find them in intranets built before 2017, in team sites created from the old template, in wikis holding company procedures, in sites migrated from SharePoint Server and in pages someone once “improved” in SharePoint Designer. Microsoft says in its announcement that fewer than 5% of active tenants still use classic features — but in organisations that have run SharePoint for fifteen years, they are the rule rather than the exception.

This article sums up what exactly Microsoft announced (MC1464926, 31 August 2026), who is affected and how to prepare so the deadline doesn’t turn into a problem.

What changes, in two phases

Phase 1 — from 1 March 2027

For all tenants:

• You can no longer create classic publishing sites — neither as site collections nor as subsites.
• You can no longer activate the publishing feature on existing sites.
• The tenant setting AllowClassicPublishingSiteCreation is forced off.

Additionally, for tenants created on or after 1 March 2027:

• New classic pages can’t be created.
• Custom scripts are disabled and can’t be enabled (DenyAddAndCustomizePages is enforced).

Phase 2 — from 1 October 2028

The same extends to all remaining tenants:

• Classic user-created pages become read-only. They can be opened and read, but not edited. New classic pages can’t be created.
• Custom scripts are disabled in every tenant, and you can no longer set an exception, not even temporarily.

Important: content is neither deleted nor modified. The pages remain available for reading. They just freeze — and with them everything that has been maintained by hand on them so far.

Which pages are affected

Microsoft lists five types of “classic user-created pages”:

Type	Where you typically find it
Wiki pages	home pages of old team sites, company wikis with procedures and how-tos
Web Part pages	department dashboards, overviews built from list web parts
Blog pages	blog subsites once created for team news
Publishing pages	classic intranets with page layouts, Enterprise Wiki
Custom ASPX pages	pages created in SharePoint Designer or by a third-party solution

What does not change:

• Modern pages and most SharePoint Framework (SPFx) solutions keep working. The exception is SPFx web parts with requiresCustomScript: true — when scripts are blocked, they disappear from the picker and from pages.
• Classic list and library views and list forms are not in scope for now. Microsoft explicitly says they “might be addressed on a separate timeline”, though. And scripts embedded in them are still subject to the custom script restrictions.
• Classic sites themselves remain. Many of them can be modernised in place, without rebuilding from scratch.

From March 2027 you can no longer create a site from these templates: Publishing Portal (BLANKINTERNETCONTAINER#0), Publishing Site (CMSPUBLISHING#0), Publishing Site Blank (BLANKINTERNET#0), Enterprise Wiki (ENTERWIKI#0), Enterprise Search Center (SRCHCEN#0), Site Directory (SPSSITES#0), News Home (SPSNHOME#0), Product Catalog (PRODUCTCATALOG#0), Report Center (SPSREPORTCENTER#0) and Topic Area (SPSTOPIC#0). Other classic templates are not affected.

Why this is bigger than it looks

For living content, “read-only” means “the end”. A wiki with a procedure that gets updated once a quarter, or a department page with contacts, simply stops being maintained after 1 October 2028. Nobody gets an error message; the content just starts ageing quietly. On an intranet that is worse than an outage, because nobody notices.

The home page is often classic where nobody expects it. Team sites created from the old template typically have a wiki page as their home page (Microsoft may already have converted uncustomised home pages to modern ones, but customised ones stayed classic). The site may look modern in its libraries and lists while its front page falls under the change.

Custom scripts end for good. Already today, allowing custom scripts on a site reverts to “not allowed” within 24 hours. From October 2028, even that temporary allowance goes away. Microsoft says existing scripts won’t stop working, but you can’t add or edit them. If your pages use the Script Editor or Content Editor with JavaScript, you won’t be able to fix them when something breaks.

Migrating from SharePoint Server gets harder. From March 2027 you can’t move a classic publishing site “as is”, because such a site can no longer be created in SharePoint Online. Classic pages can still be migrated, but after the deadline they are read-only and script-based elements may not be preserved. Microsoft recommends building modernisation into the migration itself. Migration tool vendors point this out too — ShareGate, for example, says it cannot work around this restriction.

How to find out whether it affects you

Microsoft offers three sources of information and one reassurance: if your inventory finds no classic publishing sites, no classic pages and no affected scripts, you don’t need to do anything.

1. Audit in Microsoft Purview. The SharePoint Classic Activities category and the ClassicPageCreated, ClassicPageEdited and ClassicPageViewed events show which classic pages people actually create, edit and read.
2. Microsoft 365 Assessment Tool. Microsoft’s open-source (PnP) tool that scans SharePoint Online and lists classic pages, their web parts and an estimate of how well they will convert. Classic page analysis is in version 1.15 and later, the link to audit data (up to 180 days back) from version 1.16. For a full-tenant scan it needs a registered app with read-only permissions.
3. Sites with custom scripts. In the SharePoint admin center, Active sites has a Custom script column and a ready-made Custom script allowed sites view.

The combination of inventory and audit is what matters. A list of ten thousand classic pages solves nothing on its own. A list that says two hundred of them are edited and a thousand are read is already a plan.

How to approach it

Not everything needs to be converted. A page nobody has opened for two years doesn’t need modernising. It can stay read-only as an archive, or be deleted. Only what must remain editable is worth converting. For each group of pages, choose one of three paths: modernise, keep as an archive, remove.

Start with what is alive and important. Microsoft recommends ranking pages by business importance and by how often they are edited. Then group them by complexity so you can convert in waves and reuse what you learn in the first wave.

The tools exist, but they have limits:

• Page transformation with PnP PowerShell is the deterministic conversion that Microsoft describes as the primary path. Its core workflow, however, covers wiki pages and web part pages in the Site Pages library. Publishing pages, blogs, pages outside Site Pages, home pages and SharePoint Server sources require separate, more advanced procedures. The engine is part of the open-source PnP Framework library and has no Microsoft support SLA.
• SharePoint Page Modernization Agent is a new open-source AI agent that helps with more complex pages — custom HTML, Script Editor content or layouts that need human judgement. It is in preview and not supported by Microsoft, runs in tools such as GitHub Copilot or Claude Code and consumes language model tokens. Its authors themselves recommend comparing every generated page with the original. Script Editor content may end up only as explanatory text, not as a working replacement.

Microsoft adds a sentence worth taking seriously: highly customised pages can require redesign or manual rebuilding. And a generated page can exist and still be blank or incomplete, so “it opened without an error” is not enough of a check.

Split the work between IT and site owners. Plan centrally, set the order and prepare the tools. But the content after conversion is best checked by whoever uses it — the site owner or the department. A wave-based approach lets you validate content, links, permissions, web parts and layout before you move on to the next few hundred pages.

A timeline that makes sense

Just under two years remain until October 2028. That sounds like plenty, but for an intranet with thousands of pages, where every wave has to be checked by people from the business, it is about right. A realistic plan:

When	What
by the end of 2026	inventory: Assessment Tool + audit, list of sites with custom scripts
by 1 March 2027	decide on classic publishing sites; from this date no new ones can be created, and migration from SharePoint Server needs to go hand in hand with modernisation
2027	first waves: the most important and most frequently edited pages, replacing scripts with modern web parts or SPFx
H1 2028	the rest of the edited pages; archive or remove unused ones
1 October 2028	classic pages are read-only — by now nothing that needs changing should be left there

Key takeaways

1. The content doesn’t disappear, it freezes. From 1 October 2028 no classic wiki, web part page, blog, publishing page or custom ASPX page can be edited.
2. Publishing sites end earlier. Creating them and activating publishing stops on 1 March 2027 — which mainly affects migrations from SharePoint Server.
3. Find out where your classic content is. The Assessment Tool and the Purview audit together give you both the list and what is actually used. If they find nothing, you don’t need to do anything.
4. Convert only what must stay alive. Archive or delete the rest. Tools help, but not without human review.

---

We modernise classic sites and intranets as part of an environment review and a governance design — from inventory and deciding what to convert and what to archive, to modern replacements for script-based pages. If your SharePoint dates from before modern pages, or you are planning a migration from SharePoint Server, get in touch.

Sources: Microsoft Message Center MC1464926 (31 Aug 2026), Microsoft Learn — Deprecation of Classic SharePoint Pages, Transform classic SharePoint pages to modern pages, Allow or prevent custom scripts, Microsoft 365 Assessment Tool, SharePoint Page Modernization Agent.