SharePoint Embedded: Migration-APIs für App-Szenarien

Consulting Briefing – SharePoint Embedded: Das „Motorraum-SharePoint“ für DMS, Fachanwendungen und Intranet 2.0

Wer SharePoint bisher vor allem als Websites, Bibliotheken und hübsche Kacheln im Browser kennt, muss jetzt kurz umdenken: SharePoint Embedded ist sozusagen der Motorraum von Microsoft 365 – ohne Haube, ohne Felgen, nur der Antriebsstrang. Voll-API, keine Oberfläche, dafür ein hochskalierbares Dokumenten- und Dateisystem direkt im Tenant des Kunden.

Die Idee: Anwendungen – eigene Line-of-Business-Lösungen, Branchensoftware, Portale – nutzen SharePoint Embedded als Storage-Backend, ohne dass der Hersteller eigene Storage-Architektur, Backup, Compliance und Security erfinden muss. Inhalt, Residency und Compliance bleiben im Microsoft 365 Tenant des Kunden, die Anwendung „dockt“ nur an.

Was ist SharePoint Embedded – in 30 Sekunden?

Kurzfassung:

• API-only-DMS: Kein eigenes UI, Zugriff ausschließlich über Microsoft Graph und App-Registrierungen.

• App-Dokumente im Kundentenant: Pro App entsteht eine dedizierte Storage-Partition („App Documents“) im Microsoft 365 Tenant des Kunden, isoliert vom „normalen“ SharePoint.

• Multi-Tenant-Modell: Typisch ist ein „owning tenant“ des Softwareanbieters und viele „consuming tenants“ der Kunden. Die App läuft beim Anbieter, die Daten liegen bei den Kunden.

• Große Skalierung: Millionen Container pro Tenant, je Container bis zu zig Millionen Dokumente – also genug Platz für ernsthafte DMS- und Branchenlösungen.

Damit wird SharePoint Embedded zum Baustein für alles, was Dateien, Versionen, Berechtigungen, Compliance und Suche braucht – ohne klassische SharePoint-Seiten.

Neue Migrations-APIs – Turbo für Inhalte ins Embedded-DMS

Damit das Ganze nicht bei „grünem Feld“ stehen bleibt, gibt es inzwischen dedizierte SharePoint Embedded Migration APIs in Microsoft Graph (aktuell im Preview-Status).

Das Grundprinzip:

1. Staging in Azure Blob
   Die API nutzt von Microsoft gemanagte Azure-Blob-Container als Zwischenspeicher. Dort landen Dateien, Metadaten und ein Manifest mit der Struktur.

2. Migration Job
   Über Graph wird ein Migrationsjob angestoßen, der die Inhalte aus dem Blob-Staging in einen definierten SharePoint-Embedded-Container überführt.

3. Monitoring
   Statusabfragen liefern Fortschritt, Fehler, Durchsatz – ideal für größere Volumen.

4. Aufräumen
   Abschließend werden Staging-Container und alte Jobs bereinigt.

Zielgruppe: ISVs und interne Entwickler, die große Bestände aus Alt-DMS, File-Servern oder Fremdsystemen automatisiert in SharePoint Embedded kippen wollen – inklusive Metadaten, Strukturen und Berechtigungen.

Typische Szenarien: DMS, Branchensoftware, Intranet-Lösungen

Wo lohnt sich der Blick auf SharePoint Embedded konkret?

1. Klassisches DMS / eAkten-System

• Aktenstruktur und Vorgänge liegen in einer Fachanwendung (Web-App, Desktop-Client, mobile App).

• Dokumente, Versionen, Anhänge werden in SharePoint Embedded-Containern gespeichert.

• Vorteile:

  • Tenant-residente Daten, also keine „Schatten-Cloud“ beim Hersteller.

  • Standardfunktionen wie Versionierung, Recycle Bin, eDiscovery, grundsätzliche M365-Compliance.

  • Saubere Trennung von Aktenlogik (App) und Storage/Compliance (Embedded).

2. Branchensoftware (Gesundheitswesen, Fertigung, öffentliche Verwaltung …)

• Branchenlösungen haben oft strenge Compliance- und Residency-Anforderungen.

• SharePoint Embedded erlaubt:

  • Multi-Tenant-Architektur pro Kunde mit Isolation.

  • Nutzung vorhandener Security-, DLP- und Compliance-Richtlinien im Kundentenant.

  • Integration von KI-Funktionen (Copilot, semantische Suche), ohne Daten herauszuschieben.

Gerade Anbieter, die bisher einen eigenen Blob-Speicher oder S3-Bucket mit selbstgebauter Berechtigungslogik nutzen, können so massiv aufräumen.

3. Intranet 2.0 und Portallösungen

• Moderne Intranets oder Kundenportale werden zunehmend als Headless-/SPA-Anwendungen gebaut.

• SharePoint Embedded kann:

  • Alle Dokumentbereiche (Richtlinien, Vorlagen, Projektdokumente) als Container bereitstellen.

  • Im Frontend wird nur noch der eigene, hübsch designte React-/Angular-/Blazor-Client angezeigt.

• Spannend: Kombination mit klassischem SharePoint Online – z. B. für News, Navigation, People – und Embedded als reines „File Backend“ für besonders regulierte oder mandantenfähige Teile.

Architekturfragen: Tenant-Isolation, Storage und Berechtigungen

Jetzt wird es architektonisch – dort, wo Projekte später stehen oder fallen.

Tenant-Isolation

• Typisch ist ein Provider-Tenant (Anbieter) und viele Consumer-Tenants (Kunden).

• Die App-Registrierung und Steuerlogik liegt beim Anbieter, die Container und Dateien im Kundentenant.

• Zugriff funktioniert über Graph-Berechtigungen, für die der Kundentenant-Admin explizit Consent erteilt über seine Daten, Richtlinien und Logs.

Storage-Design

Fragen, die man früh klären sollte:

• Container-Schnitt
  Container pro Kunde? Pro Fachbereich? Pro Geschäftsvorfall?
  Üblich ist:

  • Container pro Kunde (bei ISV-Szenario)

  • Bei großen Organisationen: Container per Business-Unit oder fachlicher Domäne.

• Region und Residency
  Region folgt dem jeweiligen Tenant des Kunden – wichtig für rechtliche Anforderungen.

• Skalierung und Limits
  Millionen Container, je Container zig Millionen Dokumente – klingt viel, aber bei großen Archiven müssen Namenskonventionen, Archivtakt und Lifecycle mitgedacht werden.

Berechtigungen und Sicherheit

• Zugriff erfolgt über App-Identitäten und Container-Berechtigungen, nicht über klassische SharePoint-Gruppen mit Frontend-UI.

• Pro Container lassen sich Berechtigungen auf Basis von:

  • Benutzer- und Gruppenzuordnung aus Entra ID,

  • dem Anwendungskontext (z. B. Kundenmandant, Rolle im Fachsystem),

  • und optional über anspruchsbasierte Logik steuern.

• Wichtig:

  • Klare Autorisierungsschicht in der Anwendung (Claims, Rollen, Mandant).

  • Logging und Audit in M365 nutzen, damit Security und Compliance nicht im Blindflug arbeiten.

Empfehlungen für einen pragmatischen Proof-of-Concept (PoC)

Gerade größere Organisationen sollten das Thema nicht direkt mit dem größten Fachverfahren testen. Ein pragmatischer PoC könnte so aussehen:

1. Use Case clever wählen

• Begrenzter, aber realistischer Anwendungsfall, z. B.:

  • Eine Fachabteilung mit klaren Dokumenttypen (Verträge, Projektakten, Patientenbriefe, Wartungsunterlagen).

  • Volumen im PoC: 5.000–50.000 Dokumente.

• Zielbild:

  • Ein kleiner Ausschnitt der Realität, aber mit echten Datenstrukturen und echten Workflows.

2. Architektur minimal, aber sauber schneiden

• Festlegen:

  • Welcher Tenant ist Provider, welcher Consumer?

  • Wie sieht die Container-Struktur aus?
    Beispiel: 1 Container für „Pilot-Fachbereich“, innerhalb davon logische Ordner/Akten.

• App-Registrierung in Entra ID, notwendige Graph-Berechtigungen, Consent-Prozess definieren.

• Von Anfang an mitdenken:

  • Namenskonventionen für Container und Akten-IDs,

  • spätere Mandantentrennung (falls aus Pilot ein übergreifender Service wird).

3. Migration im Kleinformat testen

• Mit der Embedded-Migrations-API ein repräsentatives Datenpaket aus einem Altsystem oder Fileshare einspielen:

  • Verschiedene Dokumenttypen,

  • unterschiedliche Metadaten,

  • Berechtigungsvarianten (z. B. vertraulich vs. allgemein zugänglich).

• Erfolgsmetriken:

  • Durchsatz (Dokumente pro Stunde),

  • Fehlerquote,

  • Vollständigkeit von Metadaten und Berechtigungen.

4. Fachliches Frontend – so einfach wie möglich

• Für den PoC reicht oft:

  • Eine schlanke Web-App mit:

    • Login über Entra ID,

    • Liste der Akten,

    • Dokumentenansicht,

    • einfache Suchfunktionen.

• Wichtig:

  • Fachbereich soll nicht „SharePoint“ sehen, sondern seine Anwendung, die zufällig auf einem sehr robusten DMS-Backend steht.

5. Governance, Compliance, Betrieb

Parallel zum technischen PoC:

• Richtlinien testen:

  • Retention,

  • Sensitivity Labels,

  • DLP-Regeln, die auf Embedded-Container wirken.

• Betriebsfragen klären:

  • Wer überwacht Metriken und Logs?

  • Wie erfolgt Incident-Handling, wenn Berechtigungen falsch gesetzt sind?

  • Welche Rollen in IT und Fachbereich sind beteiligt?

Fazit: Embedded ist SharePoint ohne Ballast – aber nichts für Bastelbuden

SharePoint Embedded ist spannend für alle, die professionelle Anwendungen bauen oder einkaufen, bei denen Dokumente eine zentrale Rolle spielen – ohne sich um das ganze Storage- und Compliance-Geraffel selbst kümmern zu wollen.

Die neuen Migrations-APIs machen ernsthafte Projekte möglich: große Datenmengen, automatisiert, nachvollziehbar. Dazu kommen klare Architekturmodelle für Tenant-Isolation, skalierbarer Storage und ein Berechtigungskonzept, das sauber mit Entra ID zusammenspielt.

Die Kehrseite: Wer Embedded nutzt, baut im Prinzip ein eigenes DMS- oder Fachverfahren auf Enterprise-Niveau. Ohne ordentliches Architektur- und Governance-Design wird das schnell zur Dokumenten-Variante von Spaghetti-Code.

Der clevere Weg: einen fokussierten PoC aufsetzen, mit einem klar abgegrenzten Fachbereich, echten Dokumenten, Embedded-Migration im Kleinen – und danach entscheiden, ob dieses Motorraum-SharePoint die Basis für das nächste große DMS-, Branchen- oder Intranet-Projekt wird.