This weekend, I strapped on an Apple Vision Pro to watch a baseball game in immersive virtual reality for the first time. It was technically impressive, visually pretty remarkable, and also didn't make that much sense.

Apple and Major League Baseball chose a classic match-up of the Boston Red Sox and the New York Yankees for the first of its series of four games streamed on the device. I do not review tech for The Verge, but I do watch a lot of baseball - if there's a game on and I'm at home, it's likely on my television. If this is the future of sports, live events, and wearable technology in general, I'd like to see what all the fuss is a …

Read the full story at The Verge.

In 2016, we introduced modern SharePoint and the SharePoint Framework to our online service – a cloud-born user experience & developer extensibility framework. Ten years later, we continue to invest in this stable platform to provide reliable, well-governed, AI-ready, mobile-friendly, and secure-by-default foundations for customers’ publishing and content management needs.

Also in 2016, we renamed our previous publishing and UX extensibility system to “classic”. These features were designed to ease our customers’ transition from on premises environment to the cloud service. Now, ten years later, these classic features are used by fewer than 5% of our monthly active tenant base, and the classic SharePoint page content is not participating in the latest ways content should be secured, managed, and shared. Classic pages are also not fully represented in the content formats that power Microsoft 365 Copilot, which can reduce the coverage and accuracy of Copilot responses that draw on classic content. As such, over the next two years, we will take steps to retire classic SharePoint pages and custom scripting add/update capability in SharePoint Online from Microsoft 365 – below you will find details on timelines, assessment tooling, and migration guidance.

Overview

We are introducing a set of changes to classic experiences in SharePoint Online across two phases.

No classic page content or data will be deleted by Microsoft in these phases. Existing pages will remain accessible in a read-only form.

Phase 1 – Beginning March 1, 2027 

The following changes will take effect:

For all tenants

• Creation of new classic publishing sites and activation of the classic publishing feature will be disabled for site collection and sub sites.
• The AllowClassicPublishingSiteCreation tenant setting will be enforced as False and cannot be changed.

For new tenants created on or after March 1, 2027

• Users cannot create new classic pages — including wiki pages, web part pages, blog pages, publishing pages, and custom ASPX pages.
• The ability to add or update custom scripts will be disabled by default, and the site setting DenyAddAndCustomizePages will be enforced as True and cannot be changed. Note that this setting applies only to classic pages — modern SharePoint pages are not affected, and custom solutions built on the SharePoint Framework (SPFx) will continue to work under your organization's existing governance.

Phase 2 - Beginning October 1, 2028

The following changes will extend to all tenants:

• Classic user-created pages — including wiki pages, web part pages, blog pages, publishing pages, and custom ASPX pages — will become read-only. Users will no longer be able to create or edit these classic pages.
• The ability to add or update custom scripts will be disabled and the DenyAddAndCustomizePages site setting will be enforced as True and cannot be changed.

What you should do now

For SharePoint administrators:

• No data or content will be deleted by Microsoft as part of this change, and all existing data governance features will continue to be honored and continue to function. 
• Discover and assess your classic SharePoint environment     
  Identify usage of classic sites and pages across your tenant. Use the “SharePoint Classic Activities” Purview Audit log category - included in Audit (Standard) and available to all organizations, and events (ClassicPageCreated, ClassicPageEdited, and ClassicPageViewed) to identify active classic page usage, and leverage the Microsoft 365 Assessment Tool to understand the overall classic scope and modernization feasibility.
• Prioritize based on business importance and usage
  If your assessment finds no classic content, none of these changes apply to your organization — no action needed. Otherwise, focus first on high-value or frequently updated classic sites and pages, and identify where modernization will have the greatest impact. Classifying content by business criticality can help guide a phased migration plan.
• Transform to modern SharePoint experiences before enforcement deadlines
  SharePoint administrators should use modernization tools such as SharePoint PnP Modernization and SharePoint Page Modernization Agent to convert classic pages into modern SharePoint experiences where applicable. Microsoft will continue enhancing the tooling to accelerate page modernization with best-effort fidelity reservation, but it may not fully automate complex scenarios; modernization is a project that typically requires planning, resourcing, and highly customized pages often need redesign or manual rebuilding.
• Adopt a phased migration strategy
  Combine centralized IT-led planning and prioritization with distributed execution by site owners over time. Most organizations find success by modernizing page content in waves rather than attempting a single large-scale migration.

For detailed guidance, tools, and step-by-step recommendations, refer to the Microsoft Learn article. 

For site owners and content authors: 

Site owners should work with their SharePoint administrators to identify classic sites and pages that are still actively used and determine which content should be modernized, retired, or replaced. Documentation, assessment tools, and migration guidance linked below can help organizations understand available modernization options and prepare for the transition.

How do I get help?

Refer to the following documentation, tools, and Microsoft partner resources to support your migration from classic SharePoint experiences:

• Modernize your classic SharePoint sites | Microsoft Learn
• Transform classic pages to modern pages | Microsoft Learn
• Microsoft 365 Assessment Tool
• Microsoft Solution Providers

Learn more

For complete details, timelines, FAQs, and ongoing updates, see the Microsoft Learn announcement. 

A Message Center post in the Microsoft 365 admin center has been sent to all tenants. (MC1464926 & MC1464924)

 Background 

Historically, DevOps Auditing could be configured through the server-level auditing API using the isDevopsAuditEnabled property under: 

Microsoft.Sql/servers/auditingSettings 

As Azure SQL auditing capabilities evolved, a dedicated resource was introduced specifically for DevOps Auditing: 

Microsoft.Sql/servers/devOpsAuditingSettings 

This dedicated API is now the supported approach for configuring DevOps Auditing.  

The Question 

Customers occasionally observe that setting isDevopsAuditEnabled=true continues to work on some servers but not on others. 

A recent customer engagement highlighted this scenario where the same deployment was able to enable DevOps Auditing on most servers, while a smaller subset of servers ignored the setting even though the ARM operation completed successfully.  

At first glance, this appears inconsistent. However, the behaviour is expected. 

How Backward Compatibility Works 

Today, Azure SQL maintains backward compatibility for customers who still use the legacy auditing API. 

The behaviour is as follows: 

1. The recommended and supported approach is to use the dedicated DevOps Auditing resource: 

Microsoft.Sql/servers/devOpsAuditingSettings 

1. The isDevopsAuditEnabled property under: 

Microsoft.Sql/servers/auditingSettings 

is no longer recommended for new implementations. 

1. To preserve backward compatibility, the legacy property may continue to work for servers that have never been migrated to the new model. 

1. Once the dedicated DevOps Auditing API is used on a server for the first time, that server is permanently marked as migrated. 

1. After migration, the legacy isDevopsAuditEnabled property is no longer honoured for that server, even if it is supplied in subsequent requests.  

Why Some Servers Behave Differently 

Consider an environment with hundreds of Azure SQL servers managed through ARM templates or Azure Policy. 

The deployment may successfully update: 

{ 

"type": "Microsoft.Sql/servers/auditingSettings", 

"properties": { 

"isDevopsAuditEnabled": true 

} 

} 

For servers that have never used the new DevOps Auditing resource, the setting may still take effect. 

For servers that were previously configured through: 

Microsoft.Sql/servers/devOpsAuditingSettings 

the server is already considered migrated. In these cases, the request can complete successfully, but the legacy property is ignored and DevOps Auditing remains unchanged.  

Recommended Action 

Customers should migrate all automation, ARM templates, Bicep templates, Terraform deployments, and Azure Policies to use the dedicated DevOps Auditing resource: 

Microsoft.Sql/servers/devOpsAuditingSettings 

and avoid relying on the legacy isDevopsAuditEnabled property going forward.  

Key Takeaway 

If isDevopsAuditEnabled appears to work for some servers but not others, it is usually due to the server's migration state: 

• Not yet migrated → legacy flag may still work. 

• Already migrated → legacy flag is ignored. 

• Use Microsoft.Sql/servers/devOpsAuditingSettings for all future configurations.  

This behaviour allows Azure SQL to maintain backward compatibility while providing a clear migration path to the dedicated DevOps Auditing configuration model.  

Gant Laborde returns to the podcast for a recap of all things Chain React! Robin and Mazen chat with Gant about the trends he saw at Chain React this year — from Expo's keynote to AI's growing role in software development — as well as why in-person conferences are still at the center of what motivates us as a community.

Show Notes

1. Chain React Recap Video

Connect With Us!

• Gant Laborde: @gantlaborde
• Robin Heinze: @robinheinze
• Mazen Chami: @mazenchami
• React Native Radio: @ReactNativeRdio

This episode is brought to you by Infinite Red!

Infinite Red is a premier mobile app consultancy, especially focused on Expo and React Native, located fully remote in the US. We’re a team of 30 with highly experienced mobile app developers and have been doing this for over a decade. We are also one of the first development teams to adopt agentic coding in a way that keeps high quality standards and aren’t afraid to do things the old school way if we need to. If you’re looking for mobile app or React Native or Expo expertise for your next project, hit us up at infinite.red/radio.