Filesystem zu SharePoint migrieren: Ordner, Metadaten oder Hybrid?

Ein Fileserver ist meistens ehrlicher als jede Prozessdokumentation.

Man sieht sofort, wie ein Unternehmen wirklich arbeitet: Kundenordner, Projektordner, Jahresordner, „Alt“, „Archiv“, „_neu“, „final“, „final_final“ und irgendwo ein Ordner, den niemand löschen will, weil „da bestimmt noch was Wichtiges drin ist“.

Wenn diese Struktur nach SharePoint migriert wird, kommt schnell die Standardfrage:

Sollen wir die Ordnerstruktur behalten — oder alles flach mit Metadaten organisieren?

Nach meinem Gespräch mit Michael Greth über SharePoint, Copilot in SharePoint und Migrationserfahrung aus der Praxis ist meine Antwort ziemlich klar:

Die Frage ist falsch gestellt.

Nicht „Ordner oder Metadaten?“ ist entscheidend, sondern:

Wie arbeiten die Menschen tatsächlich — und welche Struktur braucht Copilot später, um brauchbare Antworten zu liefern?

Ordner sind nicht böse. Metadaten sind kein Selbstzweck. Schlecht wird es erst, wenn man ein altes Filesystem 1:1 nach SharePoint kippt und anschließend erwartet, dass Suche, Views, Governance und Copilot daraus automatisch Wissensmanagement machen.

Das passiert nicht.

Warum Ordner überhaupt noch eine Berechtigung haben

In vielen SharePoint-Projekten wird sehr schnell gesagt: „Ordner sind schlecht, wir machen alles über Metadaten.“

Das klingt modern. In der Praxis ist es oft zu kurz gedacht.

Es gibt Teams, die arbeiten primär nicht im Browser. Sie nutzen SharePoint über OneDrive-Sync, öffnen Dateien lokal im Explorer oder Finder, arbeiten offline im Zug oder beim Kunden und erwarten eine Struktur, die sich wie ein Dateisystem anfühlt.

Microsoft beschreibt genau diesen Arbeitsmodus: SharePoint- und Teams-Dateien können per OneDrive auf den Computer synchronisiert werden, damit Nutzer direkt im Dateisystem arbeiten und Dateien auch offline verfügbar haben. Genau dort spielen Ordner weiterhin eine Rolle.

Für diese Nutzer ist eine komplett flache Bibliothek mit zehn Pflichtfeldern kein Fortschritt. Sie fühlt sich eher an wie Bürokratie.

Ordner helfen besonders bei:

• lokaler Orientierung über OneDrive-Sync
• Offline-Arbeit
• sehr stabilen, wenigen Strukturmerkmalen
• einfachen Übergängen vom Fileserver
• Teams, die fast ausschließlich mit Office-Dateien im Explorer arbeiten

Beispiele:

Kunden
  Kunde A
    Angebote
    Verträge
    Rechnungen
  Kunde B
    Angebote
    Verträge
    Rechnungen

Das versteht jeder sofort. Dafür braucht niemand eine Schulung.

Aber genau hier liegt auch das Problem: Diese Einfachheit skaliert schlecht.

Sobald ein Dokument in mehrere Dimensionen gehört — Kunde, Jahr, Dokumenttyp, Status, Projekt, Verantwortlicher, Aufbewahrung — wird die Ordnerstruktur zur Entscheidung mit Nebenwirkungen.

Liegt der Vertrag unter „Kunde A / Verträge / 2026“ oder unter „2026 / Verträge / Kunde A“?
Was passiert, wenn ein Dokument zwei Projekte betrifft?
Wie filtere ich alle offenen Verträge über alle Kunden hinweg?
Wie finde ich alle Rechnungen mit Status „in Prüfung“?
Wie erkläre ich Copilot später, welche Dokumente relevant, aktuell und vertrauenswürdig sind?

Eine Ordnerstruktur beantwortet immer nur eine Hauptfrage. Metadaten können mehrere Fragen gleichzeitig beantworten.

Was Metadaten besser können

Metadaten beschreiben ein Dokument unabhängig davon, wo es liegt.

Ein Vertrag ist dann nicht „der dritte PDF in einem Unterordner“, sondern ein Dokument mit Eigenschaften:

• Kunde: Contoso GmbH
• Dokumenttyp: Vertrag
• Status: Freigegeben
• Gültig bis: 31.12.2026
• Verantwortlich: Einkauf
• Vertraulichkeit: Intern

Damit kann SharePoint verschiedene Sichten erzeugen:

• Verträge nach Ablaufdatum
• Dokumente je Kunde
• offene Freigaben
• Inhalte nach Verantwortlichem
• alle Rechnungen aus 2026
• Projektunterlagen nach Status

Microsofts Managed-Metadata-Konzept ist genau dafür gebaut: SharePoint unterstützt formale Taxonomien über Term Sets und Managed Metadata Columns, aber auch nutzergetriebene Enterprise Keywords. Man kann also kontrollierte Begriffe nutzen, ohne jede Fachbereichssprache komplett zu ersticken.

Für SharePoint im Browser sind Metadaten meist die stärkere Logik:

• Views können filtern, gruppieren und sortieren.
• Content Query kann Metadaten gezielt durchsuchen.
• Custom Site Columns werden auffindbar, wenn sie in Views genutzt werden.
• Dokumente werden nicht nur „gefunden“, sondern fachlich eingeordnet.

Das ist nicht nur Komfort. Es ist Governance.

Denn SharePoint ist kein Netzlaufwerk mit schöner Oberfläche. SharePoint ist ein Informationssystem. Und Informationssysteme brauchen Eigenschaften, Zustände und Regeln.

Wenn die Grundlagen von SharePoint als Dokumentenmanagement-Plattform noch nicht sauber eingeordnet sind, passt als Einstieg unser Artikel „SharePoint Online – Die Basis für modernes Dokumentenmanagement“. Dort geht es um Versionierung, zentrale Ablage, Suche, Metadaten und die Rolle von SharePoint gegenüber klassischen Dateiablagen.

Der Haken: Niemand pflegt gerne Metadaten

Jetzt kommt der Punkt, an dem viele Projekte scheitern.

Die Architektur ist sauber. Die Spalten sind fachlich richtig. Die Views sehen gut aus. In der Pilotdemo nicken alle.

Und drei Monate später sind 70 Prozent der Dokumente mit „Sonstiges“ klassifiziert.

Warum?

Weil Menschen keine Metadaten pflegen, nur weil IT das für richtig hält.

Metadatenpflege funktioniert nur, wenn sie drei Bedingungen erfüllt:

1. Der Nutzen ist direkt sichtbar.
   Wer ein Feld ausfüllt, muss danach etwas schneller finden, sortieren, filtern oder auswerten können.

2. Die Eingabe ist minimal.
   Drei gute Felder schlagen zwölf theoretisch perfekte Felder.

3. Der Prozess passt zur Arbeit.
   Metadaten dürfen nicht am Ende als Zusatzarbeit kommen, sondern müssen dort entstehen, wo das Dokument sowieso angelegt, geprüft oder freigegeben wird.

Ein schlechtes Metadatenmodell erkennt man daran, dass es vor allem die Bedürfnisse von Admins erfüllt. Ein gutes Modell erkennt man daran, dass Fachbereiche damit ihren Alltag schneller erledigen.

Praktische Regeln:

• Pflichtfelder nur für wirklich kritische Informationen.
• Auswahlfelder statt Freitext, wo Standardisierung wichtig ist.
• Default-Werte nutzen, wenn der Kontext klar ist.
• Content Types verwenden, wenn Dokumentarten unterschiedliche Felder brauchen.
• Views so bauen, dass Metadaten sofort belohnt werden.
• „Unklassifiziert“-Views einrichten, damit Pflege sichtbar steuerbar bleibt.

Die wichtigste Adoption-Frage lautet nicht: „Wie erklären wir Metadaten?“

Sondern:

Welche konkrete Arbeit wird einfacher, wenn das Feld gepflegt ist?

Wenn darauf niemand antworten kann, gehört das Feld wahrscheinlich nicht ins Pflichtmodell.

Automatisierung: Autofill Columns, Document Processing und Copilot

Der bessere Weg ist nicht, Mitarbeitende mit Formularfeldern zu erschlagen.

Der bessere Weg ist: Menschen prüfen, Maschinen schlagen vor.

Microsoft baut hier mehrere Bausteine in SharePoint und Microsoft 365 aus. Document processing for Microsoft 365 nennt unter anderem Autofill Columns, OCR, Taxonomy Tagging und weitere Pay-as-you-go-Dienste. In der Copilot-in-SharePoint-FAQ beschreibt Microsoft außerdem Funktionen, die Bibliotheksinhalte nutzen, um Metadaten-Spalten vorzuschlagen, zu extrahieren, zu klassifizieren oder zusammenzufassen. Wichtig ist dabei: Autorisierte Nutzer prüfen und übernehmen Änderungen.

Das ist der richtige Denkansatz.

Nicht:

„KI macht ab jetzt alles automatisch.“

Sondern:

„KI reduziert die manuelle Erfassung — der Mensch behält die fachliche Kontrolle.“

Ein realistischer Prozess sieht so aus:

1. Dokument wird hochgeladen oder erstellt.
2. SharePoint/Document Processing/Copilot analysiert Inhalt und Kontext.
3. Vorschläge für Dokumenttyp, Kunde, Status oder Schlagworte werden erzeugt.
4. Ein autorisierter Nutzer prüft die Vorschläge.
5. Metadaten werden übernommen.
6. Views, Suche, Prozesse und Copilot nutzen die gepflegte Struktur.

Das ist deutlich besser als reine Handarbeit. Aber es ist kein Freifahrtschein.

Für produktive Nutzung braucht es:

• klare Felddefinitionen
• kontrollierte Begriffe
• Review-Regeln
• Qualitätskontrollen
• Ausnahmenprozess
• Monitoring von „leer“, „Sonstiges“ und falschen Werten

Sonst automatisiert man nur das Chaos.

Der Hybrid-Ansatz: Beide Welten sauber vereinen

In der Praxis empfehle ich selten „nur Ordner“ oder „nur Metadaten“.

Der Mittelstand braucht meistens einen kontrollierten Hybrid.

Die Idee:

Ordner nur dort, wo sie den Arbeitsmodus unterstützen. Metadaten überall dort, wo sie Orientierung, Auswertung, Governance und Copilot verbessern.

Beispiel:

• Bibliothek: Kundenunterlagen
• Ordner-Ebene 1: Kunde oder Jahr — nur wenn für Sync-Nutzer wirklich notwendig
• Keine tiefen Unterordnerketten
• Dokumenttyp, Status, Verantwortlich, Vertraulichkeit und Aufbewahrung als Metadaten
• Views für Web-Nutzer: Nach Kunde, nach Dokumenttyp, nach Status, nach Frist
• View „Unvollständig klassifiziert“ für Governance
• Automatisierung für Vorschläge und Pflichtfelder

Wichtig: Der Ordner darf nicht die einzige Wahrheit sein.

Wenn ein Ordner „Verträge“ heißt, sollte der Dokumenttyp trotzdem „Vertrag“ sein. Sonst verliert man die Fähigkeit, über alle Kunden, Jahre und Projekte hinweg zu filtern.

Das ist der Kern:

Ordner geben Nähe zum alten Arbeitsmodus. Metadaten geben Zukunftsfähigkeit.

Was ist besser für Copilot?

Für Copilot ist nicht entscheidend, ob ein Dokument in einem Ordner oder in einer flachen Bibliothek liegt.

Entscheidend ist, ob der Inhalt:

• aktuell ist
• korrekt berechtigt ist
• nicht mehrfach widersprüchlich vorliegt
• fachlich gut beschrieben ist
• in relevanten Sites/Bibliotheken liegt
• nicht in Archiv- oder Schattenstrukturen verrottet

Microsoft formuliert es für Copilot und Agents ziemlich deutlich: Sie funktionieren besser, wenn SharePoint- und OneDrive-Inhalte gut governancet, relevant und sicher zugänglich sind. Copilot und Agents nutzen Microsoft Graph und respektieren vorhandene Berechtigungen, Sharing Settings und Policies.

Das heißt für Migrationen:

Copilot macht schlechte Informationsarchitektur nicht gut. Copilot macht sie sichtbarer.

Wenn Berechtigungen zu breit sind, steigt das Risiko.
Wenn alte Dokumente neben neuen liegen, steigt die Verwirrung.
Wenn „final_final_neu.pdf“ neben dem gültigen Vertrag liegt, wird die Antwortqualität nicht besser.
Wenn Metadaten fehlen, fehlen Copilot zusätzliche Signale zur Einordnung.

Für Copilot-Readiness gewinnt deshalb meistens der Hybrid mit starker Governance:

• keine wilden Tiefenordner
• klare Bibliotheken und Sites
• sinnvolle Metadaten
• kontrollierte Berechtigungen
• Lifecycle-Regeln
• regelmäßige Reviews
• Archivierung alter Inhalte

Nicht weil Copilot zwingend Metadaten braucht, um überhaupt zu funktionieren. Sondern weil gute Metadaten, klare Inhaltsmodelle und Governance die Wahrscheinlichkeit erhöhen, dass Nutzer relevante, nachvollziehbare und sichere Antworten bekommen.

Genau diese Basis haben wir in zwei ergänzenden Beiträgen schon vertieft: „Copilot in SharePoint scheitert selten am Modell – sondern an eurer Basis“ erklärt den Zusammenhang aus Informationsarchitektur, Berechtigungen, Metadaten und Content-Hygiene. „M365-Audit vor Copilot: Warum Tenant-Hygiene jetzt Pflicht ist“ geht stärker auf Tenant-Hygiene, SharePoint-Berechtigungen und Copilot-Risiken ein.

Vorgehensmodell für die Migration

1. Fileserver nicht kopieren — analysieren

Vor der Migration muss klar sein:

• Welche Ordner werden aktiv genutzt?
• Welche Inhalte sind Altlasten?
• Wo gibt es Dubletten?
• Welche Berechtigungen sind historisch gewachsen?
• Welche Dokumentarten kommen wirklich vor?
• Welche Suchfragen stellen Nutzer heute?

Eine Migration ohne Analyse ist nur ein Umzug von Chaos.

2. Arbeitsmodi trennen

Nicht alle arbeiten gleich.

• Sync-/Explorer-Nutzer brauchen Orientierung im lokalen Dateisystem.
• Web-/Teams-Nutzer brauchen Views, Filter und schnelle Suche.
• Führungskräfte brauchen Auswertungen und Status.
• Copilot-Nutzer brauchen verlässliche, aktuelle, berechtigte Inhalte.

Diese Arbeitsmodi sollten bewusst im Zielmodell vorkommen.

3. Bibliotheken und Sites fachlich schneiden

Nicht jede Abteilung braucht eine einzige riesige Dokumentbibliothek. Und nicht jeder Ordner braucht eine eigene Site.

Gute Schnitte entstehen entlang von:

• Verantwortlichkeit
• Berechtigung
• Lebenszyklus
• Dokumenttyp
• Prozess
• Vertraulichkeit

Wenn zwei Inhalte komplett unterschiedliche Berechtigungen, Prozesse und Aufbewahrung haben, gehören sie selten in dieselbe Bibliothek.

4. Minimales Metadatenmodell bauen

Start klein:

• Dokumenttyp
• Status
• Kunde/Projekt/Fachbereich
• Verantwortlich
• Vertraulichkeit
• Aufbewahrung oder Gültigkeit, falls relevant

Mehr nur, wenn es echten Nutzen gibt.

5. Views als Produkt denken

Views sind nicht Deko.

Sie sind die Oberfläche, über die Nutzer den Sinn von Metadaten erleben.

Beispiele:

• „Meine offenen Dokumente“
• „Verträge laufen in 90 Tagen ab“
• „Dokumente ohne Klassifikation“
• „Projektunterlagen nach Phase“
• „Kundenunterlagen nach Dokumenttyp“

Wenn Views gut sind, pflegen Nutzer eher Metadaten, weil der Nutzen sichtbar wird.

6. Automatisierung und Review einführen

Metadatenqualität ist kein einmaliges Migrationsprojekt. Es ist ein Betriebsmodell.

Nach dem Go-live braucht es:

• automatische Vorschläge
• Pflichtfelder an den richtigen Stellen
• Qualitäts-Views
• regelmäßige Reviews
• klare Owner je Bibliothek/Site
• Nachbesserung nach echten Nutzungsmustern

Vor- und Nachteile im Überblick

Automatisierung der Metadatenpflege

Weiterführende WITC-Artikel

Wenn ihr tiefer in die angrenzenden Themen einsteigen wollt, passen diese bereits veröffentlichten Beiträge direkt zu diesem Artikel:

• SharePoint Online – Die Basis für modernes Dokumentenmanagement — Grundlagen zu SharePoint als Dokumentenmanagement-Plattform statt Fileserver-Ersatz.
• Copilot in SharePoint scheitert selten am Modell – sondern an eurer Basis — warum Informationsarchitektur, Berechtigungen, Metadaten und Content-Hygiene die Copilot-Qualität bestimmen.
• M365-Audit vor Copilot: Warum Tenant-Hygiene jetzt Pflicht ist — warum Copilot alte Berechtigungs- und Governance-Probleme nicht verursacht, aber sichtbar macht.
• Was der Copilot Knowledge Agent für KMU bedeutet — Einordnung, wie SharePoint-Inhalte für Copilot-/Agent-Szenarien besser strukturiert werden.
• M365 Governance: die 10% Baseline, die 80% Chaos verhindert — schlanke Governance-Regeln für Teams, SharePoint, Gästezugriff und Lifecycle.

---

Fazit

Wenn ein Filesystem nach SharePoint migriert wird, ist die gefährlichste Entscheidung nicht „Ordner behalten“.

Die gefährlichste Entscheidung ist, keine bewusste Entscheidung zu treffen.

Ein 1:1-Umzug übernimmt alte Probleme.
Ein radikales Metadatenmodell ohne Adoption erzeugt neue Probleme.
Ein guter Hybrid verbindet Arbeitsrealität mit Zukunftsfähigkeit.

Meine klare Empfehlung:

• Nutzt Ordner sparsam für Sync- und Orientierungslogik.
• Nutzt Metadaten konsequent für Fachlichkeit, Views, Suche, Governance und Copilot-Readiness.
• Automatisiert Vorschläge, aber behaltet menschliche Prüfung.
• Bewertet die Struktur nicht aus IT-Sicht, sondern aus Nutzungs- und Governance-Sicht.

SharePoint ist dann nicht der neue Fileserver.

SharePoint wird zur Wissensbasis, die Menschen heute nutzen — und Copilot morgen sinnvoll auswerten kann.

Praxis-Check

Wenn ihr gerade vor einer Fileserver-zu-SharePoint-Migration steht, sind das die fünf Fragen, die ich vor jedem Zielbild stellen würde:

1. Welche Ordnerlogik brauchen Nutzer wirklich lokal über Sync?
2. Welche Sichten brauchen Nutzer im Browser?
3. Welche Metadaten erzeugen sofort sichtbaren Nutzen?
4. Welche Felder können automatisch vorgeschlagen werden?
5. Welche Inhalte dürfen Copilot/Agents auf keinen Fall falsch oder zu breit sichtbar machen?

Wenn diese Fragen nicht beantwortet sind, ist die Migration noch nicht bereit.

Wenn ihr gerade an diesem Punkt steht: Wir unterstützen bei SharePoint-Migrationen genau hier — Analyse, Zielarchitektur, Metadatenmodell, Pilotmigration, Adoption und Copilot-Readiness-Check — ohne Dogma, aber mit sauberem Betriebsmodell.