People hold on to useful intranet links for years. A manager bookmarks the checklist for bringing on a new employee. Someone else keeps last year’s benefits email because it’s the easiest way to find the enrollment page again. When people go back to those pages, they expect the link to work and the instructions to be current.
For the HR team behind that benefits page, the work comes in a burst just before enrollment. Someone has to update the dates, check the plan links, and get the revised guidance approved. That work might happen only once a year, on a deadline set by the start of enrollment.
That benefits page might still use SharePoint Online’s classic authoring tools. Microsoft is phasing out the ability to create and edit classic pages, in part because of the security and governance risks of the old customization model. An existing page will still open when it goes read-only. That can be enough for a notice HR keeps as a record. A page employees use for current instructions needs an editable replacement. I’d move it to modern SharePoint early enough to test publishing and make sure people following old links reach the new guidance before enrollment opens.
Microsoft’s SharePoint Online rollout starts on March 1, 2027. The first phase blocks creation of new classic publishing sites and activation of classic publishing features across tenants, for both site collections and subsites. Tenants created on or after that date also start with classic page creation and custom script changes blocked. Beginning October 1, 2028, those page and scripting restrictions extend to existing tenants and their classic user-created pages become read-only.
The page freeze covers classic wiki pages, Web Part pages, blogs, publishing pages, and custom ASPX pages made with SharePoint Designer or other tools. Classic list and library views and list forms fall outside the page freeze. Their embedded scripts still come under the scripting changes. When the restriction applies, SharePoint enforces DenyAddAndCustomizePages=True. The Message Center notice says existing scripts can continue to run. The ability to maintain those scripts goes away, which matters the next time a URL changes or an integration needs a fix. Microsoft’s security rationale makes sense here. Classic custom script can run with the access of the person viewing the page.
The March date matters immediately to anyone designing a migration from SharePoint Server. A plan to recreate a classic publishing portal in a new SharePoint Online site and modernize it later depends on a target Microsoft is closing. The migration guidance makes that constraint explicit. I would design the modern publishing destination as part of the move and test a representative portal before committing to a migration schedule.
Where I would keep publishing in SharePoint
I would start with the Microsoft 365 Assessment Tool and the classic page creation, edit, and view events in Microsoft Purview Audit. The inventory tells you what is there, including which Web Parts a page uses. The audit events show how people have used the pages during the period you can see. Ask the site owners which pages have to be correct on a specific day and which ones help people carry out a process. Open enrollment and annual policy updates can make pages with modest traffic worth moving early.
Take a department’s classic team site where the members, document libraries, and permissions still make sense. I would replace the live wiki or Web Part pages with modern pages in that site where in-place transformation is supported. The team can keep working in the same libraries. If the original URL is widely used, make keeping it or giving readers a clear route to the new page part of the cutover. A rewrite that works from the site home page can still strand someone who arrives from an old bookmark. I would use a separate publishing site if the old team site also contains working files that readers of the approved guidance should never see. That gives the editors a place to publish while the working team keeps its own permissions and collaboration space.
A classic publishing portal calls for more design. Its master pages, layouts, and subsites may embody years of choices about who publishes and how employees find the result. For a benefits portal, I would use a modern communication site with a small group of authors and a broader audience of readers. The new layout should make the enrollment date and next action easy to find. Recreate the review process with modern page approval where it fits. Map links and access to the new site explicitly, especially if the portal had separate guidance for different employee populations. Audience targeting can put the relevant link in front of each group. If access to the guidance itself is restricted, test permissions using the direct page URL too.
For a few important pages, an editor can often rebuild them faster than a project team can define conversion rules. For hundreds of similar pages, PnP page transformation gives you a repeatable way to convert supported layouts and Web Parts. Classic publishing pages need a cross-site transformation plan with layout and metadata mapping. The open-source SharePoint Page Modernization Agent is in preview and may help with pages that contain custom markup. I would evaluate it on a small sample and have the editors validate what it produces. For any automated conversion, test the result with the people who use it, including links, permissions, and the ability to make the next edit.
When I would choose a different home
Suppose the enrollment page contains a script that looks up an employee’s eligibility. The owner of that script has a different problem from the editor who publishes the deadline. If the requirement is a small, reusable display within the intranet, a governed SharePoint Framework Web Part can integrate with approved APIs under the applicable permissions. If employees use the old page to make elections, I would put that transaction in the benefits application, where eligibility, confirmation, and decision history belong. The modern SharePoint page can explain the process and take people to the application.
Microsoft is also rolling out HTML pages in SharePoint. I would consider one for a self-contained explainer with an interactive chart where the feature is available. SharePoint renders it in a sandbox that blocks arbitrary outbound API calls, so the eligibility lookup still needs an approved integration. For a benefits page the HR team has to edit every year, I would start with a standard modern page its authors can maintain themselves.
Some classic pages only have value as history. An approved copy of last year’s guidance might need to be retrievable as a record. It can stay readable or move to a managed archive, depending on the records policy. The records owner should be able to retrieve the exact approved version and any evidence that has to accompany it. A read-only page can still contain a Web Part that pulls in live data. Where the record has to show what employees were told on a particular date, preserve the approved content and any referenced material needed to establish that. Before the old page freezes, I would make clear which page gives current instructions and update the links employees use most. If records rules prevent changing the source, put that direction in the current intranet and manage how the historical copy is found. If the page is a copy of something already maintained in a public publishing system, I would consolidate it there. Product documentation that ships with a release should follow the team that owns the release. The intranet can point employees to the current version.
For the first wave, I would take one ordinary team site and one publishing site with a real deadline. Have an editor change and submit the page, an approver release it, and an employee find the correct instructions from an old link and from search. If a page contains an eligibility tool, test that separately with the people who use it. Once the owners can carry out the next publishing cycle on the new site, they can decide which remaining pages deserve the same work and which should be kept as records.