Vom Fileserver nach SharePoint: Eine Migration ersetzt keine Informationsarchitektur

Ein Fileserver lässt sich technisch nach SharePoint migrieren. Dateien werden gescannt, Benutzer zugeordnet, Zielbibliotheken vorbereitet und Inhalte übertragen. Am Ende stimmen Dateimengen und Protokolle – trotzdem finden Mitarbeitende ihre Unterlagen schlechter als zuvor.

Das passiert, wenn das Projekt eine Transportaufgabe löst, aber die Ordnungsfrage offenlässt. Alte Abteilungsordner, historisch gewachsene Berechtigungen, Dubletten und Archivbestände liegen nun in Microsoft 365. Der Speicherort ist moderner. Die Informationsarchitektur ist dieselbe geblieben.

Eine Migration und eine Informationsarchitektur sind deshalb zwei unterschiedliche Ergebnisse:

• Migration: Die vorgesehenen Inhalte wurden technisch korrekt von der Quelle zum Ziel übertragen.
• Informationsarchitektur: Nutzer verstehen, wo welche Information hingehört, wie sie gefunden wird, wer sie verantwortet und wann sie überprüft oder entfernt wird.

Ein gutes Projekt benötigt beides. Der Fehler liegt nicht im Migrationstool, wenn die zweite Aufgabe nie entschieden wurde.

Der Fileserver und SharePoint folgen unterschiedlichen Nutzungslogiken

Ein klassischer Fileserver wird häufig über Ordnerpfade und Gruppenberechtigungen organisiert. Der Pfad trägt einen großen Teil des Kontextes: Abteilung, Projekt, Jahr, Vorgang und Dokumentart können in mehreren Ebenen stecken.

SharePoint kann ebenfalls Ordner verwenden. Zusätzlich strukturiert die Plattform Informationen über Sites, Bibliotheken, Teams-Bezug, Navigation, Inhaltstypen, Metadaten, Ansichten, Suche, Freigaben und Lebenszyklen. Diese Möglichkeiten bedeuten nicht, dass jede Migration möglichst viele Funktionen einsetzen sollte. Sie zeigen jedoch, warum eine unveränderte Kopie der Quelle selten automatisch ein gutes Zielbild ergibt.

Die aktuelle Microsoft-Dokumentation zur SharePoint-Informationsarchitektur beginnt bei den Bedürfnissen der Nutzer und der Auffindbarkeit. Die Planung der Navigation umfasst nicht nur Menüs, sondern auch Portal-, Hub-, Site-, Metadaten- und Sucharchitektur.

Damit verschiebt sich die Leitfrage. Statt „Welcher Ordner wird welche Site?“ muss das Projekt fragen: Welche Person sucht welche Information für welche Aufgabe – und woran erkennt sie den richtigen Ort?

Vor dem Zielbild steht die Bestandsentscheidung

Ein Scan kann Dateitypen, Größen, Alter, Pfadlängen und technische Fehler sichtbar machen. Er kann nicht zuverlässig beantworten, ob eine Datei fachlich noch benötigt wird, welche von drei Fassungen gilt oder ob ein historischer Ordner weiterhin einen Geschäftszweck besitzt.

Der Microsoft-Leitfaden für Fileshare-Migrationen trennt Planung, Bestandsanalyse und Bereinigung, Vorbereitung des Ziels, Migration und Nutzer-Onboarding. Er weist auch darauf hin, dass nur die Organisation selbst ihre Daten und deren Nutzung vollständig kennt.

Für jeden größeren Quellbereich sollten deshalb fünf Entscheidungen fallen:

1. Migrieren: Inhalt wird aktiv benötigt und erhält einen begründeten Zielort.
2. Archivieren: Inhalt muss erhalten bleiben, gehört aber nicht in die tägliche Zusammenarbeit.
3. Löschen: Inhalt besitzt keinen fortbestehenden Zweck und darf nach den geltenden Regeln entfernt werden.
4. Klären: Owner, Relevanz oder Schutzbedarf sind noch nicht entschieden.
5. Zurückstellen: Inhalt bleibt vorübergehend in der Quelle, weil Abhängigkeiten oder Qualität eine sichere Migration verhindern.

„Alles migrieren und später aufräumen“ verlagert die schwierigste Entscheidung in den laufenden Betrieb. Das kann als bewusstes Zwischenziel vertretbar sein. Ohne Owner, Termin und Abgrenzung wird „später“ jedoch leicht zum Dauerzustand.

Sieben Entscheidungen für die Zielarchitektur

1. Zweck und Zielgruppe jedes Bereichs

Eine Site oder Bibliothek braucht einen verständlichen Zweck. „Laufwerk S ersetzen“ ist keiner. Besser sind Aussagen wie:

• gemeinsamer Arbeitsraum des Einkaufs,
• zeitlich begrenzte Zusammenarbeit im Projekt,
• freigegebene Verfahrens- und Organisationsdokumentation,
• persönliche Arbeitsdateien einer Person,
• Austausch mit einem definierten externen Partner.

Aus Zweck und Zielgruppe folgen Struktur, Berechtigung, Navigation und Lebenszyklus. Unterschiedliche Zwecke sollten nicht nur deshalb im selben Ziel landen, weil sie auf dem Fileserver denselben Hauptordner teilten.

2. Zielort: OneDrive, Teams oder SharePoint

Die drei Begriffe werden im Alltag häufig vermischt. Für die Projektentscheidung hilft eine vereinfachte Zuordnung:

Nutzung	Naheliegender Ausgangspunkt
persönliche Arbeitsdateien und eigene Entwürfe	OneDrive
Zusammenarbeit eines definierten Teams oder Projekts	mit Teams verbundener SharePoint-Arbeitsraum
bereitgestellte Information für eine größere Zielgruppe	SharePoint-Kommunikations- oder Informationsbereich
fachliche Dokumentensammlung mit Metadaten und Ansichten	SharePoint-Dokumentbibliothek im passenden fachlichen Kontext

Diese Tabelle ist keine starre Produktregel. Manche Inhalte überschneiden sich. Entscheidend ist, dass der Zielort aus Nutzung und Verantwortung abgeleitet wird – nicht aus der ersten Ordnerebene der Quelle.

Der Beitrag „Teams-Governance ohne unnötige Bürokratie“ beschreibt, wie Zweck, Owner, externe Zusammenarbeit, Informationsablage und Lebenszyklus für Teamarbeitsräume verbunden werden.

3. Ownership und Vertretung

Jeder Zielbereich benötigt einen fachlichen Owner. Er verantwortet nicht die technische Plattform, sondern:

• Zweck und Nutzerkreis,
• inhaltliche Struktur,
• zulässige Freigaben,
• regelmäßige Überprüfung,
• Entscheidung über Archivierung oder Beendigung.

Die IT beziehungsweise Plattformadministration verantwortet den technischen Rahmen und unterstützt bei Berechtigungen, Migration, Schutz und Betrieb.

Microsoft dokumentiert für SharePoint inzwischen Funktionen zur Site-Lifecycle-Verwaltung, darunter Prüfungen auf fehlende Owner, Inaktivität und fortbestehenden Geschäftszweck. Bestimmte Automatisierungen hängen vom jeweiligen Lizenzumfang ab. Unabhängig davon bleibt die organisatorische Grundregel: Eine Site ohne erreichbaren Owner ist kein dauerhaft verantworteter Informationsraum.

4. Berechtigungslogik statt Rechtekopie

Fileserver-Berechtigungen sind oft über Jahre gewachsen. Einzelne Ordner brechen Vererbungen, ehemalige Projektgruppen bleiben bestehen und direkte Benutzerrechte ergänzen Gruppen. Eine technische Übernahme kann diese Komplexität konservieren.

Vor der Migration sollte deshalb entschieden werden:

• Welche Rollen benötigen Lesen, Bearbeiten oder Verwalten?
• Welche Berechtigungen werden über Gruppen statt Einzelpersonen vergeben?
• Welche sensiblen Inhalte benötigen einen getrennten Bereich?
• Welche externen Nutzer dürfen welchen Geschäftszweck erfüllen?
• Welche alten Rechte sind historisch, aber nicht mehr fachlich begründet?

Nicht jede Ausnahme muss verschwinden. Sie muss aber erklärbar und verantwortet sein. Eine gute Zielarchitektur folgt möglichst wenigen stabilen Berechtigungsgrenzen. Feingranulare Einzelrechte auf Dateien sind kein geeignetes Standardmodell für einen großen Bestand.

5. Struktur, Metadaten und Navigation

Ordner sind weiterhin möglich und für bestimmte Arbeitsweisen sinnvoll. Problematisch wird es, wenn nur der vollständige alte Pfad Kontext liefert oder Nutzer zwischen vielen ähnlich benannten Hierarchien wählen müssen.

Metadaten lohnen sich, wenn sie eine echte Aufgabe unterstützen:

• Dokumente nach Projekt, Status oder Dokumentart filtern,
• unterschiedliche Ansichten für verschiedene Rollen bereitstellen,
• Suche und Auffindbarkeit verbessern,
• Lebenszyklus oder fachliche Bearbeitung steuern.

In SharePoint können Spalten eines Inhaltstyps fachliche Metadaten erfassen und in Ansichten verwenden. Daraus folgt nicht, dass jede Datei viele Pflichtfelder benötigt. Zu viele manuelle Angaben senken die Akzeptanz und erzeugen neue Qualitätsprobleme.

Eine sinnvolle Regel lautet: Ein Metadatum wird nur eingeführt, wenn klar ist, wer es pflegt und welche Navigation, Suche, Ansicht oder Entscheidung davon profitiert.

6. Lebenszyklus und Aufbewahrung

Ein Projektbereich braucht ein Ende. Eine Verfahrenssammlung braucht eine regelmäßige fachliche Prüfung. Persönliche Entwürfe haben einen anderen Lebenszyklus als freigegebene Vertragsunterlagen.

Vor der Migration sollten daher mindestens geklärt sein:

• Wann wird ein Bereich überprüft?
• Was geschieht bei Wechsel des Owners?
• Wann wird ein Projekt geschlossen?
• Welche Inhalte bleiben als Nachweis erhalten?
• Was wird archiviert und was gelöscht?
• Wer darf eine Ausnahme entscheiden?

Konkrete Aufbewahrungs- und Löschfristen hängen von Inhalt, Rechtsgrundlage und Unternehmensregeln ab. Ein allgemeiner Migrationsleitfaden kann sie nicht festlegen. Das Projekt muss die zuständigen fachlichen, rechtlichen und datenschutzbezogenen Rollen einbinden, wo dies erforderlich ist.

7. Suche und tatsächliche Auffindbarkeit

Eine technisch indexierte Datei ist noch nicht leicht auffindbar. Nutzer brauchen verständliche Bezeichnungen, passende Zielbereiche, ausreichende Metadaten und eine Navigation, die ihre Aufgaben abbildet.

Die Auffindbarkeit sollte mit konkreten Aufgaben geprüft werden:

• Finden neue Mitarbeitende die aktuelle Reisekostenregel?
• Erkennt der Vertrieb die freigegebene Angebotsvorlage?
• Findet ein Projektmitglied die gültige technische Entscheidung?
• Kann ein Owner veraltete oder unklare Inhalte identifizieren?

Microsoft empfiehlt in seinen Prinzipien zur Informationsarchitektur, Navigation mit tatsächlichen Nutzern und realistischen Aufgaben zu testen. Ein Klicktest mit der Projektgruppe ersetzt diesen Blick nicht vollständig.

Konstruiertes Beispiel: Die alte Struktur erhält nur neue URLs

Das folgende Beispiel ist konstruiert.

Ein Unternehmen legt für jede erste Ordnerebene seines Fileservers eine SharePoint-Site an. Unterhalb werden die vorhandenen Ordner weitgehend unverändert übertragen. Alte Gruppen und Einzelberechtigungen werden so vollständig wie möglich nachgebildet.

Die Migration ist technisch erfolgreich. Anschließend zeigt sich jedoch:

• Projekt-, Abteilungs- und Archivmaterial liegen weiterhin nebeneinander.
• Mehrere Sites heißen aus Nutzersicht ähnlich.
• Mitarbeitende speichern neue Dateien teils in Teams, teils in den migrierten Bibliotheken.
• Veraltete Gruppen besitzen weiterhin Zugriff.
• Für abgeschlossene Bereiche gibt es keinen Owner und kein Enddatum.

SharePoint hat das Problem nicht erzeugt. Das Projekt hat die bisherige Ordnung als Zielarchitektur behandelt, ohne ihren Zweck zu prüfen.

Eine bessere Vorgehensweise wählt zunächst einen abgegrenzten Bereich. Nutzeraufgaben, Owner, Zielorte, Berechtigungsgruppen und Lebenszyklus werden festgelegt. Erst danach wird ein repräsentativer Bestand migriert und fachlich abgenommen.

Ein Pilot prüft mehr als Übertragungsgeschwindigkeit

Der erste Pilot sollte nicht nur technisch leicht sein. Er sollte die späteren Entscheidungsfragen in beherrschbarer Größe enthalten:

• mehrere relevante Nutzerrollen,
• typische und problematische Dateitypen,
• einige berechtigte Ausnahmen,
• reale Such- und Navigationsaufgaben,
• einen fachlich erreichbaren Owner,
• einen überschaubaren Cutover.

Der Pilot gilt nicht bereits als bestanden, wenn alle vorgesehenen Dateien übertragen wurden. Zusätzliche Abnahmekriterien sind:

• Nutzer finden definierte Informationen,
• Berechtigungen entsprechen dem Zielmodell,
• aktive Dokumente lassen sich im vorgesehenen Prozess bearbeiten,
• Owner können Inhalte und Zugriffe verwalten,
• Support und Rückfall sind geklärt,
• Quell- und Zielbestand sind abgestimmt,
• Nutzer wissen, ab wann welcher Ort verbindlich ist.

Das Migrationstool und seine Berichte helfen bei technischen Fehlern und Einschränkungen. Die fachliche Abnahme muss die Organisation ergänzen.

Wann eine weitgehend unveränderte Migration vertretbar ist

Es gibt Situationen, in denen die technische Ablösung des Fileservers dringender ist als die vollständige Neugestaltung. Eine weitgehend unveränderte Übernahme kann als Zwischenziel sinnvoll sein, wenn:

• die Quelle kurzfristig außer Betrieb genommen werden muss,
• der Bestand zunächst sicher und zugänglich übertragen werden soll,
• Zielbereiche und Berechtigungen trotzdem kontrolliert sind,
• Nutzer den Übergangscharakter verstehen,
• Bereinigung und Neustrukturierung einen Owner, Termin und Umfang besitzen,
• das Zwischenziel keine problematischen Freigaben oder unzulässigen Datenwege erzeugt.

Die Gegenanzeige ist ein unbefristetes „Lift and Shift“, das anschließend als fertige Collaboration-Lösung bezeichnet wird. Dann trägt die Organisation die alten Such-, Rechte- und Lebenszyklusprobleme weiter und ergänzt neue Ablagealternativen.

Eine Zielbild-Matrix für jeden Quellbereich

Ein pragmatisches Arbeitsmittel verbindet Quelle und Zielentscheidung:

Feld	Zu klärender Inhalt
Quellbereich	Laufwerk, Ordner, Umfang und technischer Zustand
Geschäftszweck	Aufgabe und Prozesse, die der Bestand unterstützt
Zielgruppe	Nutzerrollen, interne und externe Beteiligte
Owner und Vertretung	fachliche Verantwortung im Ziel
Entscheidung	migrieren, archivieren, löschen, klären oder zurückstellen
Zielort	OneDrive, Teamarbeitsraum, SharePoint-Bereich oder Archiv
Berechtigungsmodell	Gruppen, Rollen und begründete Ausnahmen
Struktur und Metadaten	Ordner, Bibliotheken, Inhaltstypen, Ansichten und Navigation
Lebenszyklus	Review, Projektende, Archivierung und Löschentscheidung
Abnahme	Suchaufgaben, Berechtigungsfälle und fachliche Nutzung

Diese Matrix muss nicht für jede einzelne Datei ausgefüllt werden. Sie arbeitet auf sinnvollen Inhaltsbereichen und Ausnahmen. Damit bleibt der Aufwand beherrschbar.

Der Erfolg zeigt sich nach dem Cutover

Eine Projektkennzahl wie „übertragene Dateien“ misst den Transport. Für den organisatorischen Nutzen sind andere Signale aussagekräftiger:

• Können Nutzer definierte Informationen schneller oder verlässlicher finden?
• Sinkt die Zahl paralleler Ablageorte für denselben Zweck?
• Besitzen aktive Bereiche einen erreichbaren Owner?
• Werden Berechtigungs- und Zugriffsfragen nachvollziehbar entschieden?
• Werden abgeschlossene Bereiche tatsächlich überprüft und beendet?
• Entstehen weniger Dubletten und Rückfragen zur gültigen Fassung?

Diese Fragen brauchen keine erfundene universelle Zielquote. Vor dem Pilot werden Ausgangslage und gewünschte Wirkung festgelegt; danach wird mit denselben Aufgaben erneut geprüft.

Der Beitrag „Digitalisierung vor dem Toolkauf“ liefert dafür die übergeordnete Logik: Erst Ergebnis, Nutzer, Daten und Verantwortung klären, dann das Werkzeug konfigurieren.

Der erste sinnvolle Schritt ist deshalb nicht die Installation eines Migration Agents. Wählen Sie einen relevanten Quellbereich und beantworten Sie für ihn Zweck, Zielgruppe, Owner, Zielort, Berechtigungslogik, Auffindbarkeit und Ende. Erst wenn diese sieben Entscheidungen zusammenpassen, kann das Migrationstool die richtige Aufgabe zuverlässig ausführen.