Classic SharePoint Changes Are Coming: What Organisations Need to Do Before 2027

Posted on by

Microsoft is restricting the creation and editing of specific classic SharePoint Online experiences from March 2027. ,Affected user-created pages will become read-only from October 2028. Organisations need to identify critical dependencies before they become and urgent operational problem. 

TL;DR

  • Microsoft is not retiring SharePoint Online. It is retiring or restricting specific classic publishing, page and custom-script experiences.
  • From 1 March 2027, organisations will no longer be able to create new classic publishing sites or activate classic publishing features.
  • From 1 October 2028, affected classic user-created pages will become read-only across existing tenants.
  • Existing affected pages will remain available to view, but organisations will no longer be able to create or edit them.
  • The main risk is not losing content overnight. It is discovering too late that important communications, processes or customisations depend on technology that can no longer be maintained.
  • Start with an assessment of your sites, pages, custom scripts, workflows, integrations, ownership and business criticality before deciding what to modernise, rebuild, archive or retire.

Not just a SharePoint Update – A Business Continuity Issue  

Microsoft has been progressively retiring SharePoint Classic tehcnologies. We’re seeing this through the phased deprecation, restrictions, and retirement of the technology.  

Recently, Microsoft announced phased changes to specific classic publishing sites, user-created pages and custom scripting within SharePoint Online. These changes will limit the ability to create, edit and maintain affected experiences between March 2027 and October 2028. 

The immediate risk is not that an intranet will disappear overnight. Existing content will not be deleted. The risk is that an organisation discovers too late that an important classic page or customisation can no longer be updated.  

Your organisation may have a mix of classic and modern components, meaning some areas will be affected while others remain unchanged. The challenge is determining where those boundaries sit and which affected components support business-critical content or processes. Without that visibility, organisations may underestimate the scope of remediation until editing restrictions are close to taking effect. 

Resolving a classic dependency can require more than converting pages. Organisations may need to review content, permissions, workflows, integrations, information architecture and ownership.  

Like any planned retirement, the earlier the work begins, the more control you have over cost, sequencing and minimising disruption. 

Classic or Modern SharePoint: How to Tell What You Have 

“Classic” and “modern” describe different SharePoint experiences and technical approaches. They are not separate Microsoft 365 products, and an organisation may have both within the same SharePoint Online environment. 

Visual appearance can provide clues, but it is not a reliable assessment method on its own. A branded site can look current while still relying on classic publishing pages, custom scripts or older page layouts underneath. 

Area  Classic SharePoint  Modern SharePoint  How to check 
Sites  Often includes classic publishing portals, older team sites and sites built around subsites  Commonly includes communication sites and modern team sites  Check the site template and whether publishing features are activated 
Pages  Wiki pages, Web Part pages, blog pages, publishing pages and some custom ASPX pages  Modern site pages created through the current SharePoint page editor  Open a page in edit mode and review its page type and editing experience 
Page components  Classic Web Parts, page layouts, master pages or injected scripts  Modern Web Parts and supported SharePoint Framework extensions  Review the components used on business-critical pages 
Branding  May rely on master pages, custom CSS or JavaScript  Uses modern themes, headers, navigation and supported extensions  Determine whether branding depends on custom code or a master page 
Publishing  Often uses publishing sites, page layouts and approval processes built around classic publishing features  Uses modern pages, news and supported approval approaches  Review how authors create, approve and publish content 
Customisation  May use SharePoint Designer, script injection, custom ASPX pages or legacy add-ins  Uses supported Microsoft 365 services, modern APIs and SharePoint Framework where appropriate  Inventory scripts, add-ins, integrations and custom solutions 
User experience  Often designed primarily for desktop use and may differ across pages  Responsive and designed for current SharePoint and Microsoft 365 experiences  Test important journeys on desktop and mobile 
What the retirement means  Some creation, editing and scripting capabilities will be restricted under Microsoft’s phased rollout  Modern pages are not the target of this classic-page retirement  Confirm page types and dependencies rather than assuming the whole site is affected 

Do not rely only on how a site looks. The clearest way to understand your exposure is to run an assessment that identifies page types, classic publishing features, custom scripts, Web Parts and other dependencies. 

What Has Microsoft Announced? 

SharePoint Online is the cloud-based SharePoint service included in Microsoft 365. Within that service, organisations can still have older, or “classic”, sites, pages and customisations alongside modern SharePoint experiences. 

The announced changes apply to specific classic publishing, page-authoring and custom-script capabilities inside SharePoint Online. They do not mean that every SharePoint site will stop working or that all existing content will be deleted. 

This distinction matters because the required response depends on what an organisation is using. A modern communication site may require no action for this retirement. A classic publishing portal with custom page layouts, injected JavaScript, and business-critical publishing processes may require substantial assessment and redesign.

In scope under Microsoft’s current announcement 

  • New classic publishing site creation
  • Activation of classic publishing features
  • Creation and editing of affected classic user-created pages
  • Adding or updating custom scripts under the announced restrictions
  • Wiki pages
  • Web Part pages
  • Blog pages
  • Publishing pages
  • Custom ASPX pages created through SharePoint Designer or third-party solutions

Not currently part of the classic-page read-only scope 

  • Classic list and library views
  • List form pages

However, Microsoft notes that custom scripts embedded in those other experiences remain subject to the custom-script changes. 

The Retirement Timeline Explained 

Phase 1: From 1 March 2027 

What changes for all tenants 

  • New classic publishing sites can no longer be created. 
  • Classic publishing features can no longer be activated. 
  • The tenant setting that allows classic publishing site creation will be enforced as disabled. 

Additional changes for tenants created on or after 1 March 2027 

  • For tenants created on or after 1 March 2027, users can no longer create new classic user-created pages. 
  • Adding or updating custom scripts is disabled by default. 
  • The relevant site setting is enforced and cannot be changed. 

What organisations should do 

Stop creating new dependencies on classic publishing and custom scripting. Use the remaining period to establish which existing sites and processes are affected, assign owners and agree on priorities. 

Phase 2: From 1 October 2028 

What changes 

  • From 1 October 2028, the Phase 1 page and scripting restrictions begin extending to remaining existing tenants. 
  • Affected classic user-created pages become read-only. 
  • Users can no longer create or edit those classic pages. 
  • Existing affected pages remain available for viewing. 
  • Existing classic page content is not deleted as part of this change. 

What this means operationally 

Information may remain visible, but the organisation may no longer be able to correct, update or republish it through the affected classic page experience. For a business-critical policy, safety procedure, service page or employee portal, view-only access is not a sustainable operating model. 

How Is This Different from Other SharePoint Retirements? 

The classic SharePoint Online changes are only one of several SharePoint lifecycle events. They affect different technologies, environments and dependencies, so they should not be combined into a single “SharePoint retirement” project. 

The table below separates the main changes and shows why each requires a different response. 

Change  Environment or capability affected  Current position  What the organisation needs to determine 
SharePoint Server 2016 end of support  On-premises SharePoint Server 2016  Extended support ended on 14 July 2026  Whether the server environment requires migration, upgrade, isolation or replacement 
SharePoint Server 2019 end of support  On-premises SharePoint Server 2019  Extended support ended on 14 July 2026  Whether the server environment requires migration, upgrade or replacement 
SharePoint 2013 workflows  Legacy workflow technology  Separate retirement event  Which business processes still depend on these workflows 
SharePoint Add-Ins  Legacy extension model  Separate retirement event  Which solutions, integrations or custom functions depend on add-ins 
Classic SharePoint Online experiences  Specific publishing sites, classic pages and custom scripting within SharePoint Online  Phased changes from 1 March 2027 and 1 October 2028  Which sites, pages and customisations fall within Microsoft’s scope 

These events may overlap within the same organisation, but they are not the same change. Combining them without first mapping the affected environments can inflate project scope, obscure urgent risks and lead to unnecessary work. 

How to know whether your organisation is affected 

An older intranet is not automatically affected, and a newer-looking site is not automatically safe. What matters is the underlying site type, page type and technical dependency. 

Your organisation should investigate further if any of the following apply: 

  • You use classic publishing sites or publishing features.  
  • Important content is held on wiki, Web Part, blog, publishing or custom ASPX pages.  
  • Your environment uses SharePoint Designer.  
  • Page layouts or branding depend on master pages, custom CSS or injected JavaScript.  
  • Business processes rely on custom scripts, legacy add-ins, forms or workflows.  
  • Your intranet or portal has been heavily customised.  
  • Site, content or technical ownership is unclear.  
  • Nobody can provide a current inventory of sites, pages and customisations.  
  • The organisation has not reviewed its SharePoint architecture, permissions or content ownership for several years.  
  • A third-party intranet or custom solution was implemented without a clear upgrade or support path. 

If several of these indicators apply, the next step is not to start migrating content. It is to establish the size and criticality of the dependency. That assessment determines cost, sequencing and the amount of specialist support required. 

What Is at Risk If Classic Dependencies Are Left Unresolved? 

The main risk is not the age of the technology. It is the operational complexity attached to it. 

A single classic page may support a wider chain of content, permissions, scripts, approvals, forms or integrations. If that chain is not understood before editing restrictions take effect, the organisation may face rushed remediation, higher delivery costs and disruption to important services. 

Risk area  What may be happening now  Organisation consequence 
Content  Policies, procedures or employee information are duplicated, outdated or unowned  Employees lose confidence in the information they find, and content clean-up increases the effort required before migration 
Publishing  Communications rely on classic publishing pages, layouts or approvals  Authors may lose the ability to maintain important content through the existing process 
Business processes  Forms, approvals or departmental tools depend on scripts, workflows or page customisations  A page change can disrupt a process that appeared unrelated to the intranet 
Permissions and governance  Access is complex, undocumented or inherited from old structures  Reproducing the same model can carry existing security and compliance risks into the new environment 
Findability  Navigation, metadata and search reflect an old organisational structure  Employees spend more time searching and are more likely to use outdated information 
Cost and delivery  Dependencies are discovered late, after scope and budgets have been set  The project requires unplanned rework, specialist intervention or emergency remediation 
Internal capacity  Knowledge sits with one administrator, supplier or former employee  Decisions slow down and the organisation becomes dependent on scarce expertise 
Long-term supportability  Custom solutions have no clear owner, documentation or upgrade path  Maintenance costs increase and future Microsoft 365 changes become harder to absorb 

The required update is not just a page-moving exercise. It is a decision about what the organisation still needs, what should be redesigned and what should no longer be carried forward. 

A Practical Roadmap 

Step 1: Establish the Current State 

Build an inventory of affected sites, pages, publishing features, scripts, Web Parts, workflows, forms, integrations, permissions and owners. 

The outcome should be a reliable picture of what exists, what it supports and which dependencies are business-critical. Without this baseline, cost and effort estimates are likely to be incomplete. 

Step 2: Prioritise by Organisation Risk and Value 

Group assets into: 

Decision  Use when 
Retain for now  The item is still required and remains supportable during the transition 
Modernise or rebuild  The business purpose remains valid, but the current implementation is affected or unsustainable 
Archive  The content must be retained but does not need to remain active 
Retire  There is no continuing business, legal or records requirement 

Do not prioritise only by age or page volume. A small page supporting a critical process may carry more risk than a large archive of rarely used content. 

Step 3: Design the Target State 

Define the future information architecture, navigation, permissions, governance, ownership, publishing model and search experience before migration begins. 

Skipping this step usually moves existing duplication, poor ownership and confusing navigation into a newer interface. That creates delivery activity without resolving the underlying problem. 

Step 4: Test with a Representative Pilot 

Choose a contained area that represents the complexity of the wider environment. A pilot that includes only simple pages may produce a misleading view of cost and risk. 

Validate content, permissions, search, links, publishing, accessibility, integrations, user experience and support requirements. 

Step 5: Move in Controlled Waves 

Sequence work according to business criticality, technical risk and readiness. Validate each wave before expanding the programme. 

A phased approach reduces the size of any failure, allows estimates to be refined and prevents unresolved issues from being repeated across the estate. 

Step 6: Prepare Owners and Users 

Train content owners, site owners, administrators and support teams before responsibility transfers to the new environment. 

Success should be measured by whether people can find, trust, update and govern information, not only by the number of pages moved. 

Step 7: Decommission Only After Validation 

Remove legacy access and dependencies only when content, permissions, links, processes, ownership and support arrangements have been confirmed. 

Premature decommissioning creates avoidable disruption. Leaving old environments available indefinitely creates a different problem: duplicated information, unclear sources of truth and ongoing support costs. 

When Should Planning Begin?

Planning should begin now, but that does not mean every organisation needs to launch a full migration project immediately. 

The first priority is to establish whether your organisation is affected and how much business risk sits behind the affected pages and customisations. A relatively simple environment may require a contained modernisation project. A heavily customised publishing portal may require new architecture, rebuilt components, content decisions, testing and structured change management. 

Starting early protects choice. It gives the organisation time to plan expenditure, secure internal resources, engage stakeholders and resolve high-risk dependencies in a controlled sequence. Waiting reduces those options and increases the likelihood of rushed decisions, rework and unplanned cost. 

When External Support May Be Appropriate 

Not every organisation needs an external partner. If your internal team has a reliable estate inventory, current SharePoint expertise, clear ownership and sufficient delivery capacity, it may be able to manage the transition internally. 

Specialist support becomes more valuable when the organisation cannot confidently answer what it has, what is business-critical or what the modern target should look like. 

Indicators that external support may reduce risk 

  • There is no complete inventory of sites, pages or technical dependencies. 
  • The environment includes classic publishing portals or substantial customisation. 
  • Business-critical processes rely on scripts, workflows, forms or integrations. 
  • Site and content ownership is unclear. 
  • Internal teams do not have capacity to run discovery and remediation alongside operational work. 
  • Migration estimates vary significantly because scope is uncertain. 
  • The organisation needs an independent view of risk, options and likely effort. 
  • Previous SharePoint changes have moved content without improving usability or governance. 

How WebVine Can Help 

WebVine can begin with an assessment of the current environment rather than assuming that a full migration is required. 

The purpose of the assessment is to give the organisation a defensible view of its exposure, priorities and options. Depending on what is found, support may include: 

  • discovery and estate assessment 
  • identification of classic dependencies 
  • content and technical ownership mapping 
  • information architecture and target-state design 
  • classic-to-modern mapping 
  • content clean-up and disposition planning 
  • permissions and governance design 
  • pilot and migration planning 
  • testing and user acceptance support 
  • training, transition and ongoing optimisation 

The outcome should be clarity: what needs action, what can remain, what should be retired and what the organisation should budget and resource for. This reduces the risk of committing to a migration programme before the true scope is understood. 

The Priority Is Clarity, Not Panic 

Microsoft’s changes to classic SharePoint experiences do not mean that SharePoint Online is disappearing or that affected content will be deleted in 2028. They do mean that organisations will lose the ability to create or edit certain classic pages and maintain some legacy customisations in the same way. 

The cost of waiting is uncertainty. Without a clear view of affected pages, business processes and ownership, organisations risk discovering critical dependencies when there is less time to resolve them and fewer options available. 

A structured assessment provides the basis for a proportionate response. Some content may be straightforward to modernise. Some functions may need to be rebuilt. Other content may no longer justify the cost of carrying it forward. 

The organisations best placed to manage this change will be those that start with evidence, make deliberate decisions and modernise in controlled stages. Assess your classic SharePoint footprint now so you have more control over timing, cost and disruption. Ultimately we recommend using this opportunity to improve how information is managed across your organisation. 

About the Author – Chloe Dervin 

Chloe Dervin is Managing Director of WebVine and works with organisations to navigate the complexity of SharePoint, Microsoft 365 and the modern digital workplace. Her focus is on translating technology into practical business outcomes, helping organisations improve how information is managed, accessed and maintained while balancing capability, cost, risk and long-term sustainability. 

Frequently Asked Questions

Is Microsoft retiring SharePoint Online? 

No. Microsoft is changing specific classic publishing, user-created page and custom-script experiences within SharePoint Online. Modern SharePoint sites and pages are not the subject of this particular classic-page retirement.  

Will our classic SharePoint content be deleted? 

Microsoft states that existing affected classic page content will not be deleted. After the relevant phase takes effect, those pages will remain available for viewing in read-only form.  

Which classic pages will become read-only? 

Microsoft lists wiki pages, Web Part pages, blog pages, publishing pages and custom ASPX pages created using SharePoint Designer or third-party solutions.  

Are classic lists and libraries included? 

Classic list and library views and list form pages are not currently included in the classic-page read-only scope. However, custom scripts embedded in those experiences are subject to the announced scripting changes. 

Does a classic site need to be replaced completely? 

Not necessarily. The appropriate approach depends on the site type, page types, customisations and business requirements. Some pages may be suitable for transformation, while publishing portals or heavily customised environments may require a new modern structure. Microsoft notes that modern pages are not currently supported within certain classic publishing portals and recommends creating a new communication site for those scenarios. 

How can we tell whether we are affected? 

Review the site templates, page types, publishing features, Web Parts, master pages, custom scripts, workflows and third-party solutions in use. For a large or poorly documented environment, a formal assessment is more reliable than checking sites visually. 

Should we migrate everything to modern SharePoint? 

No. First decide what remains valuable and required. Content and functions should be assessed for modernisation, rebuilding, archiving or retirement. Moving everything without making those decisions preserves existing cost, duplication and governance problems. 

When should we start? 

Start with assessment and ownership now. The scale of any subsequent programme should be based on the evidence found, not on the assumption that every classic site needs the same response. 

Sources