In der Architekturdiskussion geht meist unter, dass zwischen Entscheidung und Betrieb eine Migration liegt, deren Aufwand die Auswahl der Zielarchitektur beeinflussen sollte.

Das erste Thema ist das Seeding. Ein globaler Datenbestand von mehreren hundert Terabyte lässt sich nicht über eine 100-Mbit/s-Standleitung in ein Wochenende pressen. Die Hersteller bieten dafür unterschiedliche Verfahren an – vom initialen Befüllen eines Edge Filers am zentralen Standort mit anschließendem Transport bis zu Import-Diensten der Cloud-Anbieter. Diese Frage gehört in die Planung, nicht in die Umsetzungsphase.

Das zweite Thema sind die Berechtigungen. NTFS-ACLs, Vererbungsstrukturen, historisch gewachsene Sonderrechte und verwaiste SIDs überstehen eine Migration nur, wenn das Zielsystem sie sauber abbildet und der Kopierprozess sie erhält. Eine Bereinigung vorab ist fast immer sinnvoll und wird fast immer aufgeschoben.

Das dritte Thema ist der Cutover. Ein Parallelbetrieb aus alter und neuer Struktur mit einem finalen Delta-Abgleich ist der übliche Weg.

Wie gut diese drei Themen werkzeugseitig abgedeckt sind, unterscheidet die Produkte deutlicher, als die Datenblätter vermuten lassen. CTERA bringt einen Migrationsagenten mit, der auf dem Edge Filer läuft und unmittelbar an die weiter oben erwähnte Discovery anschließt: Aus der Bestandsaufnahme der Legacy-Freigaben entstehen Migrationsjobs, die Daten samt NTFS-Berechtigungen übernehmen und sich für Delta-Läufe wiederholen lassen, bis beim Cutover nur noch eine kleine Änderungsmenge offen ist. Der praktische Vorteil liegt in der Personalunion: Dasselbe System führt die Migration durch und stellt anschließend den produktiven File Service bereit. Ein separates Migrationswerkzeug mit eigener Lizenz, eigenem Betriebskonzept und eigenen Fehlerquellen entfällt. In ASSISTRA-Projekten hat dieses Vorgehen die geschilderten Szenarien zuverlässig abgedeckt.

In dieser Integrationstiefe ist das ungewöhnlich. Wo ein solcher Agent fehlt, wird in der Praxis mit generischen Werkzeugen migriert – Robocopy ist der Klassiker, ergänzt um selbstgeschriebene Skripte für Jobsteuerung, Protokollierung und Fehlerbehandlung. Das funktioniert, kostet aber Zeit und Personal: Jobs müssen manuell geplant, überwacht und für Delta-Läufe wiederholt werden, Abbrüche fallen erst in der Auswertung auf, und der Cutover-Zeitpunkt lässt sich nur schätzen. Bei einigen hundert Freigaben summiert sich dieser Aufwand zu einem eigenständigen Projektteil, der in der Produktbewertung meist gar nicht auftaucht.

Für die Umstellung der Anwender ist DFS Namespaces ein hervorragendes Werkzeug – auch dann, wenn DFS-R ausdrücklich nicht die Zielarchitektur ist. Ein DFS-Pfad als stabile Adresse entkoppelt die Benutzersicht vom tatsächlichen Backend und erlaubt, Freigaben schrittweise umzuhängen, ohne Laufwerksverbindungen, Verknüpfungen und Anwendungskonfigurationen anzufassen. Diese Trennung von Namespace und Speicherort ist der Teil von DFS, der auch in einer Edge-Architektur seinen Wert behält.