Dismissione SharePoint Classic, cosa cambia con la decisione di Microsoft

Microsoft ha annunciato un cambiamento che riguarda tutte le organizzazioni che utilizzano ancora SharePoint Online nella sua versione Classic. L’obiettivo dichiarato è ridurre i rischi di sicurezza e di governance legati ai modelli di personalizzazione più datati, spingendo le aziende verso l’esperienza moderna di SharePoint, pensata per essere più sicura, più semplice da amministrare e pronta per i dispositivi mobili.

Il percorso di dismissione segue due fasi distinte, con date già definite, e coinvolge i siti di pubblicazione Classic, le pagine create dagli utenti e gli script personalizzati. Non si tratta di un cambiamento improvviso, perché Microsoft lascia un paio d’anni di finestra prima che gli effetti diventino irreversibili, ma proprio per questo conviene iniziare a ragionarci già ora, soprattutto se la propria intranet porta ancora in sé l’eredità di anni di personalizzazioni accumulate.

Le scadenze fissate da Microsoft per l’addio a SharePoint Classic

Fase 1, dal 1° marzo 2027

A partire da questa data, su tutti i tenant non sarà più possibile creare nuovi siti di pubblicazione Classic, né come raccolte siti né come sottositi. Allo stesso modo, non si potrà più attivare la funzionalità di pubblicazione Classic dove non è già abilitata. L’impostazione di tenant che consente la creazione di questi siti verrà bloccata in modo permanente.

Per i tenant creati a partire dal 1° marzo 2027, la restrizione è più ampia, perché gli utenti non potranno più creare nuove pagine Classic e l’aggiunta o la modifica di script personalizzati sarà disattivata di default.

Fase 2, dal 1° ottobre 2028

Dal 1° ottobre 2028, le limitazioni introdotte nella prima fase si estendono a tutti i tenant esistenti, compresi quelli attivi da anni. Le pagine Classic create dagli utenti diventano di sola lettura, quindi non sarà più possibile crearne di nuove né modificare quelle esistenti. Anche in questo caso, la possibilità di aggiungere o aggiornare script personalizzati verrà disattivata.

Microsoft precisa che le pagine restano comunque accessibili in visualizzazione anche dopo questa seconda scadenza, un dettaglio che vale la pena sottolineare perché toglie l’ansia della cancellazione, ma non riduce l’urgenza di pianificare, dato che una pagina che non si può più modificare, in pratica, smette di essere utile come strumento di comunicazione interna.

Quali pagine e quali ambienti sono coinvolti

La dismissione riguarda specificamente alcune tipologie di pagine Classic create dagli utenti: le wiki page, le web part page, le pagine di blog, le publishing page e le pagine ASPX personalizzate, create con SharePoint Designer o con soluzioni di terze parti. Chi lavora quotidianamente con SharePoint riconoscerà in questo elenco gran parte delle pagine che compongono una intranet costruita con l’approccio più datato, quello basato su layout fissi e inserimenti di codice piuttosto che su web part configurabili.

Restano invece fuori da questo perimetro le viste di liste e raccolte documentali e le pagine dei relativi form, anche se gli script personalizzati eventualmente incorporati al loro interno sono comunque soggetti alle nuove restrizioni sulla creazione e modifica di script. È una distinzione tecnica che vale la pena tenere a mente quando si fa l’inventario: non tutto ciò che è “vecchio” in un tenant SharePoint rientra in questa dismissione, e non tutto ciò che ne resta fuori è al sicuro dalle regole sugli script.

Il cambiamento si applica a tutti gli ambienti Microsoft 365, inclusi quelli Government (GCC, GCC High e DoD), gli ambienti air-gapped di Office 365 e Microsoft 365 operato da 21Vianet. Non ci sono quindi eccezioni legate al tipo di piano o al settore di appartenenza dell’organizzazione.

Perché Microsoft ha deciso di intervenire ora

Le pagine Classic e i modelli di personalizzazione legacy si basano su rendering lato server e su script personalizzati, tecnologie che secondo Microsoft aumentano il rischio di sicurezza, la complessità amministrativa e i costi di manutenzione nel lungo periodo. Un sito costruito con master page personalizzate o con script aggiunti anni fa da un fornitore che magari non lavora più con l’azienda diventa, con il tempo, un oggetto che nessuno vuole più toccare per paura di romperlo, ed è esattamente questo tipo di debito tecnico che Microsoft vuole ridurre.

C’è anche un tema di velocità di innovazione. Il modello Classic limita la coerenza con cui è possibile introdurre nuove funzionalità, mentre l’esperienza moderna di SharePoint offre un ambiente di collaborazione più sicuro e governato, una gestione dei permessi più semplice attraverso i gruppi di Microsoft 365, un’interfaccia pensata fin dall’origine per i dispositivi mobili e, soprattutto in prospettiva, le fondamenta su cui si basano le funzionalità più recenti legate all’intelligenza artificiale. Chi resta ancorato alle pagine Classic rischia quindi non solo un problema di sicurezza, ma anche di restare escluso da questo tipo di evoluzione.

Chi ha già approfondito le differenze tra le due esperienze lo sa bene, perché il salto da SharePoint Classic a SharePoint Modern non riguarda solo l’estetica delle pagine, ma tocca la gestione dei permessi, l’integrazione nativa con Teams e Outlook e la possibilità di automatizzare flussi di lavoro con Power Automate, tutti ambiti in cui il modello Classic mostra ormai i suoi limiti.

I 4 passaggi consigliati da Microsoft per modernizzare SharePoint Classic

La documentazione ufficiale suggerisce un approccio graduale, pensato per ridurre i rischi legati alla migrazione e dare ai proprietari dei siti il tempo di validare le pagine modernizzate.

1. Individuare e valutare l’ambiente Classic esistente

Il primo passo, e probabilmente il più importante, è capire quanti siti e pagine Classic sono ancora attivi nel tenant. Microsoft mette a disposizione gli eventi di audit di Microsoft Purview nella categoria dedicata alle attività Classic, che comprendono la creazione, la modifica e la visualizzazione di pagine Classic, oltre al Microsoft 365 Assessment Tool, pensato specificamente per individuare pagine, web part e pattern di personalizzazione ancora presenti nell’ambiente. L’output di questo strumento include un inventario dettagliato per ogni pagina trovata, con un indicatore di quanto sia complesso trasformarla nell’esperienza moderna.

Se la valutazione non rileva siti di pubblicazione Classic, pagine create dagli utenti o script interessati dalle nuove regole, non è richiesta alcuna azione ulteriore. Ma è un esito meno scontato di quanto sembri, perché alcune realtà che si credevano già del tutto moderne hanno scoperto, una volta fatta una verifica puntuale, di avere ancora decine o centinaia di pagine Classic dimenticate in siti secondari, spesso create anni prima da team che nel frattempo sono cambiati.

2. Dare priorità in base all’importanza per il business

Conviene partire dalle pagine più utilizzate, più modificate di frequente o più rilevanti per l’attività aziendale, raggruppandole per complessità e per tipo di intervento necessario, così da poter riutilizzare quanto appreso nelle fasi successive. Una pagina di news visitata ogni giorno da centinaia di persone merita un trattamento diverso da una pagina statica che nessuno apre da anni.

3. Trasformare le pagine nell’esperienza moderna

Per la trasformazione vera e propria, Microsoft indica la guida ufficiale alla modernizzazione e PnP PowerShell come strumento per una conversione deterministica delle pagine con un pattern ricorrente. Per gli scenari più complessi, con HTML personalizzato o contenuti script editor che richiedono un giudizio umano, Microsoft segnala anche SharePoint Page Migration Agent, un progetto open source attualmente in anteprima. Vale la pena ricordare che gli strumenti open source e in anteprima non hanno una copertura SLA del supporto Microsoft, e che le pagine più personalizzate possono comunque richiedere una revisione o una ricostruzione manuale.

4. Procedere per ondate

L’indicazione finale è di combinare una pianificazione centralizzata con l’esecuzione da parte dei singoli proprietari dei siti, modernizzando per gruppi successivi di pagine anziché tutte insieme. Questo approccio a ondate permette di validare contenuti, link, permessi, web part e layout su un numero contenuto di pagine prima di estendere l’intervento al resto del tenant, limitando il rischio di dover correggere lo stesso errore su centinaia di pagine diverse.

Un tema che riguarda soprattutto i tenant più grandi e più stratificati

Le organizzazioni che negli anni hanno costruito la propria intranet su SharePoint Server on-premises e poi sono migrate verso SharePoint Online tendono ad avere un numero più alto di siti, pagine e personalizzazioni Classic ancora attive, spesso senza che il reparto IT ne abbia una mappatura completa e aggiornata. È un pattern ricorrente, perché ogni passaggio di responsabilità tra team diversi, ogni fornitore esterno che ha lavorato sul tenant in un certo periodo e ogni riorganizzazione aziendale lasciano dietro di sé qualche sito che nessuno più presidia attivamente, ma che continua a esistere e a essere raggiungibile.

Più il tenant è grande e stratificato nel tempo, più la fase di censimento richiede attenzione, perché pagine e personalizzazioni possono essere distribuite su siti diversi, gestiti da team diversi, con livelli di documentazione molto disomogenei tra loro. Le due scadenze fissate da Microsoft, marzo 2027 e ottobre 2028, offrono una finestra di tempo utile per affrontare il problema con ordine, ma è proprio la fase di analisi iniziale, quella che permette di capire realmente quante pagine Classic sono ancora in uso e con quale livello di complessità, a richiedere la pianificazione più attenta, perché è il momento in cui si scopre la reale dimensione del lavoro da fare, prima ancora di cominciare a modernizzare qualcosa.

Da dove iniziare se non si ha ancora un quadro chiaro

Per le aziende di dimensioni medio-grandi, indicativamente oltre i 300 utenti, il primo ostacolo è quasi sempre capire se il problema le riguardi davvero, più che un aspetto tecnico. Un buon punto di partenza è farsi, o farsi rispondere dal proprio reparto IT, tre domande semplici.

1. L’azienda ha utilizzato in passato SharePoint Server o SharePoint on-premises?
2. È stata effettuata una migrazione verso SharePoint Online?
3. Si sa con certezza se nel tenant sono rimaste pagine, siti o personalizzazioni Classic?

Se la risposta alla terza domanda è incerta, conviene coinvolgere direttamente il referente IT per una verifica puntuale, piuttosto che fermarsi a un’impressione preliminare. Capita più spesso di quanto si pensi che aziende convinte di non avere più nulla di Classic scoprano, dopo un controllo più approfondito, oltre 120 pagine ancora attive e dimenticate in siti secondari. Una verifica fatta per tempo, anche solo qualitativa, permette di pianificare con margine, invece di scoprire la reale portata del lavoro a ridosso delle scadenze.