Eine Storage-Migration ist mehr als das Kopieren von Daten auf ein neues Speichersystem. Anwendungen, Abhängigkeiten, Performance-Anforderungen, Netzwerkpfade, Berechtigungen und Wiederherstellungsprozesse müssen vor dem Wechsel geprüft werden.
Die wichtigsten Punkte sind:
Eine Storage-Migration sollte als Infrastrukturprojekt und nicht als reiner Datentransfer betrachtet werden. Beim Wechsel eines Storage-Systems müssen Daten nicht nur auf einem neuen Ziel verfügbar sein. Auch Anwendungen, Hosts, Virtualisierung, Netzwerk, Berechtigungen, Backup, Disaster Recovery und Monitoring müssen anschließend wie vorgesehen funktionieren.
Microsoft empfiehlt deshalb bereits in der Assessment-Phase, Datenquellen, Zugriffsmuster, Performance-Anforderungen, Änderungsraten, Resilienz, Sicherheitsanforderungen und tolerierbare Ausfallzeiten systematisch zu erfassen. Je geschäftskritischer die Anwendungen sind, desto wichtiger wird diese Vorbereitung.
Storage-Migrationen sind komplex, weil Daten meist Teil einer größeren Abhängigkeitskette sind.
Ein Volume kann beispielsweise von mehreren virtuellen Maschinen genutzt werden. Diese wiederum hängen von Datenbanken, Netzwerkdiensten, Backup-Prozessen, Monitoring oder anderen Anwendungen ab. Eine Änderung auf Storage-Ebene kann deshalb Auswirkungen weit oberhalb der eigentlichen Speicherschicht haben.
Vor einer Migration sollten unter anderem folgende Bereiche geklärt sein:
Auch Microsoft nennt unter anderem Netzwerkverbindungen, Berechtigungen, Quell- und Zielsysteme sowie Backup und Systemzustand als zentrale Punkte für die Vorbereitung einer Storage-Migration.
Die technischen Risiken unterscheiden sich je nach Infrastruktur. Vier Bereiche treten jedoch besonders häufig auf.
Downtime entsteht vor allem beim finalen Umschalten vom alten auf das neue Storage-System.
Der reine Datentransfer kann häufig bereits erfolgen, während Anwendungen weiterlaufen. Schwieriger ist der sogenannte Cutover. Dabei wird der produktive Zugriff vom bisherigen Speicherziel auf das neue System umgestellt. Wie viel Downtime dafür notwendig ist, hängt unter anderem von folgenden Faktoren ab:
Bei Microsofts Storage Migration Service beispielsweise hängt die Dauer des Cutovers unter anderem vom Neustart der beteiligten Server sowie von Active-Directory- und DNS-Replikation ab. Eine allgemeingültige Aussage wie „eine Storage-Migration verursacht keine Ausfallzeit“ wäre deshalb nicht belastbar.
Eine Migration kann gleichzeitig das Quell-Storage, das Zielsystem und das Netzwerk belasten.
Werden große Datenmengen mit maximal möglicher Geschwindigkeit übertragen, konkurriert die Migration möglicherweise mit produktiven Anwendungen um Ressourcen.
Deshalb sollten vorab unter anderem folgende Werte bekannt sein:
Microsoft empfiehlt ausdrücklich, Zugriffsmuster, Read-/Write-Verhältnis, IOPS, Durchsatz sowie saisonale oder kurzfristige Lastspitzen in die Migrationsbewertung einzubeziehen.
Eine Migration sollte daher nicht nur hinsichtlich ihrer Geschwindigkeit überwacht werden. Auch die Auswirkungen auf produktive Workloads müssen betrachtet werden.
Nicht erkannte Abhängigkeiten gehören zu den häufigsten Ursachen für Überraschungen beim Cutover.
Dazu können gehören:
Gerade bei historisch gewachsenen Umgebungen stimmt die vorhandene Dokumentation nicht immer vollständig mit dem tatsächlichen Betrieb überein.
Eine aktuelle Bestandsaufnahme ist deshalb wichtiger als eine alte Architekturzeichnung.
Nach einer Migration muss nachweisbar sein, dass die benötigten Daten vollständig und korrekt verfügbar sind.
Der erfolgreiche Abschluss eines Kopiervorgangs reicht dafür nicht aus.
Je nach Workload können beispielsweise erforderlich sein:
Microsoft empfiehlt bei Storage-Migrationen unter anderem die Prüfung des Dateisystemzustands von Quelle und Ziel sowie ein aktuelles und getestetes Backup oder Snapshot.
Die Analyse sollte bei den geschäftskritischen und technisch komplexen Workloads beginnen. Migriert werden sollten diese jedoch nicht zwangsläufig zuerst.
Das ist ein wichtiger Unterschied. Ein Tier-1-Datenbanksystem sollte früh analysiert werden, weil seine Anforderungen Einfluss auf Architektur und Migrationsverfahren haben. Für einen ersten produktiven Migrationstest eignet sich dagegen häufig ein weniger kritischer Workload.
Eine sinnvolle Klassifizierung berücksichtigt mindestens:
| Kriterium | Zu klärende Frage |
| Geschäftskritikalität | Welche Folgen hätte ein Ausfall? |
| Datenvolumen | Wie viele Daten müssen tatsächlich übertragen werden? |
| Änderungsrate | Wie stark verändern sich die Daten während der Migration? |
| Performance | Welche IOPS, Latenz und welcher Durchsatz werden benötigt? |
| Verfügbarkeit | Welche Downtime ist akzeptabel? |
| Abhängigkeiten | Welche anderen Systeme benötigen den Workload? |
| Datenschutz | Gibt es besondere regulatorische Anforderungen? |
| Recovery | Welche RPO1– und RTO2-Werte gelten? |
1RPO steht für Recovery Point Objective. Der Wert beschreibt, wie viel Datenverlust zeitlich maximal akzeptabel ist.
2RTO bedeutet Recovery Time Objective. Es beschreibt, wie schnell ein Dienst nach einem Ausfall wieder verfügbar sein muss.
Eine gute Migrationsstrategie teilt den Wechsel in kontrollierbare Phasen.
Ein Big-Bang-Wechsel aller Systeme gleichzeitig erhöht die Zahl der Variablen während des Cutovers. In vielen Umgebungen ist deshalb eine schrittweise Vorgehensweise sinnvoll.
1. Umgebung erfassen
Zunächst werden Storage-Systeme, Volumes, Hosts, Protokolle, Anwendungen und Abhängigkeiten dokumentiert.
2. Anforderungen definieren
Für jeden relevanten Workload werden Performance, Verfügbarkeit, Kapazität, RPO, RTO und zulässige Downtime definiert.
3. Zielarchitektur planen
Anschließend wird festgelegt:
4. Pilotmigration durchführen
Ein repräsentativer, aber kontrollierbarer Workload eignet sich für die erste Migration. Dabei lassen sich Prozesse, Performance und Dokumentation überprüfen.
5. Daten vorab übertragen
Wo technisch möglich, werden große Datenmengen bereits vor dem eigentlichen Cutover übertragen.
6. Änderungen synchronisieren
Bei aktiven Datenbeständen müssen Änderungen zwischen Quelle und Ziel bis zum Cutover berücksichtigt werden. Microsoft unterscheidet deshalb beispielsweise zwischen statischen Daten, bei denen eine einmalige Kopie ausreichen kann, und dynamischen Datenbeständen, für die inkrementelle Synchronisationen und ein abschließendes Cutover-Fenster geplant werden sollten.
7. Cutover durchführen
Erst jetzt erfolgt die produktive Umschaltung.
8. Validieren
Nach dem Cutover werden Anwendungen, Datenintegrität, Berechtigungen, Backup und Performance kontrolliert.
9. Altsystem nicht sofort entfernen
Das bisherige Storage-System sollte erst außer Betrieb genommen werden, wenn die neue Umgebung ausreichend validiert wurde und die definierten Rückfallmöglichkeiten nicht mehr benötigt werden.
Die Dauer einer Storage-Migration lässt sich nicht allein aus der Datenmenge ableiten.
Das Datenvolumen ist lediglich ein Faktor.
Weitere Einflussgrößen sind:
Die theoretische Übertragungsdauer eines Datenbestands lässt sich zwar aus Datenmenge und nutzbarem Durchsatz abschätzen.
Die gesamte Projektdauer umfasst jedoch deutlich mehr:
Analyse → Aufbau → Tests → initiale Datenübertragung → Synchronisation → Cutover → Validierung
Gerade bei laufenden Produktionssystemen kann daher nicht aus „X Terabyte Daten“ automatisch eine belastbare Migrationsdauer abgeleitet werden.
Ausfallzeiten lassen sich vor allem reduzieren, indem möglichst viel Arbeit vor dem eigentlichen Cutover durchgeführt wird.
Dazu gehören:
Auch die jeweilige Plattform kann eine Rolle spielen.
Bei VMware kann beispielsweise Storage vMotion geeignete virtuelle Maschinen im laufenden Betrieb zwischen Datastores verschieben. Eine Everpure-Dokumentation beschreibt, dass VMs bei einer Migration von VMFS- oder NFS-Datastores mittels Storage vMotion online bleiben können. Bei anderen Speicherformen wie RDMs kann dagegen zusätzliche Downtime erforderlich sein. Das zeigt: Die richtige Migrationsmethode hängt stark vom jeweiligen Workload ab.
Eine Migration sollte niemals der einzige vorhandene Weg zu den Daten sein.
Vor dem Cutover muss deshalb festgelegt werden, wie der vorherige Zustand wiederhergestellt werden kann.
Eine Rollback-Strategie beantwortet mindestens folgende Fragen:
Zusätzlich sollte ein aktuelles und getestetes Backup vorhanden sein. Microsoft nennt ein getestetes, aktuelles Backup oder einen Snapshot ausdrücklich als Bestandteil der Vorbereitung einer Storage-Migration. Ein vorhandenes Backup allein genügt allerdings nicht. Entscheidend ist, ob auch der Restore-Prozess funktioniert und innerhalb der geforderten RTO durchgeführt werden kann.
Eine Migration auf Everpure FlashArray beginnt mit denselben Grundfragen wie jede andere Storage-Migration: Workloads, Protokolle, Performance, Abhängigkeiten und Cutover müssen zuerst verstanden werden.
Everpure ist seit Februar 2026 der neue Name des früheren Herstellers Pure Storage. Viele technische Dokumentationen sind deshalb weiterhin unter Pure Storage veröffentlicht.
FlashArray ist die All-Flash-Storage-Plattform von Everpure für Block- und je nach Konfiguration auch weitere Storage-Anforderungen. Wir setzen FlashArray unter anderem für Datenbanken, Virtualisierung und andere geschäftskritische Workloads ein. Unsere aktuelle Everpure-Seite beschreibt FlashArray ebenfalls als Plattform für Datenbanken, virtuelle Maschinen, Container und weitere Enterprise-Anwendungen.
Der konkrete Migrationsweg hängt von der vorhandenen Umgebung ab.
Beispiele sind:
In VMware-Umgebungen kann beispielsweise Storage vMotion eingesetzt werden, wenn die technischen und lizenzrechtlichen Voraussetzungen erfüllt sind. Für Disaster-Recovery-Szenarien stellt FlashArray mit ActiveDR zudem kontinuierliche Replikationsfunktionen bereit. Laut technischer Everpure-Dokumentation hängt das erreichbare RPO dabei unter anderem von Workload, Netzwerkbandbreite und Schreiblast ab. ActiveDR ist damit jedoch nicht automatisch die passende Lösung für jede Storage-Migration. Die Migration muss anhand der bestehenden Infrastruktur geplant werden.
Evergreen soll verhindern, dass jeder technologische Refresh automatisch zu einem vollständigen Austausch des Storage-Systems mit erneuter Datenmigration wird.
Das unterscheidet Evergreen von klassischen „Forklift Upgrades“. Bei einem klassischen Storage-Lifecycle wird häufig nach einigen Jahren ein neues System parallel aufgebaut. Anschließend werden Daten erneut vom alten auf das neue Array migriert.
Die Evergreen-Architektur von Everpure ist dagegen auf modulare und generationsübergreifende Upgrades ausgelegt. Everpure beschreibt die Architektur so, dass Controller und weitere Komponenten während des laufenden Betriebs aktualisiert werden können. Der Hersteller spricht von generationsübergreifenden, nicht-disruptiven Upgrades und Daten, die dabei auf dem bestehenden System verbleiben.
Das bedeutet für die langfristige Planung:
Wichtig ist jedoch die Abgrenzung:
Evergreen ersetzt nicht die erstmalige Migration von einer bestehenden Fremdplattform auf FlashArray.
Außerdem hängen konkrete Upgrade-Rechte und Leistungen vom gewählten Evergreen-Modell und Vertrag ab. Evergreen//One ist beispielsweise ein Storage-as-a-Service-Modell. Evergreen//Forever verfolgt dagegen ein anderes Beschaffungs- und Lifecycle-Modell.
Als Concat betrachten wir eine Storage-Migration nicht isoliert als Kopierjob, sondern als Veränderung der gesamten Infrastruktur rund um die betroffenen Workloads.
Unsere Aufgabe beginnt deshalb vor dem eigentlichen Datentransfer.
Wir betrachten beispielsweise:
Auf dieser Grundlage kann ein Migrationsplan mit definierten Phasen, Tests und Cutover-Schritten entstehen.
Bei einer Everpure-Umgebung unterstützen wir Sie von der Konzeption über die Integration bis zur Weiterentwicklung der Plattform. Concat ist Everpure Elite Partner. Unsere aktuelle Partnerseite nennt insbesondere Beratung und Architektur, Integration in bestehende IT-Landschaften sowie Betrieb und Weiterentwicklung über den Lifecycle als Schwerpunkte unserer Zusammenarbeit mit Everpure.
Für das eigentliche Migrationsprojekt bedeutet das: Die Storage-Plattform wird nicht losgelöst von Ihrer vorhandenen IT betrachtet. Vor dem produktiven Cutover sollten Zielumgebung und ausgewählte Workloads getestet werden. Nach der Migration müssen Datenzugriff, Anwendungen, Performance sowie Backup- und Recovery-Prozesse kontrolliert werden.
Vor dem Start eines Migrationsprojekts sollten Sie mindestens folgende Punkte beantworten können:
Eine Migration sollte erst beginnen, wenn diese Fragen nicht nur technisch, sondern auch organisatorisch geklärt sind.
Eine erfolgreiche Storage-Migration beginnt nicht mit dem Kopieren der ersten Daten, sondern mit einer vollständigen Analyse der bestehenden Umgebung.
Workloads, Abhängigkeiten, Performance-Anforderungen, Verfügbarkeit, Backup und Rollback müssen vor dem Cutover bekannt sein. Besonders geschäftskritische Systeme benötigen einen eigenen Migrations- und Testplan.
Bei einem Wechsel auf Everpure FlashArray kommt ein weiterer strategischer Aspekt hinzu: Durch die Evergreen-Architektur können spätere Technologie-Refreshes anders organisiert werden als bei klassischen Storage-Systemen, bei denen regelmäßig ein vollständiger Austausch mit erneuter Datenmigration erforderlich sein kann.
Als Concat unterstützen wir Sie dabei, die bestehende Umgebung zu analysieren, die Zielarchitektur zu planen und Everpure in Ihre vorhandene IT-Landschaft zu integrieren. Entscheidend bleibt dabei immer der konkrete Workload – nicht eine pauschale Migrationsmethode.
Eine Storage-Migration ist die Übertragung von Daten und Workloads von einem bestehenden Speichersystem auf eine neue Storage-Plattform. Neben dem eigentlichen Datentransfer müssen auch Anwendungen, Hosts, Netzwerkverbindungen, Berechtigungen, Backup und Recovery berücksichtigt werden.
Die Dauer hängt von Datenmenge, nutzbarer Bandbreite, Datenänderungsrate, Workloads, Migrationsverfahren und Testaufwand ab. Aus der reinen Speicherkapazität lässt sich deshalb keine verlässliche Projektdauer ableiten.
Ein Rollback-Plan ermöglicht die Rückkehr zur bisherigen Umgebung, wenn beim Cutover kritische Probleme auftreten. Er sollte festlegen, wann ein Abbruch erfolgt, wie Daten behandelt werden und welche technischen Änderungen rückgängig gemacht werden müssen.
Downtime lässt sich reduzieren, indem Daten vorab übertragen, Änderungen anschließend synchronisiert und Zielsysteme bereits vor dem Cutover vollständig konfiguriert und getestet werden. Welche Verfahren möglich sind, hängt vom jeweiligen Workload und der Plattform ab.
Für einen ersten produktiven Migrationstest eignen sich häufig weniger kritische, aber technisch repräsentative Workloads. Geschäftskritische Systeme sollten dagegen bereits früh analysiert werden, damit ihre Anforderungen in die Zielarchitektur einfließen.
Vor einer Migration auf Everpure FlashArray müssen vorhandene Workloads, Storage-Protokolle, Hosts, Virtualisierung, Performance und Verfügbarkeitsanforderungen analysiert werden. Anschließend wird für jeden Workload ein geeigneter Migrationsweg ausgewählt.
Evergreen ermöglicht bei unterstützten Szenarien generationsübergreifende Hardware- und Software-Upgrades, ohne dass dafür jedes Mal ein vollständiger Austausch des Storage-Systems mit anschließender Datenmigration notwendig ist. Die erstmalige Migration auf FlashArray bleibt davon unabhängig.
Das bisherige Storage-System sollte erst außer Betrieb genommen werden, wenn Datenintegrität, Anwendungen, Performance, Backup und Recovery der neuen Umgebung erfolgreich geprüft wurden und kein operativer Rollback mehr erforderlich ist.
Sie müssen den Inhalt von reCAPTCHA laden, um das Formular abzuschicken. Bitte beachten Sie, dass dabei Daten mit Drittanbietern ausgetauscht werden.
Mehr InformationenSie müssen den Inhalt von Turnstile laden, um das Formular abzuschicken. Bitte beachten Sie, dass dabei Daten mit Drittanbietern ausgetauscht werden.
Mehr Informationen