SharePoint Classic Pages and Custom Script: What Ends, and When?

When a message-center notice or a forwarded note says Microsoft is turning off classic SharePoint, the first two questions in the room are what in the tenant is classic and which date is ours. This guide reads Microsoft Learn as served on September 24, 2026, sorts the change by the tenant it binds, and turns Microsoft’s own assessment steps into an inventory and a first modernization wave you can fund against the right date. Microsoft’s main page on the change, Upcoming changes to classic publishing sites, classic pages, and custom scripting in SharePoint Online, was last updated August 28, 2026.

The planning rule for an existing tenant follows from that table: its publishing-site deadline is March 1, 2027, and its page and custom script deadline is October 1, 2028. A summary that says custom scripts are switched off for everyone on March 1, 2027 is not what Microsoft’s page says; that date carries the script change only for tenants created on or after it.

When the inventory starts, the first dispute is usually over which pages count, so settle it from Microsoft’s list rather than from the look of a page. Microsoft’s page says the read-only change applies to these classic user-created page types:

• Wiki pages
• Web Part pages
• Blog pages
• Publishing pages
• Custom ASPX pages created by using SharePoint Designer or third-party solutions

It then says “Other classic experiences, including list and library views and list form pages, aren’t in the current scope. However, custom scripts embedded in those experiences are subject to the changes to custom script creation and updates.” For publishing sites, its FAQ says that beginning March 1, 2027 you can’t create site collections or subsites from the publishing-related templates it lists: Publishing Portal Site, Publishing Site, Publishing Site Blank, Enterprise Wiki, Enterprise Search Center, Site Directory, News Home Site, Product Catalog, Report Center and Topic Area Template. The same answer says “Other classic templates aren’t affected by this change.”

Nothing is deleted on either date. Microsoft Learn says “These changes don’t delete or modify existing classic page content.” The governance and information-architecture decision that sits above page modernization, including whether to modernize in place or with a migration, is covered in Governance-First SharePoint Modernization for Regulated Enterprises; this guide stays with the dated change.

If script-enabled sites have been treated as a design convenience, read what Microsoft says a site owner can do with them. Microsoft’s Allow or prevent custom script page says “If you allow custom script, all users who have Add and Customize Pages permission to a site or page can add any script they want.” Its Security considerations of allowing custom script page says “When you allow users to run custom script, you can no longer enforce governance, scope the capabilities of inserted code, block specific parts of code, or block all custom code that has been deployed.” It adds that if you’ve allowed custom script and later change the setting, “you can’t block the execution of script that has already been inserted.”

Today, allowing script is already temporary. Microsoft’s Allow or prevent custom script page says “Changes to allow custom scripts are overridden to Not allowed within 24 hours.” It also describes what breaks when script is blocked: for SharePoint Framework web parts that have the requiresCustomScript value set to true, “Every instance of a web part that was added to a page when custom scripts were previously allowed no longer surfaces in those pages.”, and its table of affected features lists, for publishing sites, “Can’t create or edit master pages and page layouts”.

Microsoft’s direction is stated plainly on the security page: “Instead of allowing custom script, we recommend using the SharePoint Framework.” A tenant that wants the block before the dates can use the setting Microsoft’s Baseline security mode settings page describes: “This setting permanently removes the ability to add new custom scripts in OneDrive and SharePoint sites.”

If a rebuild is funded before anyone has counted, the estimate is a guess, and Microsoft’s own advice is to measure first: “Start assessing your environment and planning modernization now.” Microsoft’s deprecation page names two instruments. It says “Use the Microsoft Purview Audit SharePoint Classic Activities category and the ClassicPageCreated, ClassicPageEdited, and ClassicPageViewed events to understand current usage.” and “Run the Microsoft 365 Assessment Tool to identify classic pages, Web Parts, customization patterns, and modernization feasibility.”

Two conditions on the assessment matter before it is run. Microsoft’s Requirements for the classic pages assessment page says “The classic pages component assesses SharePoint Online. It doesn’t assess SharePoint Server or another on-premises source.” The same page tells you to configure the tool’s settings for tenants in GCC High and DoD, among other environments it lists.

For custom script, the SharePoint admin center already holds a list. Microsoft’s custom script page says “The Custom script allowed sites view is also available to provide easy access to all sites where custom script is enabled” and warns “These views show which sites are configured to allow custom scripts, even if they don’t actually use custom scripts.” A site on that list is a site to check, not a confirmed dependency.

Turn the results into a register before any estimate:

• Pull Purview Audit usage first, so edit frequency and views are known before scope is set.
• Tag every classic page and site with the date that binds it, how often it is edited, and a named owner.
• Count publishing portals separately, because Microsoft recommends starting a modernized publishing portal from a new communication site.
• Mark every site that allows custom script, and note which pages on it carry script-based web parts.

If the register comes back empty, Microsoft’s page says “If your assessment finds no classic publishing sites, classic user-created pages, or affected custom scripts, no action is required for these changes.”

When the register is long, the failure mode is a program that converts everything at the same priority, and Microsoft’s advice points the other way. Its deprecation page says “Start with frequently edited, high-traffic, or business-critical pages.” and, in its FAQ, “Modernize pages that must remain editable after the applicable date.” Microsoft’s Modernize your classic SharePoint sites page says “we recommend that you transform only the pages that are frequently used.”

Decide per page class, in three ways:

• Transform: pages that must stay editable and fit Microsoft’s page transformation path.
• Rebuild: publishing portals and highly customized pages. For portals, Microsoft’s modernization page says “If you want to modernize your publishing portal it’s recommended to start from a new communication site and configure that one accordingly.” For the rest, Microsoft’s deprecation page says “Highly customized pages can require redesign or manual rebuilding.”
• Leave read-only: pages that are viewed but no longer edited, which Microsoft says stay available for viewing.

The transformation tooling carries conditions a regulated change process has to weigh. Microsoft’s Transform classic SharePoint pages to modern pages page says “Publishing pages, Blog pages, pages outside SitePages, home pages, and SharePoint Server sources require separate advanced procedures and aren’t accepted by the page wave scripts.” and “The page transformation engine is part of the open-source PnP Framework and doesn’t have a Microsoft support SLA.” Microsoft’s deprecation page points to PnP PowerShell for deterministic page transformation and to the open-source SharePoint Page Migration Agent (preview) for complex pages, and says in the same passage “Preview and community tools might not fully automate complex scenarios and don’t have a Microsoft support SLA.”

Plan to replace script-based customizations rather than re-allow them: Microsoft recommends the SharePoint Framework, and a publishing site with script blocked cannot create or edit master pages and page layouts, according to Microsoft’s custom script page. Validate each wave before the next one starts, the way Microsoft’s transformation page validates each generated page before a larger wave.

If your tenant sits in a government cloud, check Microsoft’s cloud line before assuming a separate clock. Microsoft’s deprecation page says “The changes to classic user-created pages apply across all Microsoft 365 environments, including:” and its list includes “Microsoft 365 Government (GCC, GCC High, and DoD)”. That sentence names the classic user-created page change; for the publishing-site and custom script changes in a government cloud, confirm the timing with Microsoft rather than infer it. The assessment itself is configured for GCC High and DoD tenants, according to Microsoft’s requirements page.

For a regulated tenant, the pages to inventory first are the ones that must stay editable after the date: policy libraries, regulated notices, controlled procedures and records-facing pages. Which of them your security, records and compliance owners require to remain editable is their determination; the inventory gives them the list to decide on.

If classic content still lives on SharePoint Server, Microsoft’s deprecation page says “Beginning March 1, 2027, classic publishing sites can’t be migrated as-is to a newly created classic publishing site in SharePoint Online because creation of those sites is disabled.” and “Script-based page elements and other customizations might not be preserved.”, and its assessment requirements page says the classic pages component doesn’t assess SharePoint Server. Leaving SharePoint Server is its own decision, covered in Our SharePoint Server Is Reaching End of Life: How Do We Migrate Off On-Premises to Microsoft 365?.

If the assessment finds nothing in scope, the work is smaller than this guide suggests, and Microsoft says no action is required for these changes. Other cases where a full program is the wrong answer:

• Pages nobody edits can be left to go read-only. Microsoft says affected pages “remain available for viewing”, so transforming every page is not always the right call, and Microsoft recommends transforming the frequently used ones.
• List and library views and list form pages are not in Microsoft’s current scope, so a program built to rebuild them for this change is mis-scoped; custom scripts embedded in them are still in.
• Preview and community tools have no Microsoft support SLA, according to Microsoft Learn; whether that is acceptable is a decision for your change process, not a detail for the project team.
• If the real question is a new intranet rather than the classic estate, that is a separate funding decision.
• If Microsoft changes the dates or the scope, parts of this guide change with it; re-read Microsoft’s page before each date.

When you bring in help for the inventory or the waves, hold every proposal to the same criteria:

• Ask for usage evidence from Purview Audit and an Assessment Tool run before any estimate.
• Require every page and site to carry its binding date and a transform, rebuild or leave-read-only decision.
• Expect publishing portals to be rebuilt on new communication sites, as Microsoft recommends, with any publishing page transformation run under Microsoft’s separate advanced procedures.
• Expect script-based customizations to be replaced on the SharePoint Framework, not re-allowed.
• Require a validated first wave before the rest of the plan is committed.
• For a GCC High or DoD tenant, confirm the assessment is configured for that cloud.
• Ask who does the work, where they are based, and which named deliverables they hand over.
• Get a plain statement that your team owns the tenant after the project.