Zum Hauptinhalt springen
S-EDV news
← Alle News
Windows & Microsoft 365 14.09.2026 · 8 min Lesezeit

SharePoint Online: Microsoft schaltet klassische Seiten 2027 und 2028 ab

Microsoft beendet die klassischen Erfahrungen in SharePoint Online in zwei Stufen. Ab 1. März 2027 lassen sich keine klassischen Veröffentlichungswebsites mehr anlegen, ab 1. Oktober 2028 werden klassische Seiten in allen Mandanten schreibgeschützt und Custom Scripts abgeschaltet. Gelöscht wird nichts, aber alte Intranets, Wiki-Bibliotheken und selbstgebaute ASPX-Seiten brauchen bis dahin einen Migrationspfad.

Abstrakte Darstellung verblassender klassischer Seitenkacheln neben modernen Kacheln mit Zeitachse und der Schlagzeile Klassisches SharePoint läuft aus KI-generiert

Wer heute wissen will, ob im eigenen Microsoft-365-Mandanten noch klassische SharePoint-Seiten liegen, braucht dafür eine knappe Stunde. Wer die Frage erst 2027 stellt, plant die Ablösung eines gewachsenen Intranets unter Termindruck. Microsoft hat am 31. August 2026 im SharePoint-Blog einen Zeitplan veröffentlicht, der die klassischen Erfahrungen in SharePoint Online in zwei Stufen beendet: ab 1. März 2027 fällt die Neuanlage klassischer Veröffentlichungswebsites weg, ab 1. Oktober 2028 werden klassische Seiten in allen Mandanten schreibgeschützt. Der Vorlauf ist ungewöhnlich lang, genau deshalb lohnt sich die Bestandsaufnahme jetzt und nicht in eineinhalb Jahren.

Wichtig vorweg, weil es die häufigste Rückfrage ist: Microsoft löscht in keiner der beiden Stufen Inhalte oder Daten. Vorhandene klassische Seiten bleiben erreichbar, am Ende in schreibgeschützter Form. Es handelt sich also nicht um einen Datenverlust, sondern um das Ende der Bearbeitbarkeit und der Erweiterbarkeit per Custom Script.

Was ändert sich wann?

Microsoft teilt den Ausstieg in zwei klar datierte Phasen. Die erste trifft zunächst nur die Neuanlage, die zweite dann den laufenden Betrieb in allen Mandanten.

Stufe 1, ab 1. März 2027, gilt für alle Mandanten:

  • Das Anlegen neuer klassischer Veröffentlichungswebsites wird deaktiviert, ebenso das Aktivieren der klassischen Veröffentlichungsfunktion für Websitesammlungen und Unterwebsites.
  • Die Mandanteneinstellung AllowClassicPublishingSiteCreation wird zwingend auf False gesetzt und lässt sich nicht mehr ändern.

Für Mandanten, die am oder nach dem 1. März 2027 neu erstellt werden, kommt zusätzlich dazu:

  • Benutzer können keine neuen klassischen Seiten mehr erstellen. Das umfasst Wiki-Seiten, Webpart-Seiten, Blog-Seiten, Veröffentlichungsseiten und benutzerdefinierte ASPX-Seiten.
  • Das Hinzufügen oder Aktualisieren benutzerdefinierter Skripte ist standardmäßig deaktiviert. Die Websiteeinstellung DenyAddAndCustomizePages wird auf True erzwungen und ist nicht mehr änderbar.
  • Diese Einschränkung gilt ausdrücklich nur für klassische Seiten. Moderne SharePoint-Seiten sind nicht betroffen, und Lösungen auf Basis des SharePoint Framework laufen unter der bestehenden Governance weiter.

Stufe 2, ab 1. Oktober 2028, weitet die Einschränkungen auf alle Mandanten aus:

  • Von Benutzern erstellte klassische Seiten werden schreibgeschützt. Wiki-Seiten, Webpart-Seiten, Blog-Seiten, Veröffentlichungsseiten und eigene ASPX-Seiten lassen sich dann weder neu anlegen noch bearbeiten.
  • Das Hinzufügen und Aktualisieren benutzerdefinierter Skripte wird abgeschaltet, DenyAddAndCustomizePages steht dauerhaft auf True.

Microsoft hat die Ankündigung zusätzlich über zwei Message-Center-Einträge im Microsoft-365-Admin-Center an alle Mandanten verteilt (MC1464926 und MC1464924). Wer das Message Center regelmäßig auswertet, findet die Meldung dort im eigenen Bestand wieder.

Warum Microsoft das macht

Die Begründung ist bemerkenswert offen. Microsoft verweist darauf, dass das moderne SharePoint samt SharePoint Framework 2016 eingeführt wurde und die damals in klassisch umbenannten Vorgängerfunktionen vor allem den Umstieg von lokalen Installationen in die Cloud erleichtern sollten. Zehn Jahre später nutzen laut Microsoft weniger als fünf Prozent der monatlich aktiven Mandanten diese klassischen Funktionen überhaupt noch.

Der zweite Punkt ist der technisch interessantere: Klassische Seiteninhalte nehmen nach Microsofts Darstellung nicht an den heute üblichen Verfahren zum Sichern, Verwalten und Teilen von Inhalten teil. Und sie sind nicht vollständig in den Inhaltsformaten vertreten, auf denen Microsoft 365 Copilot aufsetzt. Das kann Abdeckung und Genauigkeit von Copilot-Antworten verringern, wenn diese auf klassische Inhalte zurückgreifen. Für Unternehmen, die Copilot einsetzen oder einführen wollen, ist das ein eigenständiger Migrationsgrund, unabhängig von den Fristen.

Für wen ist das relevant?

Betroffen sind Mandanten mit gewachsenen SharePoint-Online-Umgebungen, in denen noch klassische Strukturen leben. Typische Altlasten aus der Praxis:

  • Intranets, die aus SharePoint 2013 oder 2016 nach SharePoint Online migriert wurden und die klassische Veröffentlichungsfunktion weiterverwenden.
  • Wiki-Bibliotheken, die als Dokumentations- oder Wissensablage dienen, oft ohne aktive Pflege, aber mit realem Nutzwert.
  • Blog-Sites, die früher als Unternehmensnews genutzt wurden und nie abgelöst wurden.
  • Klassische Veröffentlichungsportale mit Seitenlayouts, Masterpages und eigenen Branding-Anpassungen.
  • Selbstgebaute ASPX-Seiten mit eingebettetem JavaScript, etwa für Dashboards, Formulare oder Navigationshilfen.
  • Anpassungen und Formulare, die per Custom Script umgesetzt wurden, häufig durch einen früheren Dienstleister und ohne aktuelle Dokumentation.

Ebenso wichtig ist die Gegenprobe, wer nicht betroffen ist. Mandanten, die ausschließlich moderne Kommunikations- und Teamwebsites sowie Teams-verbundene Websites nutzen, müssen nichts tun. Lösungen auf Basis des SharePoint Framework bleiben ebenfalls unberührt. Und die Ankündigung betrifft SharePoint Online in Microsoft 365, nicht SharePoint Server On-Premises. Wer eine lokale Farm betreibt, ist von diesen Terminen nicht erfasst, sollte den Lebenszyklus seiner Serverversion aber ohnehin getrennt planen.

Wie dringend ist das?

Das ist kein Sicherheitsereignis. Es gibt keine Schwachstelle, keinen Patch, kein Zeitfenster in Tagen. Die Dringlichkeit ergibt sich allein aus dem Aufwand der Ablösung, und der wird regelmäßig unterschätzt. Microsoft formuliert selbst, dass die Modernisierungswerkzeuge komplexe Szenarien nicht vollständig automatisieren und stark angepasste Seiten häufig neu entworfen oder manuell nachgebaut werden müssen.

Realistisch heißt das: Die Inventur ist eine Sache von Stunden, die Migration eines gewachsenen Intranets eine Sache von Monaten. Wer die Bestandsaufnahme in den nächsten Wochen erledigt, weiß bis Jahresende, ob überhaupt Handlungsbedarf besteht, und kann die Umsetzung ins normale Projektgeschäft 2027 einplanen. Wer wartet, verhandelt Budget und Ressourcen unter einer festen Frist. Ergibt die Bewertung, dass kein klassischer Inhalt vorhanden ist, gilt die gesamte Ankündigung für das Unternehmen schlicht nicht.

Was sollten Admins jetzt tun?

Die sinnvolle Reihenfolge ist Inventar, Bewertung, Priorisierung, Migration. Konkret:

  • Bestand erfassen. Mit der SharePoint Online Management Shell alle Websitesammlungen auflisten und die Eigenschaft DenyAddAndCustomizePages auswerten. Get-SPOSite -Limit All liefert die Übersicht, pro Website zeigt Get-SPOSite -Identity <URL> -Detailed den aktuellen Wert. Websites mit False erlauben Custom Scripts und gehören auf die Prüfliste.
  • Mandanteneinstellung prüfen. Über Get-SPOTenant den aktuellen Wert von AllowClassicPublishingSiteCreation ablesen. Steht er bereits auf False, ändert Stufe 1 für die Neuanlage nichts mehr.
  • Klassische Seitenbibliotheken suchen. Wiki-Bibliotheken, Seitenbibliotheken mit ASPX-Dateien und Veröffentlichungsseiten aufspüren. Hinweise geben auch die Berichte im SharePoint Admin Center sowie Websitevorlagen, die auf Veröffentlichungsfunktionen hindeuten.
  • Nutzung messen statt raten. Microsoft nennt die Purview-Audit-Kategorie "SharePoint Classic Activities" mit den Ereignissen ClassicPageCreated, ClassicPageEdited und ClassicPageViewed. Damit lässt sich unterscheiden, was tatsächlich benutzt wird und was nur noch als Karteileiche existiert. Die Kategorie ist laut Microsoft in Audit (Standard) enthalten und für alle Organisationen verfügbar.
  • Umfang bewerten. Das Microsoft 365 Assessment Tool liefert eine Gesamtsicht auf den klassischen Bestand und auf die Machbarkeit der Modernisierung.
  • Nach Geschäftsrelevanz priorisieren. Zuerst die Seiten angehen, die häufig aktualisiert werden oder geschäftskritische Informationen tragen. Wenig genutzte Altbestände lassen sich oft archivieren statt migrieren.
  • Message Center im Blick behalten. Die Einträge MC1464926 und MC1464924 sind der offizielle Kanal für Änderungen an diesem Zeitplan.

Wie der Migrationspfad aussieht

Für die drei typischen Altlasten gibt es jeweils ein modernes Gegenstück, und die Umstellung ist selten ein reiner Kopiervorgang.

  • Klassische Veröffentlichungsportale und Intranets werden zu modernen Kommunikationswebsites. Navigation, Branding und Seitenstruktur werden dabei neu gedacht, Seitenlayouts und Masterpages haben in der modernen Welt keine direkte Entsprechung.
  • Eingebettetes JavaScript auf ASPX-Seiten wird durch Erweiterungen auf Basis des SharePoint Framework ersetzt. Das ist der von Microsoft unterstützte Weg für eigene Funktionalität und bleibt von den Änderungen ausgenommen.
  • Per Custom Script realisierte Formulare und Anpassungen lassen sich meist mit Power Apps und Power Automate abbilden, oft mit weniger eigenem Code als vorher.

Microsoft verweist für die Seitenumwandlung auf Werkzeuge wie die SharePoint PnP Modernization und den SharePoint Page Modernization Agent. Beide arbeiten mit bestmöglicher Erhaltung der Inhalte, nicht mit Garantie auf identisches Ergebnis. Empfohlen wird ein wellenweises Vorgehen: zentrale Planung und Priorisierung durch die IT, Umsetzung verteilt über die Websitebesitzer, statt einer einzigen großen Migration.

Einordnung für Unternehmen

Für kleine und mittlere Unternehmen ist die Meldung vor allem ein Anlass, den eigenen SharePoint-Bestand einmal ehrlich anzusehen. In vielen Mandanten liegt noch Material aus der Zeit der ersten Cloud-Migration, das niemand mehr pflegt, das aber verlinkt ist und weiterhin aufgerufen wird. Die Fristen 2027 und 2028 zwingen zu genau der Aufräumarbeit, die ohnehin überfällig ist.

Zwei Punkte sprechen dafür, das Thema nicht bis 2027 liegen zu lassen. Erstens der Copilot-Bezug: Wer Microsoft 365 Copilot bereits nutzt oder einführt, bekommt aus klassischen Inhalten schlechtere Ergebnisse, unabhängig von jeder Frist. Zweitens die Aufwandsverteilung. Die Inventur kostet wenig und schafft Klarheit. Stellt sich heraus, dass nichts Klassisches vorhanden ist, ist das Thema mit einer kurzen Notiz erledigt. Stellt sich das Gegenteil heraus, bleiben gut 18 Monate bis zur ersten und über zwei Jahre bis zur zweiten Stufe, um die Ablösung geordnet zu planen, zu budgetieren und in Wellen umzusetzen.

Wer mit einem externen Dienstleister arbeitet, sollte die Bestandsaufnahme als eigenen kleinen Auftrag vergeben und sich das Ergebnis schriftlich geben lassen. Das ist die Grundlage für jede spätere Aufwandsschätzung und verhindert, dass 2027 überraschend ein größeres Projekt auf dem Tisch liegt.

Passende Anleitungen auf S-EDV

Quellen

SharePoint OnlineMicrosoft 365Classic PagesCustom ScriptsMigrationCopilot