Klassische SharePoint-Seiten sind ab Oktober 2028 schreibgeschützt. Was das bedeutet und wie Sie sich vorbereiten

In unserem Septemberüberblick war es eine einzige Zeile in der Fristentabelle: 1. 10. 2028 – klassische SharePoint-Seiten werden schreibgeschützt. Das wirkt fern und unscheinbar. Klassische Seiten sind aber kein Randthema. Es gibt sie in Intranets, die vor 2017 entstanden sind, in Teamwebsites aus der alten Vorlage, in Wikis mit Unternehmensabläufen, in aus SharePoint Server migrierten Websites und in Seiten, die jemand einmal in SharePoint Designer „verbessert“ hat. Microsoft gibt in seiner Ankündigung zwar an, dass weniger als 5 % der aktiven Mandanten klassische Funktionen noch nutzen – in Unternehmen, die SharePoint seit fünfzehn Jahren betreiben, sind sie aber eher die Regel als die Ausnahme.

Dieser Artikel fasst zusammen, was Microsoft genau angekündigt hat (MC1464926, 31. August 2026), wen es betrifft und wie Sie sich vorbereiten, damit die Frist nicht zum Problem wird.

Was sich ändert, in zwei Phasen

Phase 1 – ab 1. März 2027

Für alle Mandanten:

• Klassische Veröffentlichungswebsites (Publishing) lassen sich nicht mehr anlegen – weder als Websitesammlungen noch als Unterwebsites.
• Das Veröffentlichungsfeature lässt sich auf bestehenden Websites nicht mehr aktivieren.
• Die Mandanteneinstellung AllowClassicPublishingSiteCreation wird fest deaktiviert.

Zusätzlich für Mandanten, die ab dem 1. März 2027 angelegt werden:

• Neue klassische Seiten lassen sich nicht erstellen.
• Benutzerdefinierte Skripts sind deaktiviert und lassen sich nicht aktivieren (DenyAddAndCustomizePages wird erzwungen).

Phase 2 – ab 1. Oktober 2028

Dasselbe gilt dann für alle übrigen Mandanten:

• Von Benutzern erstellte klassische Seiten werden schreibgeschützt. Sie lassen sich öffnen und lesen, aber nicht bearbeiten. Neue klassische Seiten lassen sich nicht erstellen.
• Benutzerdefinierte Skripts sind in allen Mandanten deaktiviert, und eine Ausnahme lässt sich nicht mehr einrichten, auch nicht vorübergehend.

Wichtig: Inhalte werden weder gelöscht noch verändert. Die Seiten bleiben lesbar. Sie erstarren nur – und mit ihnen alles, was dort bisher von Hand gepflegt wurde.

Welche Seiten betroffen sind

Microsoft nennt fünf Arten „von Benutzern erstellter klassischer Seiten“:

Typ	Wo Sie ihn typischerweise finden
Wiki-Seiten	Startseiten alter Teamwebsites, Unternehmenswikis mit Abläufen und Anleitungen
Webpartseiten	Abteilungsübersichten, Dashboards aus Listen-Webparts
Blogseiten	Blog-Unterwebsites, die einst für Teamneuigkeiten angelegt wurden
Veröffentlichungsseiten	klassische Intranets mit Seitenlayouts, Enterprise Wiki
Benutzerdefinierte ASPX-Seiten	in SharePoint Designer oder von einer Drittanbieterlösung erstellte Seiten

Was sich nicht ändert:

• Moderne Seiten und die meisten Lösungen auf Basis des SharePoint Framework (SPFx) funktionieren weiter. Ausnahme sind SPFx-Webparts mit requiresCustomScript: true – bei blockierten Skripts verschwinden sie aus der Auswahl und von den Seiten.
• Klassische Listen- und Bibliotheksansichten sowie Listenformulare sind vorerst nicht betroffen. Microsoft schreibt aber ausdrücklich, dass sie „in einem separaten Zeitplan“ folgen könnten. Und darin eingebettete Skripts fallen trotzdem unter die Skriptbeschränkungen.
• Klassische Websites selbst bleiben bestehen. Viele lassen sich an Ort und Stelle modernisieren, ohne Neuaufbau.

Ab März 2027 lässt sich keine Website mehr aus diesen Vorlagen anlegen: Publishing Portal (BLANKINTERNETCONTAINER#0), Publishing Site (CMSPUBLISHING#0), Publishing Site Blank (BLANKINTERNET#0), Enterprise Wiki (ENTERWIKI#0), Enterprise Search Center (SRCHCEN#0), Site Directory (SPSSITES#0), News Home (SPSNHOME#0), Product Catalog (PRODUCTCATALOG#0), Report Center (SPSREPORTCENTER#0) und Topic Area (SPSTOPIC#0). Andere klassische Vorlagen sind nicht betroffen.

Warum das größer ist, als es aussieht

Bei lebenden Inhalten heißt „schreibgeschützt“ dasselbe wie „Ende“. Ein Wiki mit einem Ablauf, der einmal im Quartal aktualisiert wird, oder eine Abteilungsseite mit Kontakten wird nach dem 1. 10. 2028 schlicht nicht mehr gepflegt. Niemand bekommt eine Fehlermeldung, der Inhalt veraltet einfach still. Im Intranet ist das schlimmer als ein Ausfall, weil es niemand bemerkt.

Die Startseite ist oft dort klassisch, wo es niemand erwartet. Teamwebsites aus der alten Vorlage haben als Startseite typischerweise eine Wiki-Seite (nicht angepasste Startseiten hat Microsoft möglicherweise schon automatisch modernisiert, angepasste sind aber klassisch geblieben). In Bibliotheken und Listen wirkt die Website dann modern, ihre Startseite fällt aber unter die Änderung.

Benutzerdefinierte Skripts enden endgültig. Schon heute springt das Zulassen benutzerdefinierter Skripts auf einer Website innerhalb von 24 Stunden auf „nicht zulässig“ zurück. Ab Oktober 2028 entfällt auch diese vorübergehende Freigabe. Laut Microsoft funktionieren vorhandene Skripts weiter, lassen sich aber weder hinzufügen noch bearbeiten. Wer auf seinen Seiten den Script Editor oder Content Editor mit JavaScript nutzt, kann sie nicht mehr reparieren, wenn etwas kaputtgeht.

Die Migration aus SharePoint Server wird schwieriger. Ab März 2027 lässt sich eine klassische Veröffentlichungswebsite nicht mehr „wie sie ist“ übertragen, weil sich eine solche Website in SharePoint Online nicht mehr anlegen lässt. Klassische Seiten lassen sich weiterhin migrieren, sind nach der Frist aber schreibgeschützt, und skriptbasierte Elemente bleiben möglicherweise nicht erhalten. Microsoft empfiehlt, die Modernisierung direkt in die Migration einzuplanen. Darauf weisen auch Anbieter von Migrationswerkzeugen hin – ShareGate etwa schreibt, diese Einschränkung nicht umgehen zu können.

Wie Sie herausfinden, ob es Sie betrifft

Microsoft bietet dafür drei Informationsquellen und eine Entwarnung: Findet Ihre Inventur keine klassischen Veröffentlichungswebsites, keine klassischen Seiten und keine betroffenen Skripts, müssen Sie nichts tun.

1. Überwachung in Microsoft Purview. Die Kategorie SharePoint Classic Activities und die Ereignisse ClassicPageCreated, ClassicPageEdited und ClassicPageViewed zeigen, welche klassischen Seiten tatsächlich erstellt, bearbeitet und gelesen werden.
2. Microsoft 365 Assessment Tool. Das Open-Source-Werkzeug von Microsoft (PnP) durchsucht SharePoint Online und listet klassische Seiten, ihre Webparts und eine Einschätzung auf, wie gut sie sich konvertieren lassen. Die Analyse klassischer Seiten gibt es ab Version 1.15, die Anbindung an Überwachungsdaten (bis zu 180 Tage zurück) ab Version 1.16. Für einen ganzen Mandanten braucht es eine registrierte App mit reinen Leseberechtigungen.
3. Websites mit benutzerdefinierten Skripts. Im SharePoint Admin Center gibt es unter Active sites die Spalte Custom script und die vorbereitete Ansicht Custom script allowed sites.

Entscheidend ist die Kombination aus Inventur und Überwachung. Eine Liste mit zehntausend klassischen Seiten löst für sich genommen nichts. Eine Liste, die sagt, zweihundert davon werden bearbeitet und tausend gelesen, ist bereits ein Plan.

Wie Sie vorgehen

Nicht alles muss konvertiert werden. Eine Seite, die seit zwei Jahren niemand geöffnet hat, braucht keine Modernisierung. Sie kann schreibgeschützt als Archiv bleiben oder gelöscht werden. Konvertieren lohnt sich nur, was bearbeitbar bleiben muss. Entscheiden Sie für jede Gruppe von Seiten einen von drei Wegen: modernisieren, als Archiv behalten, entfernen.

Beginnen Sie mit dem, was lebt und wichtig ist. Microsoft empfiehlt, Seiten nach geschäftlicher Bedeutung und Bearbeitungshäufigkeit zu ordnen. Dann nach Komplexität gruppieren, damit Sie in Wellen konvertieren und das in der ersten Welle Gelernte in den nächsten nutzen können.

Es gibt Werkzeuge, aber sie haben Grenzen:

• Seitentransformation mit PnP PowerShell ist die deterministische Konvertierung, die Microsoft als Hauptweg beschreibt. Ihr Grundablauf deckt allerdings Wiki-Seiten und Webpartseiten in der Bibliothek Websiteseiten (Site Pages) ab. Veröffentlichungsseiten, Blogs, Seiten außerhalb von Site Pages, Startseiten und Quellen aus SharePoint Server erfordern eigene, fortgeschrittenere Verfahren. Die Engine ist Teil der Open-Source-Bibliothek PnP Framework und hat keinen Microsoft-Support mit SLA.
• SharePoint Page Modernization Agent ist ein neuer Open-Source-KI-Agent, der bei komplexeren Seiten hilft – mit eigenem HTML, Script-Editor-Inhalten oder Layouts, die menschliches Urteilsvermögen brauchen. Er ist in der Vorschau und ohne Microsoft-Support, läuft in Werkzeugen wie GitHub Copilot oder Claude Code und verbraucht Token eines Sprachmodells. Die Autoren selbst empfehlen, jede erzeugte Seite mit dem Original zu vergleichen. Script-Editor-Inhalte können am Ende nur als erläuternder Text erscheinen, nicht als funktionierender Ersatz.

Microsoft ergänzt einen Satz, den man ernst nehmen sollte: Stark angepasste Seiten können eine Neugestaltung oder einen manuellen Neuaufbau erfordern. Außerdem kann eine erzeugte Seite existieren und trotzdem leer oder unvollständig sein – „ließ sich ohne Fehler öffnen“ reicht als Prüfung also nicht.

Teilen Sie die Arbeit zwischen IT und Websitebesitzern auf. Zentral planen, die Reihenfolge festlegen und die Werkzeuge vorbereiten. Den Inhalt nach der Konvertierung prüft aber am besten, wer ihn nutzt – der Websitebesitzer oder die Abteilung. Ein Vorgehen in Wellen erlaubt es, Inhalt, Links, Berechtigungen, Webparts und Layout zu prüfen, bevor Sie sich an die nächsten Hunderte Seiten machen.

Ein sinnvoller Zeitplan

Bis Oktober 2028 bleiben knapp zwei Jahre. Das klingt nach viel, ist bei einem Intranet mit Tausenden Seiten, bei dem jede Welle von Fachleuten geprüft werden muss, aber eher knapp bemessen. Ein realistischer Plan:

Wann	Was
bis Ende 2026	Inventur: Assessment Tool + Überwachung, Liste der Websites mit benutzerdefinierten Skripts
bis 1. 3. 2027	über klassische Veröffentlichungswebsites entscheiden; ab diesem Datum lassen sich keine neuen anlegen, und eine Migration aus SharePoint Server muss mit der Modernisierung einhergehen
2027	erste Wellen: die wichtigsten und am häufigsten bearbeiteten Seiten, Ersatz von Skripts durch moderne Webparts oder SPFx
1. Hj. 2028	die übrigen bearbeiteten Seiten, Archivierung oder Entfernung ungenutzter Seiten
1. 10. 2028	klassische Seiten sind schreibgeschützt – bis dahin sollte dort nichts mehr liegen, was geändert werden muss

Das Wichtigste in Kürze

1. Die Inhalte verschwinden nicht, sie erstarren. Ab dem 1. 10. 2028 lässt sich keine klassische Wiki-, Webpart-, Blog-, Veröffentlichungs- oder benutzerdefinierte ASPX-Seite mehr bearbeiten.
2. Veröffentlichungswebsites enden früher. Anlegen und Aktivieren der Veröffentlichung sind schon ab dem 1. 3. 2027 nicht mehr möglich – das betrifft vor allem Migrationen aus SharePoint Server.
3. Finden Sie heraus, wo Sie Klassisches haben. Assessment Tool und Purview-Überwachung liefern zusammen die Liste und die Information, was tatsächlich genutzt wird. Finden sie nichts, müssen Sie nichts tun.
4. Konvertieren Sie nur, was lebendig bleiben muss. Den Rest archivieren oder löschen. Werkzeuge helfen, aber nicht ohne menschliche Prüfung.

---

Die Modernisierung klassischer Websites und Intranets übernehmen wir im Rahmen einer Prüfung der Umgebung und eines Governance-Konzepts – von der Inventur über die Entscheidung, was konvertiert und was archiviert wird, bis zum modernen Ersatz für Seiten mit Skripts. Wenn Ihr SharePoint aus der Zeit vor den modernen Seiten stammt oder Sie eine Migration aus SharePoint Server planen, melden Sie sich bei uns.

Quellen: Microsoft Message Center MC1464926 (31. 8. 2026), Microsoft Learn – Deprecation of Classic SharePoint Pages, Transform classic SharePoint pages to modern pages, Allow or prevent custom scripts, Microsoft 365 Assessment Tool, SharePoint Page Modernization Agent.