SharePoint Online Weekly Update — September 21, 2026

The Classic Retirement Clock Finally Has Dates

The headline item this week is a message center notice, MC1464926, that converts years of "classic is going away eventually" hand-waving into two firm dates. Beginning March 1, 2027, SharePoint Online disables creation of new classic publishing sites — for both site collections and subsites — and the AllowClassicPublishingSiteCreation tenant setting is enforced to False and can no longer be changed. New tenants created on or after that date also lose the ability to create any classic user-created pages, a category that includes wiki pages, web part pages, blog pages, publishing pages, and custom ASPX pages authored in SharePoint Designer or third-party tools. Then, beginning October 1, 2028, every remaining tenant's un-modernized classic user-created pages become read-only, and custom scripting enforcement extends to all tenants.

Crucially, nothing is deleted. Existing classic sites and pages keep rendering, and users can continue to open and view them; what disappears is the ability to create new classic surfaces and, eventually, to edit the old ones. That distinction is exactly why this announcement is dangerous to ignore. There is no outage, no broken link on day one, and therefore no forcing function — which means the organizations that do nothing will discover in late 2028 that a business-critical wiki or publishing page has silently gone read-only with no owner and no modernization plan.

The right framing is that this is a modernization program, not a page migration you can cram into the final quarter. Classic publishing sites tend to be the oldest, most heavily customized, and least documented corners of a tenant — precisely the content that resists a one-click modern conversion. The tenants that come through this cleanly will be the ones that inventory now, assign business owners while those owners still remember why a page exists, and validate a repeatable modern pattern before trying to scale it across hundreds of pages.

What to do: Run an inventory of classic publishing sites and classic user-created pages in your tenant this quarter, assign a named business owner to each surface that must remain editable past October 1, 2028, and stand up a validated modernization pattern now rather than treating the 2027–2028 dates as a distant problem.

Copilot in SharePoint: Skills That Travel, and Safe HTML for Agents

The September Copilot in SharePoint update pushes hardest on a single idea: the intelligence you build should not be trapped on one site. Personal skills now follow you across SharePoint and OneDrive, so a format, standard, or repeatable way of working you define once travels with you instead of being re-created on every site. Microsoft is pairing that portability with evaluations — a way to measure whether a skill is actually producing good output and improve it over time — which is the difference between a novelty prompt and a governed, dependable capability.

The more consequential piece for anyone building on the platform is tenant-specific HTML guidance for AI agents. Every Microsoft 365 customer now has a tenant-scoped set of instructions that an external assistant — Copilot Studio, GitHub Copilot, or any other agent — can point at to learn how to generate HTML that actually works inside SharePoint's sandbox, including support for live-linked SharePoint lists. In plain terms, Microsoft is publishing the rulebook for making AI-generated content behave inside SharePoint instead of leaving every agent to guess and produce markup that renders broken or gets stripped.

For organizations shaping their own AI programs, this is the more strategic of the two changes. It signals that Microsoft expects agents — not just Copilot — to be authoring live SharePoint experiences, and it hands you a supported contract for doing so safely. Teams that treat that HTML guidance as the canonical reference for any agent touching SharePoint will avoid a coming mess of brittle, one-off, sandbox-violating output.

What to do: Decide who in your organization may create and publish personal Copilot skills, adopt the new evaluations as a gate before a skill becomes an approved standard, and route any team building agents that generate SharePoint content to your tenant's HTML guidance so their output stays inside the supported sandbox.

SharePoint Syntex Becomes SharePoint Premium

A small rename in the admin center carries a larger message. The entry point formerly labeled SharePoint Syntex now appears as SharePoint Premium, sitting under the Content Services section of the SharePoint admin center. Existing Syntex licenses migrate automatically and no admin action is required, so this is a cosmetic change on the surface — but names in the admin center are how Microsoft tells you where a product is headed, and "Premium" is the banner it is consolidating its advanced content, AI, and governance capabilities under.

Riding alongside the rebrand is a genuinely useful end-user capability: Copilot can now suggest contextual column filters in document library views, based on the user's recent activity and the library's content type. Instead of a user manually building a filtered view to find the subset of documents they care about, Copilot proposes the filter. It is a modest feature in isolation, but it is another instance of the pattern running through everything this month — the intelligence is moving into the everyday surfaces of SharePoint rather than living in a separate Copilot pane.

The practical note for admins is simply not to be surprised. If a runbook, training deck, or license conversation still says "Syntex," it is now pointing at a name that no longer appears in the console, and the people you support will start asking where SharePoint Premium came from.

What to do: Update internal documentation and training that references SharePoint Syntex to say SharePoint Premium, confirm your advanced content-services licensing carried over cleanly, and let end users know Copilot's suggested column filters are a feature rather than an unexpected change to their libraries.

Microsoft 365 Backup Goes Full-Workload

Protection for SharePoint content took a meaningful step forward this month with the general availability rollout of a Full Workload Backup capability in Microsoft 365 Backup, beginning mid-September. Rather than assembling backup coverage site by site, administrators can now define a single backup policy that spans an entire workload — SharePoint, OneDrive, and Exchange Online — in one action. For large tenants where site sprawl made comprehensive, policy-based coverage genuinely hard to guarantee, this closes a real gap between "we have backup" and "we have backup for everything that matters."

The strategic value here is coverage certainty. Per-site or per-scope backup policies are the kind of configuration that quietly falls behind reality: new sites get provisioned, no one adds them to the policy, and the gap only becomes visible during an incident. A workload-level policy inverts that default, treating full coverage as the baseline and making exclusions the deliberate exception.

Backup is also increasingly part of the ransomware and accidental-deletion conversation rather than a pure compliance checkbox, and it pairs naturally with the archiving and lifecycle work Microsoft has been shipping all year. As stale content gets archived and aged out, having a dependable, workload-wide restore point underneath it all is what makes aggressive lifecycle policies safe to adopt.

What to do: Evaluate the new Full Workload Backup policy for Microsoft 365 Backup, replace any patchwork of per-site backup scopes with workload-level coverage where it fits your recovery objectives, and confirm that SharePoint and OneDrive restore points align with the retention and archiving policies you already run.

File Archiving Arrives Inside Purview Retention Policies

Microsoft Purview continues its steady absorption of the SharePoint content lifecycle, and this month brings file archiving support in SharePoint Online directly into data retention policies. Administrators can now fold an archiving action into the retention policies they already manage, so instead of archiving being a separate motion, cold or aging content can be moved into an archived state as part of the same governed lifecycle rule that decides what to keep and for how long.

This matters because archiving and retention have historically been two disconnected disciplines — one about cost and storage tiering, the other about compliance — administered in different places by different owners. Bringing archiving into retention policy collapses that seam. A single policy can now express both "keep this for seven years" and "and move it to archive storage once it goes cold," which is a far more honest model of how content actually ages.

For AI programs the connection is, once again, grounding hygiene. Content that has been archived out of the active tier is content that is far less likely to surface as a stale, out-of-context Copilot answer. Organizations that wire archiving into their retention policies are not just saving on storage — they are actively shrinking the surface area of forgotten documents that an AI assistant could otherwise resurface.

What to do: Review your existing Purview retention policies for SharePoint and OneDrive and identify where an archiving action now belongs, coordinate between your storage and compliance owners so a single policy governs both retention and archival tiering, and treat archived-out content as one fewer liability for Copilot grounding.

Retirement Watch: The October 1 OTP Cutoff Is Now Days Away

Amid all the new capability, the hardest deadline on the calendar is now measured in days. The SharePoint One-Time Passcode (OTP) external authentication method begins its production retirement on October 1, 2026, completing across environments by month-end, with external sharing shifting to Microsoft Entra B2B guest accounts. Once OTP retires, external sharing links that depend on it start to fail, so the window to pre-provision B2B guests for the partners you actively collaborate with has narrowed to a final sprint.

This week's classic experiences timeline joins the longer-horizon watch list alongside it. So does the retirement of all four standalone SharePoint Online and OneDrive for Business plans — no new sales after May 2026, no renewals after January 2027, full retirement by December 2029 — which affects any organization licensing SharePoint outside a Microsoft 365 suite. And earlier 2026 cutoffs for the SharePoint Add-in model, Azure Access Control Service (ACS), and legacy IDCRL authentication are already behind us; anything still leaning on them is an open incident, not a planning item.

The pattern across all of these is the same one that makes them easy to miss: nothing breaks loudly on the cutoff date, so the cost of inaction shows up weeks later as a failed external share, a lapsed license, or a page that has quietly gone read-only. A standing "retirement watch" that someone actually owns is the cheapest insurance against that class of surprise.

What to do: Before October 1, do a final sweep of external sharing for links relying on SPO OTP and pre-provision Entra B2B guests for active partners; then add this week's classic publishing and custom scripting timeline to a maintained retirement watch, and confirm your path on standalone SharePoint plans and any lingering Add-in, ACS, or IDCRL dependencies.

Sources

Back to all news