SharePoint Add-Ins sind seit dem 2. April 2026 tot — was du jetzt tun musst
Am 2. April 2026 hat Microsoft einen langen Abkündigungsprozess abgeschlossen: SharePoint Add-Ins funktionieren nicht mehr. In keinem Tenant. Keine Ausnahmen.
Wer Add-Ins im Einsatz hat, hat gerade defekte Prozesse, leere Web Parts oder Drittanbieter-Lösungen, die sich nicht mehr verbinden. Und viele IT-Teams wissen noch nicht einmal genau, ob und wo sie betroffen sind.
Dieser Artikel gibt dir den Überblick — und einen klaren Weg nach vorne.
Was sind SharePoint Add-Ins überhaupt?
SharePoint Add-Ins (früher “Apps for SharePoint”) wurden mit SharePoint 2013 eingeführt. Die Idee: Erweiterungen bereitstellen, ohne Server-seitigen Code direkt in SharePoint laufen zu lassen — sicherer, isolierter, einfacher zu deployen.
Es gibt zwei Grundtypen:
SharePoint-hosted Add-Ins laufen direkt innerhalb von SharePoint in einem isolierten “App Web”. Sie zeigen Web Parts und bringen eigene Listen oder Libraries mit. JavaScript übernimmt die Business-Logik, der eingeloggte User authentifiziert direkt.
Provider-hosted Add-Ins laufen auf externen Servern (z.B. Azure) und verbinden sich via Azure ACS (Access Control Services) zurück zu SharePoint. Sie haben oft eine eigene UI und komplexere Logik.
Beide sind seit 02.04.2026 retired — und Azure ACS wurde parallel eingestellt.
Was genau ist passiert?
Der Retirement-Prozess lief stufenweise:
| Datum | Was passiert ist |
|---|---|
| 01.03.2024 | Microsoft akzeptiert keine neuen Add-Ins mehr im Public Marketplace |
| 01.07.2024 | Add-Ins können nicht mehr aus dem Marketplace installiert werden |
| 01.11.2024 | Add-Ins funktionieren nicht mehr für neue Tenants |
| 02.04.2026 | Vollständige Abschaltung — alle Tenants, alle Add-In-Typen |
Das gilt für alle Umgebungen: Commercial, Government Cloud, Department of Defense.
Wer ist betroffen?
Das ist die entscheidende Frage — und die Antwort ist oft unbequem.
Viele Organisationen haben Add-Ins im Einsatz, die vor Jahren installiert wurden: Drittanbieter-Tools für Aufgabenverwaltung, Formulare, Dashboards, Dokumenten-Workflows. Oft weiß die aktuelle IT-Generation gar nicht mehr, dass diese Lösungen auf dem Add-In-Modell basieren.
Was jetzt nicht mehr funktioniert:
- Add-In Web Parts laden nicht mehr
- Provider-hosted Add-Ins verlieren ihre Authentifizierung (Azure ACS ist weg)
- Remote Event Receivers, die via ACS gefeuert haben, sind stumm
- Beim Deinstallieren eines SharePoint-hosted Add-In: Das App Web wird gelöscht — alle darin gespeicherten Daten sind weg
Was NICHT betroffen ist:
- SharePoint Framework (SPFx) — bleibt die primäre Zukunftstechnologie
- Standard-SharePoint-Funktionalität
- Power Automate Flows
- Power Apps
Schritt 1: Bestandsaufnahme mit dem M365 Assessment Tool
Bevor du migrierst, musst du wissen was du hast.
Microsoft stellt das Microsoft 365 Assessment Tool kostenlos zur Verfügung. Es scannt deinen Tenant nach Add-In-Nutzung und liefert einen detaillierten Report — welche Add-Ins wo installiert sind, ob es sich um SharePoint-hosted oder provider-hosted handelt, und welche Sites betroffen sind.
Dokumentation: https://aka.ms/m365assessmenttoolOhne diese Bestandsaufnahme startest du blind. Tu das nicht.
Schritt 2: Migrationsweg bestimmen
Je nach Add-In-Typ gibt es unterschiedliche Migrationspfade:
SharePoint-hosted Add-Ins → SPFx Web Parts
SharePoint-hosted Add-Ins lassen sich in der Regel sauber zu SPFx Web Parts migrieren. SPFx ist der offizielle Nachfolger: läuft im Browser, nutzt den User-Kontext für Auth, und ist vollständig in das moderne SharePoint integriert.
Typische Schritte:
- Add-In-Logik analysieren (welche Listen, welche Business-Logik?)
- SPFx-Projekt aufsetzen
- Business-Logik migrieren (oft: TypeScript + React)
- Web Part deployen via Tenant App Catalog
- Altes Add-In deinstallieren (ACHTUNG: App Web-Daten zuerst sichern!)
Provider-hosted Add-Ins → SPFx + Azure + Microsoft Entra ID
Provider-hosted Add-Ins sind komplexer, weil sie externe Server und Azure ACS genutzt haben. ACS ist ebenfalls retired.
Der neue Ansatz:
- Externe Anwendung bleibt auf Azure (oder einem anderen Hosting-Dienst)
- Auth-Modell: Microsoft Entra ID (App-only Authentication) statt Azure ACS
- SharePoint-Integration: SPFx als UI-Schicht, die die externe App aufruft
- Optional: Als Teams-Anwendung verpacken
Drittanbieter-Add-Ins → Vendor kontaktieren
Wenn du ein Drittanbieter-Tool nutzt, das auf dem Add-In-Modell basiert: Kontaktiere den Hersteller. Die meisten seriösen Anbieter haben bereits SPFx-basierte Versionen im AppSource Marketplace.
Was du JETZT tun solltest
- M365 Assessment Tool ausführen — Bestandsaufnahme deines Tenants
- Add-In-Liste priorisieren — Welche Add-Ins werden aktiv genutzt? Welche sind Altlasten?
- Drittanbieter kontaktieren — Updates/Nachfolger anfragen
- Migrationsprojekt aufsetzen — Timeline, Ressourcen, Test-Umgebung
- Datensicherung — Vor der Deinstallation: Alle App-Web-Daten exportieren
Wie wir helfen können
Die Migration von SharePoint Add-Ins zu SPFx ist kein Hexenwerk — aber sie braucht Erfahrung mit beiden Welten.
Bei Walther IT Consulting begleiten wir dich von der Ist-Analyse bis zum Go-Live:
- Bestandsaufnahme: Wir führen das M365 Assessment Tool aus und analysieren deinen Tenant
- Bewertung: Welche Add-Ins sind kritisch, welche können abgeschaltet werden?
- Umsetzung: Migration zu SPFx Web Parts oder SPFx + Entra ID Architektur
- Vendor-Koordination: Wir sprechen mit deinen Drittanbietern und evaluieren Alternativen
Du willst wissen wie groß dein Aufwand ist? Dann buche ein kostenloses Erstgespräch — wir schauen uns deinen Tenant gemeinsam an.
Fazit
SharePoint Add-Ins sind Geschichte. Wer noch darauf läuft, hat handlungsbedarf — jetzt, nicht irgendwann. Die gute Nachricht: SPFx ist ein reifer, gut dokumentierter Nachfolger, und Microsoft hat umfangreiche Migrations-Ressourcen bereitgestellt.
Die wichtigste erste Handlung: Bestandsaufnahme. Nur wer weiß was er hat, kann sinnvoll migrieren.
Quellen: Microsoft TechCommunity — SharePoint Add-In retirement | Migration Guidance | MC693865 (Microsoft 365 Message Center). Recherchiert am 15.04.2026.