Enterprise NAS Migration: Checkliste für die Planung

Ein typischer Anruf aus dem Support beginnt mit einem Satz, der mir seit Jahren immer wieder begegnet: „Wir haben ein neues NAS bestellt, aber wir wissen nicht, wie wir die alten Daten sauber herüberbekommen." Dahinter steht meist ein Unternehmen, das seinen Storage konsolidiert oder von einer ausgedienten Hardwaregeneration auf ein aktuelles Enterprise-System wechselt. Was zunächst nach einer simplen Kopieraktion klingt, ist in der Praxis ein mehrstufiger Prozess, der gut vorbereitet sein will. Genau hier setzt diese enterprise nas migration checkliste für it-administratoren an – als roter Faden durch die Phasen, die zwischen dem ersten Lieferkarton und der produktiven Inbetriebnahme liegen.

Die folgenden Abschnitte führen Schritt für Schritt durch die einzelnen Phasen einer Storage-Migration: von der Bestandsaufnahme über die Berechtigungsübernahme bis zur abschließenden Integritätsprüfung. Das Ziel ist nicht eine möglichst schnelle Übertragung, sondern eine Übertragung, die am Ende genauso konsistent ist wie der Zustand vor dem Umzug.

Bestandsaufnahme und Datenbereinigung vor dem Umzug

Eine datenmigration nas planung beginnt nicht mit dem eigentlichen Kopiervorgang, sondern mit einer ehrlichen Inventur des Quellsystems. In vielen Supportfällen stelle ich fest, dass auf den ausgemusterten NAS-Volumen noch erhebliche Mengen an ROT-Daten liegen – also redundant, veraltet oder schlicht ungenutzt. Dazu gehören alte Backup-Archive, doppelte Dateien, vergessene Freigaben und Daten, die seit Monaten oder Jahren niemand mehr angefasst hat.

Diese Daten haben zwei Nachteile: Sie verlängern die Migrationszeit erheblich, und sie werden mit derselben Sorgfalt übertragen wie produktive Bestände. Das bedeutet für die Praxis, dass eine konsequente Bereinigung vor dem Umzug nicht nur Speicherplatz auf dem Zielsystem schafft, sondern auch die Dauer des gesamten Projekts verkürzt. Wer die storage konsolidierung vorbereitung als Aufräumaktion versteht, gewinnt auf beiden Seiten.

Für die Bestandsaufnahme empfiehlt sich ein strukturiertes Vorgehen in drei Schritten:

• Volumenanalyse: Wie viel Daten liegen tatsächlich auf dem Quellsystem, und wie verteilt sich das Volumen über die einzelnen Freigaben? Tools wie TreeSize, WinDirStat oder die bordeigenen Berichtsfunktionen der NAS-Systeme liefern hierzu eine erste Übersicht. Dabei lohnt es sich, nicht nur die Gesamtgröße zu erfassen, sondern auch die Verteilung über die Verzeichnistiefen hinweg zu betrachten – denn tiefe, stark fragmentierte Verzeichnisbäume verlangsamen die Migration überproportional.
• Nutzungsanalyse: Welche Freigaben werden aktiv genutzt, welche sind verwaist? Über die Zugriffsprotokolle des NAS lässt sich feststellen, wann auf welche Verzeichnisse zuletzt zugegriffen wurde. Verzeichnisse ohne Zugriff in den letzten zwölf Monaten sind erfahrungsgemäß kritische Kandidaten für eine Löschung oder externe Archivierung. Hier ist allerdings Vorsicht geboten: Saisonale Daten – etwa Jahresabschlüsse, Prüfungsunterlagen oder archivierte Projekte – können längere Inaktivitätsphasen haben, ohne irrelevant zu sein. Eine kurze Rücksprache mit den Fachabteilungen verhindert das fahrlässige Löschen solcher Bestände.
• Klassifizierung: Welche Daten sind geschäftskritisch, welche sind archivwürdig, welche können gelöscht werden? Eine einfache Klassifikation in drei Kategorien reicht oft aus, um den Umgang mit ROT-Daten festzulegen. Wer die Ressourcen hat, kann zusätzlich nach Zugriffshäufigkeit und regulatorischer Relevanz unterscheiden – etwa ob bestimmte Daten aufbewahrungspflichtig sind oder Compliance-Anforderungen unterliegen.

Nach der Bereinigung sollte das tatsächlich zu migrierende Datenvolumen nochmals gemessen und mit der ursprünglichen Schätzung abgeglichen werden. Diese Zahl bildet die Grundlage für alle weiteren Planungen – von der Bandbreite des Migrationsfensters bis zur erforderlichen Kapazität auf dem Zielsystem. Erfahrungsgemäß liegt das tatsächlich zu migrierende Volumen nach einer konsequenten Bereinigung deutlich unter dem anfänglich geschätzten – oft genug reicht das aus, um auf die nächstkleinere Ausbaustufe des Zielsystems zu wechseln und damit Budget freizusetzen, das in Backup-Lösungen oder Netzwerkausbau fließen kann.

Eine Stunde Bereinigung spart oft mehrere Stunden Migrationszeit – und reduziert gleichzeitig das Risiko, dass veraltete Strukturen auf der neuen Plattform weitergepflegt werden müssen.

Methoden der Datenübertragung und Integritätssicherung

Ist die Datenbasis bereinigt, geht es an die eigentliche Übertragung. Dabei spielt die Sicherung der datenintegrität bei storage migration eine zentrale Rolle. Standardkopierbefehle kopieren in der Regel zuverlässig, aber sie prüfen nicht, ob die Daten auf der Zielseite wirklich identisch sind. In Produktionsumgebungen ist das ein Risiko, das niemand eingehen möchte.

Deshalb setzen professionelle Migrationswerkzeuge auf hash-basierte Prüfsummen-Vergleiche. Dabei wird auf der Quellseite für jede Datei ein Hash-Wert (beispielsweise MD5 oder SHA-256) berechnet und mit dem Hash-Wert der Zieldatei abgeglichen. Stimmen die Werte überein, ist die Übertragung bitidentisch erfolgt. Stimmen sie nicht überein, wird die Datei erneut übertragen. Erst diese Prüfung gibt einem die Gewissheit, dass kein stiller Bitfehler in den neuen Storage gewandert ist.

Die Wahl des Hash-Algorithmus hängt vom Anwendungsfall ab. MD5 ist schneller und für reine Integritätsprüfungen im internen Netzwerk noch vertretbar. Wer allerdings regulatorische Anforderungen erfüllen muss – etwa in Umgebungen mit ISO-27001-Zertifizierung oder spezifischen Compliance-Vorgaben –, sollte auf SHA-256 setzen. Der Geschwindigkeitsunterschied ist bei moderner Hardware ohnehin marginal.

Für Windows-Dateiserver und SMB-basierte NAS-Systeme kommen häufig zwei Werkzeuge zum Einsatz, die jeweils ihre Stärken haben:

Für Linux- oder NFS-basierte Umgebungen arbeiten Administratoren häufig mit rsync – wobei auch hier die Checksummen-Prüfung explizit aktiviert werden muss, etwa über die Option --checksum. Ohne diese Option prüft rsync standardmäßig nur Größe und Änderungszeit, was versteckte Bitfehler durchlässt und im Nachhinein schwer zu diagnostizieren ist. Ein weiterer Vorteil von rsync liegt in seiner Fähigkeit, inkrementelle Synchronisierungen effizient durchzuführen – was gerade bei der Warm-Cutover-Strategie (dazu später mehr) entscheidend ist.

Ein wichtiger Punkt, der in der Praxis regelmäßig übersehen wird: Bei der physischen Migration von Festplatten zwischen NAS-Gehäusen, also der klassischen HDD-Migration, muss ein eventuell aktiver SSD-Cache zwingend ausgehängt oder deaktiviert werden. Bleibt der Cache aktiv, kann es passieren, dass Daten zwar auf den rotierenden Platten liegen, der Zugriff aber ausschließlich über den Cache erfolgt – und dieser Cache nach dem Umzug als ungültig erkannt wird. Die Folge: Die Volumes sind nach der Migration unzugänglich, obwohl alle Daten physisch vorhanden sind. Dieses Problem tritt in der Praxis regelmäßig auf und gehört zu den häufigsten Ursachen für verzögerte Inbetriebnahmen nach einer Hardware-Migration. Die Ursache ist simpel: Der SSD-Cache speichert Metadaten und Hot-Daten in einem proprietären Format des jeweiligen NAS-Herstellers. Wird der Cache nicht sauber abgehängt, kann das Dateisystem die Konsistenz zwischen Cache und Platte nicht mehr garantieren. Die sicherste Vorgehensweise: Cache deaktivieren, NAS sauber herunterfahren, Platten umsetzen, Cache auf dem Zielsystem neu konfigurieren.

Berechtigungsstrukturen und ACLs konsistent übertragen

Eine der häufigsten Stolperfallen bei einer nas systemwechsel anforderungen ist die Übertragung der Zugriffsrechte. Auf Windows-basierten Systemen liegen diese in Form von NTFS-ACLs vor, auf Unix- und Linux-Systemen als POSIX-ACLs. Werden diese Strukturen bei der Migration nicht sauber mitgenommen, stehen die Benutzer nach dem Umzug vor verschlossenen Freigaben – obwohl die Dateien selbst vollständig vorhanden sind.

Das bedeutet für die Praxis, dass die Wahl des Kopierwerkzeugs und seiner Parameter über Erfolg oder Misserfolg der Migration mitentscheidet. Standardkopierbefehle wie der Windows-Explorer oder einfache cp-Befehle übertragen ACLs nicht oder nur unvollständig. Erst die explizite Aktivierung der Berechtigungsübernahme stellt sicher, dass Domänen-Berechtigungen, Benutzer-IDs und Gruppenstrukturen konsistent übernommen werden.

Bei der Migration von Windows-Dateiservern auf ein Synology-NAS hat sich folgender Ablauf bewährt:

1. Vorab-Audit der Quell-ACLs: Mit Tools wie icacls oder AccessEnum wird der Ist-Zustand dokumentiert. Ohne diese Dokumentation lässt sich nach der Migration nicht überprüfen, ob alle Berechtigungen korrekt übertragen wurden – und im Zweifel ist der Administrator derjenige, der die Abweichungen erklären muss. Diese Dokumentation ist nicht nur technisches Hilfsmittel, sondern auch organisatorische Absicherung: Im Auditfall oder bei nachträglichen Zugriffsbeschwerden liefert sie den Nachweis, dass die Migration methodisch begleitet wurde.

2. Werkzeugauswahl: FastCopy mit aktivierter ACL-Option oder Robocopy mit dem Parameter /COPY:DATSO (oder zumindest /COPY:DAT) – das S steht für Security-Informationen und ist genau der Buchstabe, der in vielen Skripten fehlt. Ein verbreiteter Fehler ist die Annahme, dass /COPY:DAT bereits die NTFS-Berechtigungen überträgt – dem ist nicht so. Erst das S-Flag sorgt für die vollständige Übernahme der Security-Deskriptoren.

3. Testmigration einer einzelnen Freigabe: Bevor das gesamte System umgezogen wird, sollte eine kleinere, repräsentative Freigabe als Pilot übertragen werden. Dort lässt sich prüfen, ob alle Berechtigungsebenen – Benutzer, Gruppen, Vererbung – korrekt übernommen wurden. Idealerweise wählt man für diesen Pilot eine Freigabe mit einer komplexen Berechtigungsstruktur: verschachtelte Gruppen, vererbte und explizite ACEs, einzelne Benutzer mit Sonderrechten. Gelingt der Pilot hier, ist die Wahrscheinlichkeit hoch, dass der Rest reibungslos folgt.

4. Abgleich der Berechtigungen: Nach der Pilotmigration werden die ACLs auf Quell- und Zielsystem verglichen. Tools wie AccessEnum oder PowerShell-Skripte leisten hier wertvolle Dienste und liefern die Grundlage für die Freigabe des Produktivbetriebs.

Bei domänenbasierten Umgebungen ist zusätzlich zu beachten, dass die SID-Konvertierung (Security Identifier) sauber funktioniert. Wenn Quell- und Zielsystem in derselben Active-Directory-Domäne liegen, lassen sich Berechtigungen in der Regel ohne Probleme übernehmen. Stehen die Systeme in unterschiedlichen Domänen, ist eine vorherige Vertrauensstellung oder eine bewusste Neuzuordnung der Berechtigungen erforderlich – sonst treffen die übertragenen ACLs ins Leere.

Ein Sonderfall ergibt sich bei der Migration zwischen verschiedenen NAS-Betriebssystemen – etwa von einem QNAP- auf ein Synology-System oder umgekehrt. Hier unterscheiden sich die Implementierungen der POSIX-ACLs teils erheblich. In solchen Fällen empfiehlt sich ein dreistufiges Vorgehen: Erst die Standard-Unix-Berechtigungen (Owner, Group, Other) übertragen, dann die erweiterten POSIX-ACLs abbilden und abschließend die Freigabeebene (SMB/NFS) separat konfigurieren. Der Versuch, alles in einem Schritt zu übertragen, endet häufig in inkonsistenten Berechtigungen, die sich nur schwer diagnostizieren lassen.

Warm-Cutover-Strategien zur Minimierung von Ausfallzeiten

In den meisten Produktionsumgebungen ist eine vollständige Downtime über mehrere Stunden oder gar Tage keine Option. An dieser Stelle kommen Warm-Cutover-Strategien ins Spiel – also Verfahren, bei denen die Daten im Hintergrund vorgespult werden und nur ein kurzes Umschaltfenster den eigentlichen Wechsel markiert. Eine netzwerkspeicher upgrade strategie lebt von dieser Trennung: lange Übertragung im Hintergrund, kurze Unterbrechung im Vordergrund.

Das Prinzip ist einfach, aber wirkungsvoll: In einer ersten Phase, der Pre-Sync-Phase, werden alle Daten vom Quell- auf das Zielsystem übertragen. In dieser Phase können die Benutzer noch ganz normal mit dem Quellsystem arbeiten. Erst im finalen Cutover-Fenster wird der Schreibzugriff auf der Quelle gesperrt, die letzten Änderungen werden synchronisiert, und die Clients werden auf das Zielsystem umgestellt. Dieses Vorgehen trennt das Risiko sauber vom laufenden Betrieb.

Der Warm-Cutover trennt das Risiko vom Betrieb: Lange Übertragungen laufen unsichtbar im Hintergrund, der eigentliche Ausfall bleibt auf Minuten begrenzt.

Für die Zeitplanung ist die Abschätzung der tatsächlichen Übertragungsgeschwindigkeit entscheidend. Eine Faustregel hilft bei der Orientierung: Bei einer anhaltenden Übertragungsrate von 100 MB/s benötigen 8 TB Daten rund 22 Stunden. In der Praxis liegen die Werte je nach Netzwerkanbindung, Dateigröße und Auslastung oft niedriger – eine konservative Schätzung mit Sicherheitspuffer ist daher empfehlenswert. Wer mit einer übermütigen Schätzung in das Wochenende geht, erlebt am Montag eine unangenehme Überraschung.

Ein Aspekt, der bei der Geschwindigkeitsberechnung oft vernachlässigt wird, ist die Art der Daten selbst. Viele kleine Dateien – etwa Quellcode-Repositories, Benutzerprofile oder Dokumentenablagen – erzeugen bei der Übertragung deutlich mehr Overhead als wenige große Containerdateien. Der Grund liegt in den Protokoll-Overhead pro Datei, den Metadaten-Zugriffen und den Latenzen beim Anlegen jeder einzelnen Datei auf dem Zielsystem. In solchen Szenarien kann die effektive Übertragungsrate auf ein Drittel der nominellen Netzwerkbandbreite sinken. Diese Differenz sollte bei der Planung des Migrationsfensters unbedingt einkalkuliert werden.

Die Pre-Sync-Phase sollte mehrfach durchgeführt werden, damit die Datenmenge im finalen Cutover-Fenster möglichst klein bleibt. Idealerweise wird im letzten Lauf vor dem Cutover nur noch ein Bruchteil der Daten übertragen – typischerweise die Änderungen der letzten Stunden. Das Cutover-Fenster selbst lässt sich dann oft auf 15 bis 60 Minuten begrenzen.

Während des Cutovers sind folgende Punkte zwingend zu beachten:

• Schreibsperre auf der Quelle: Sobald das Cutover-Fenster beginnt, darf auf dem Quellsystem nicht mehr geschrieben werden. Eine kurze, klar kommunizierte Downtime ist unvermeidlich – sie sollte aber bewusst kurz gehalten und den Anwendern vorab angekündigt werden. Je nach NAS-Hersteller lässt sich die Schreibsperre unterschiedlich granular setzen: Manche Systeme erlauben eine Freigabe-für-Freigabe-Sperre, andere nur eine vollständige Volumen-Sperre. Diese Details müssen vorab geklärt sein.
• Finale Synchronisation: Die Delta-Daten werden in dieser Phase übertragen und mit Prüfsummen verifiziert.
• DNS- oder IP-Umschaltung: Die Clients werden auf das Zielsystem umgestellt. Bei SMB-Freigaben erfolgt dies typischerweise über DNS-Aliasse oder die Anpassung der DFS-Namespaces, sodass bestehende UNC-Pfade weiterhin funktionieren. Dieser Punkt ist kritisch: Werden die UNC-Pfade hart auf die IP des Quell-NAS referenziert – etwa in Anwendungskonfigurationen, Skripten oder gemounteten Laufwerken –, reicht ein DNS-Alias allein nicht aus. Eine gründliche Inventur aller Stellen, die auf das Quellsystem verweisen, gehört daher zwingend in die Vorbereitung.
• Smoke-Test: Unmittelbar nach der Umschaltung werden die kritischen Anwendungen und Freigaben auf Funktion und Performance geprüft, bevor die breite Nutzergruppe zugreift. Ein Smoke-Test sollte nicht nur die Verfügbarkeit der Freigaben prüfen, sondern auch die Performance unter realistischer Last. Ein einfacher Test: Eine repräsentative Datei kopieren, eine Datenbank-Abfrage ausführen, ein typisches Anwender-Szenario durchspielen. Auffällige Performance-Abweichungen gegenüber dem Quellsystem deuten auf Fehlkonfigurationen hin, die sich im laufenden Betrieb deutlich schwerer diagnostizieren lassen.

Risikomanagement bei Hardware-Migration und RAID-Rebuilds

Nicht jede NAS-Migration ist eine reine Datenmigration. Häufig werden neue Gehäuse angeschafft, in denen die vorhandenen oder neue Festplatten in einem RAID-Verbund laufen sollen. An dieser Stelle lauern Risiken, die in der Hektik des Projekts leicht übersehen werden.

Ein häufiger Wunsch aus dem Support: „Wir tauschen die Platten einfach im laufenden Betrieb gegen größere aus." Das klingt nach einer unkomplizierten Kapazitätserweiterung, ist aber mit Risiken verbunden. Bei einem In-Place-Festplattentausch wird das RAID-Array während des Rebuilds im degradierten Zustand betrieben – also ohne eine der vorhandenen Redundanzen. Dieser Zustand hält unterschiedlich lange an, je nach gewähltem RAID-Level:

Während dieser Phase ist das Array anfällig für einen weiteren Plattenausfall. Bei RAID 5 bedeutet ein zweiter Defekt den Totalverlust der Daten – bei RAID 6 ist ein zweiter Defekt noch verkraftbar, ein dritter nicht mehr. RAID 10 bietet hier die kürzeste Rebuild-Zeit und damit das geringste Zeitfenster für einen Folgeausfall, weshalb es bei geschäftskritischen Volumes oft die robustere Wahl ist.

Was viele nicht wissen: RAID ist kein Backup. RAID schützt vor dem Ausfall einer einzelnen Platte, nicht vor versehentlichem Löschen, Ransomware oder einem Dateisystemfehler. Vor jeder größeren Migrationsaktion sollte daher ein separates, externes Backup existieren, auf das im Notfall zurückgegriffen werden kann. Dieser Grundsatz klingt banal, wird aber in der Praxis regelmäßig ignoriert – insbesondere dann, wenn die Migration unter Zeitdruck steht und das Backup-System anderweitig belegt ist. Wer die Migration ohne Backup beginnt, spielt Roulette mit dem gesamten Datenbestand des Unternehmens.

Bei der Migration zwischen NAS-Systemen desselben Herstellers – etwa innerhalb der Synology-Familie – ist die Kompatibilität der DSM-Version zu beachten. Die DSM-Version auf dem Ziel-NAS muss mindestens der Version des Quell-NAS entsprechen, andernfalls können Pakete und Systemkonfigurationen nicht übernommen werden. Eine Migration auf ein neueres Modell mit einer älteren DSM-Version ist in der Regel nicht möglich und auch nicht empfehlenswert, da Funktionsumfang und Sicherheitspatches sonst nicht zur Verfügung stehen. Dieschlüsselfrage lautet daher: Vor dem physischen Umzug die Firmware des Quellsystems auf den neuesten Stand bringen, die Migration durchführen und erst dann das Zielsystem mit der aktuell verfügbaren DSM-Version initialisieren. Diese Reihenfolge vermeidet Kompatibilitätskonflikte, die sich im Nachhinein nur mit erheblichem Aufwand lösen lassen.

Ein Sonderfall, der in der Praxis immer wieder für Verwirrung sorgt: das sogenannte HDD Migration-Verfahren, bei dem die physischen Platten aus dem alten Gehäuse direkt in das neue eingebaut werden. Dieses Verfahren funktioniert bei einigen Herstellern zuverlässig – setzt aber voraus, dass das Zielsystem das Dateisystem und das RAID-Layout der Platten unterstützt. Wer hier ohne Vorab-Check loslegt, riskiert, dass das neue Gehäuse die Platten nicht erkennt oder das RAID als nicht konfiguriert meldet. Dieschlüsselfrage lautet: Ist das Zielsystem für die Migration der vorhandenen Platten freigegeben? Diese Information findet sich in den Kompatibilitätslisten des jeweiligen Herstellers – und dort sollte man vor dem Umbau nachgeschaut haben.

Präventive Best Practices für den Migrationsalltag

Die Erfahrung aus unzähligen Supportfällen zeigt: Was bei einer Migration schiefgeht, ist selten die Technik selbst, sondern die fehlende Vorbereitung. Die folgenden Best Practices haben sich bewährt, um typische Stolperfallen zu vermeiden:

1. Niemals ohne Backup migrieren. Auch wenn die neue Hardware als zuverlässig gilt – ein vollständiges Backup vor der Migration ist Pflicht. Wer ohne diese Absicherung arbeitet, nimmt ein Risiko in Kauf, das sich im Nachhinein kaum wieder gutmachen lässt. Das Backup sollte nicht nur existieren, sondern auch verifiziert sein: Ein Backup, das im Ernstfall nicht eingespielt werden kann, ist keines.

2. Konsistenzprüfungen nicht dem Zufall überlassen. Hash-Vergleiche und ACL-Audits sollten dokumentiert und im Migrationsprotokoll festgehalten werden. Im Streitfall ist die Dokumentation der einzige Beweis dafür, dass die Migration sauber verlaufen ist. Ein Migrationsprotokoll, das Datum, beteiligte Systeme, übertragenes Volumen, Prüfsummenergebnisse und Abweichungen enthält, kostet in der Erstellung eine halbe Stunde – kann aber im Schadensfall Tage an Fehlersuche ersparen.

3. Den Netzwerkpfad vorab testen. Die Migrationsbandbreite steht und fällt mit der Netzwerkanbindung. Ein vorab durchgeführter Performance-Test deckt Engpässe auf, bevor sie im Migrationsfenster zum Problem werden. Dabei sollte der Test nicht nur die reine Bandbreite messen, sondern auch die Latenz und die Paketverlustrate unter Last – denn beides beeinflusst die effektive Übertragungsrate bei kleinen Dateien erheblich.

4. Den Cutover nicht in die Hauptnutzungszeit legen. Auch wenn das Warm-Cutover-Verfahren die Downtime auf Minuten reduziert – diese Minuten sollten nicht mitten in der Hauptarbeitszeit liegen. Ein frühmorgens oder am Wochenende angesetztes Cutover-Fenster nimmt vielen Anwendern den Stress. Die Kommunikation an die Fachabteilungen sollte mindestens eine Woche vorher erfolgen – inklusive einer klaren Aussage darüber, welche Systeme betroffen sind und wie lange die Unterbrechung voraussichtlich dauert.

5. Nach der Migration nicht sofort die alten Platten löschen. Erfahrungsgemäß tauchen in den ersten Tagen nach einer Migration Anwenderfragen auf, die sich nur durch einen Blick auf die Quelldaten klären lassen. Die alten Datenträger sollten daher mindestens zwei bis vier Wochen als Read-Only-Bereitstellung erhalten bleiben, bevor sie endgültig gelöscht oder neu initialisiert werden. In dieser Übergangsphase lohnt es sich, die Zugriffshäufigkeit auf das Quellsystem zu protokollieren: Sinkt sie innerhalb der ersten Woche auf null, kann die Aufbewahrungsfrist verkürzt werden – ein wirtschaftliches Argument, das sich gegenüber dem Management leicht vertreten lässt.

Eine Migration ist am Ende immer auch eine Übung in Disziplin. Wer die Phasen – Bestandsaufnahme, Bereinigung, Übertragung mit Integritätsprüfung, ACL-Übernahme, Warm-Cutover und Nachkontrolle – konsequent durchläuft, hat am Ende nicht nur ein neues NAS, sondern ein System, dem die Anwender genauso vertrauen wie dem alten. Genau das ist das Ergebnis, das jede geplante Migration verdient – und das ist am Schreibtisch des Kunden oft der Moment, in dem aus einem unterbrochenen Support-Ticket ein gelungenes Wochenendprojekt wird.