SharePoint Classic Einstellung: Was sich durch Microsofts Entscheidung ändert

Microsoft hat eine Änderung angekündigt, die alle Organisationen betrifft, die noch SharePoint Online in der Classic-Version nutzen. Erklärtes Ziel ist es, die Sicherheits- und Governance-Risiken älterer Anpassungsmodelle zu reduzieren und Unternehmen zur modernen SharePoint-Erfahrung zu bewegen, die sicherer, einfacher zu administrieren und mobilfreundlich gestaltet ist.

Der Einstellungsprozess verläuft in zwei unterschiedlichen Phasen mit bereits festgelegten Terminen und betrifft Classic-Publishingsites, von Nutzern erstellte Seiten und benutzerdefinierte Skripte. Es handelt sich nicht um eine plötzliche Änderung, da Microsoft ein paar Jahre Zeitfenster lässt, bevor die Auswirkungen unumkehrbar werden. Genau deshalb lohnt es sich, schon jetzt darüber nachzudenken, vor allem wenn Ihr Intranet noch das Erbe jahrelang angesammelter Anpassungen in sich trägt.

Die von Microsoft festgelegten Fristen für den Abschied von SharePoint Classic

Phase 1, ab dem 1. März 2027

Ab diesem Datum ist es in allen Tenants nicht mehr möglich, neue Classic-Publishingsites zu erstellen, weder als Websitesammlungen noch als Unterwebsites. Ebenso kann die Classic-Publishing-Funktion dort, wo sie noch nicht aktiviert ist, nicht mehr eingeschaltet werden. Die Tenant-Einstellung, die das Erstellen dieser Sites erlaubt, wird dauerhaft gesperrt.

Für Tenants, die ab dem 1. März 2027 neu erstellt werden, ist die Einschränkung umfassender: Nutzer können dann überhaupt keine neuen Classic-Seiten mehr erstellen, und das Hinzufügen oder Bearbeiten benutzerdefinierter Skripte wird standardmäßig deaktiviert.

Phase 2, ab dem 1. Oktober 2028

Ab dem 1. Oktober 2028 gelten die in der ersten Phase eingeführten Einschränkungen für alle bestehenden Tenants, auch für solche, die seit Jahren aktiv sind. Von Nutzern erstellte Classic-Seiten werden schreibgeschützt, sodass keine neuen mehr erstellt und bestehende nicht mehr bearbeitet werden können. Auch hier wird die Möglichkeit, benutzerdefinierte Skripte hinzuzufügen oder zu aktualisieren, deaktiviert.

Microsoft stellt klar, dass die Seiten auch nach dieser zweiten Frist in der Ansicht zugänglich bleiben (ein Detail, das man hervorheben sollte, weil es die Sorge vor der Löschung nimmt, aber die Dringlichkeit der Planung nicht verringert): Eine Seite, die nicht mehr bearbeitet werden kann, hört praktisch auf, als Werkzeug der internen Kommunikation nützlich zu sein.

Welche Seiten und welche Umgebungen betroffen sind

Die Einstellung betrifft konkret bestimmte Arten von nutzererstellten Classic-Seiten: Wiki-Seiten, Webpart-Seiten, Blogseiten, Publishing-Seiten und benutzerdefinierte ASPX-Seiten, die mit SharePoint Designer oder Lösungen von Drittanbietern erstellt wurden. Wer täglich mit SharePoint arbeitet, wird in dieser Liste einen Großteil der Seiten wiedererkennen, aus denen ein Intranet besteht, das mit dem älteren Ansatz aufgebaut wurde, mit festen Layouts und eingefügtem Code statt konfigurierbarer Webparts.

Listen- und Dokumentbibliotheksansichten sowie die zugehörigen Formularseiten fallen dagegen nicht in diesen Geltungsbereich, auch wenn darin eventuell eingebettete benutzerdefinierte Skripte trotzdem den neuen Einschränkungen für das Erstellen und Bearbeiten von Skripten unterliegen. Diese technische Unterscheidung sollte man sich bei der Bestandsaufnahme merken: Nicht alles „Alte” in einem SharePoint-Tenant fällt unter diese Einstellung, und nicht alles, was davon ausgenommen ist, ist vor den Skriptregeln sicher.

Die Änderung gilt für alle Microsoft-365-Umgebungen, einschließlich der Government-Umgebungen (GCC, GCC High und DoD), der air-gapped-Umgebungen von Office 365 sowie des von 21Vianet betriebenen Microsoft 365. Es gibt also keine Ausnahmen je nach Plantyp oder Branche der Organisation.

Warum Microsoft jetzt handelt

Classic-Seiten und veraltete Anpassungsmodelle basieren auf serverseitigem Rendering und benutzerdefinierten Skripten, Technologien, die laut Microsoft das Sicherheitsrisiko, die administrative Komplexität und die langfristigen Wartungskosten erhöhen. Eine Site, die vor Jahren mit angepassten Masterpages oder Skripten eines Anbieters aufgebaut wurde, der heute vielleicht nicht mehr mit dem Unternehmen zusammenarbeitet, wird mit der Zeit zu etwas, das niemand mehr anfassen möchte, aus Angst, etwas kaputt zu machen. Und genau diese Art von technischer Schuld will Microsoft reduzieren.

Es geht auch um Innovationsgeschwindigkeit. Das Classic-Modell begrenzt, wie konsistent neue Funktionen eingeführt werden können, während die moderne SharePoint-Erfahrung eine sicherere und besser governte Zusammenarbeitsumgebung bietet, eine einfachere Berechtigungsverwaltung über Microsoft-365-Gruppen, eine von Grund auf für mobile Geräte konzipierte Oberfläche und, mit Blick auf die Zukunft, die Grundlage für die neuesten Funktionen rund um künstliche Intelligenz. Wer an Classic-Seiten festhält, riskiert also nicht nur ein Sicherheitsproblem, sondern auch, von dieser Weiterentwicklung ausgeschlossen zu bleiben.

Wer sich bereits mit den Unterschieden zwischen den beiden Erfahrungen beschäftigt hat, weiß das genau, denn der Sprung von SharePoint Classic zu SharePoint Modern betrifft nicht nur die Optik der Seiten, sondern auch die Berechtigungsverwaltung, die native Integration mit Teams und Outlook sowie die Möglichkeit, Workflows mit Power Automate zu automatisieren, alles Bereiche, in denen das Classic-Modell inzwischen an seine Grenzen stößt.

Die 4 von Microsoft empfohlenen Schritte zur Modernisierung von SharePoint Classic

Die offizielle Dokumentation schlägt ein schrittweises Vorgehen vor, das die Migrationsrisiken verringern und den Site-Besitzern Zeit geben soll, modernisierte Seiten zu überprüfen.

1. Die bestehende Classic-Umgebung erfassen und bewerten

Der erste und wahrscheinlich wichtigste Schritt besteht darin, zu verstehen, wie viele Classic-Sites und -Seiten im Tenant noch aktiv sind. Microsoft stellt dafür die Microsoft-Purview-Überwachungsereignisse in der Kategorie für Classic-Aktivitäten bereit, die das Erstellen, Bearbeiten und Anzeigen von Classic-Seiten umfassen, sowie das Microsoft 365 Assessment Tool, das speziell dafür konzipiert ist, Seiten, Webparts und Anpassungsmuster zu identifizieren, die in der Umgebung noch vorhanden sind. Die Ausgabe dieses Tools enthält ein detailliertes Inventar für jede gefundene Seite, mit einer Einschätzung, wie aufwendig die Umwandlung in die moderne Erfahrung wäre.

Stellt die Bewertung fest, dass es keine Classic-Publishingsites, nutzererstellten Seiten oder von den neuen Regeln betroffenen Skripte gibt, ist keine weitere Maßnahme erforderlich. Dieses Ergebnis ist jedoch weniger selbstverständlich, als es klingt, denn manche Unternehmen, die glaubten, bereits vollständig modern zu sein, haben nach einer gründlichen Prüfung festgestellt, dass sie noch Dutzende oder Hunderte vergessener Classic-Seiten in Nebensites hatten, oft Jahre zuvor von Teams erstellt, die inzwischen gewechselt haben.

2. Nach geschäftlicher Bedeutung priorisieren

Es lohnt sich, mit den am häufigsten genutzten Seiten zu beginnen, die am häufigsten aktualisiert werden oder für das Geschäft am relevantesten sind, und sie nach Komplexität und Art des nötigen Eingriffs zu gruppieren, damit die in den ersten Phasen gewonnenen Erkenntnisse in den folgenden wiederverwendet werden können. Eine News-Seite, die täglich von Hunderten von Personen besucht wird, verdient eine andere Behandlung als eine statische Seite, die seit Jahren niemand mehr öffnet.

3. Seiten in die moderne Erfahrung umwandeln

Für die eigentliche Umwandlung verweist Microsoft auf den offiziellen Modernisierungsleitfaden und auf PnP PowerShell als Werkzeug für die deterministische Konvertierung von Seiten mit einem wiederkehrenden Muster. Für komplexere Szenarien mit benutzerdefiniertem HTML oder Script-Editor-Inhalten, die menschliches Urteilsvermögen erfordern, weist Microsoft außerdem auf den SharePoint Page Migration Agent hin, ein derzeit in der Vorschau befindliches Open-Source-Projekt. Es lohnt sich, daran zu erinnern, dass Open-Source- und Vorschau-Tools keine SLA-Abdeckung durch den Microsoft-Support haben und dass die am stärksten angepassten Seiten dennoch eine manuelle Überprüfung oder einen manuellen Neuaufbau erfordern können.

4. In Wellen vorgehen

Die abschließende Empfehlung lautet, zentrale Planung mit der Ausführung durch die einzelnen Site-Besitzer zu kombinieren und aufeinanderfolgende Gruppen von Seiten zu modernisieren, statt alles auf einmal zu tun. Dieser wellenartige Ansatz ermöglicht es, Inhalte, Links, Berechtigungen, Webparts und Layout an einer begrenzten Anzahl von Seiten zu validieren, bevor der Einsatz auf den Rest des Tenants ausgeweitet wird. So sinkt das Risiko, denselben Fehler auf Hunderten verschiedener Seiten korrigieren zu müssen.

Ein Thema, das vor allem größere, stärker gewachsene Tenants betrifft

Organisationen, die ihr Intranet über die Jahre auf lokalem SharePoint Server aufgebaut und später zu SharePoint Online migriert haben, haben tendenziell eine höhere Zahl noch aktiver Classic-Sites, -Seiten und -Anpassungen, oft ohne dass die IT-Abteilung eine vollständige und aktuelle Übersicht darüber hat. Das ist ein wiederkehrendes Muster, denn jeder Verantwortungswechsel zwischen unterschiedlichen Teams, jeder externe Anbieter, der zu einem bestimmten Zeitpunkt am Tenant gearbeitet hat, und jede Unternehmensreorganisation hinterlässt irgendeine Site, die niemand mehr aktiv betreut, die aber weiterhin existiert und erreichbar ist.

Je größer und je stärker über die Zeit gewachsen ein Tenant ist, desto mehr Aufmerksamkeit erfordert die Bestandsaufnahme, da Seiten und Anpassungen auf verschiedene Sites verteilt und von unterschiedlichen Teams verwaltet sein können, mit sehr uneinheitlichem Dokumentationsniveau. Die beiden von Microsoft festgelegten Fristen, März 2027 und Oktober 2028, bieten ein nützliches Zeitfenster, um das Thema geordnet anzugehen, aber gerade die anfängliche Analysephase, die zeigt, wie viele Classic-Seiten tatsächlich noch im Einsatz sind und mit welchem Komplexitätsgrad, erfordert die sorgfältigste Planung, denn in diesem Moment wird der tatsächliche Umfang der Arbeit sichtbar, noch bevor überhaupt mit der Modernisierung begonnen wird.

Wo Sie anfangen sollten, wenn Sie noch keinen klaren Überblick haben

Für mittelgroße bis große Unternehmen, etwa ab 300 Nutzern, besteht die erste Hürde fast immer darin, herauszufinden, ob das Thema das eigene Unternehmen überhaupt betrifft, mehr als eine rein technische Frage. Ein guter Ausgangspunkt ist es, sich selbst oder die eigene IT-Abteilung drei einfache Fragen beantworten zu lassen.

1. Hat das Unternehmen in der Vergangenheit SharePoint Server oder lokales SharePoint genutzt?
2. Wurde eine Migration zu SharePoint Online durchgeführt?
3. Ist mit Sicherheit bekannt, ob im Tenant noch Classic-Seiten, -Sites oder -Anpassungen vorhanden sind?

Ist die Antwort auf die dritte Frage unsicher, lohnt es sich, den IT-Ansprechpartner direkt für eine gezielte Prüfung einzubeziehen, statt bei einem vorläufigen Eindruck stehen zu bleiben. Häufiger als man denkt stellen Unternehmen, die überzeugt waren, nichts Classic mehr zu haben, nach einer genaueren Prüfung fest, dass über 120 Seiten noch aktiv und in Nebensites vergessen sind. Eine frühzeitige, auch nur qualitative Prüfung ermöglicht es, mit Vorlauf zu planen, statt den tatsächlichen Umfang der Arbeit erst kurz vor den Fristen zu entdecken.