Teststrategie für die Cloud-Migration: Phasen, Testarten und Checkliste
Eine Teststrategie für die Cloud-Migration legt fest, was Sie vor, während und nach jeder Migrationswelle testen und mit welchen Pass/Fail-Kriterien entschieden wird, ob ein Workload live geht. Sie deckt Funktion, Datenintegrität, Performance, Security und Rollback ab. Die Methode: Baseline auf der alten Plattform messen, eine Testmigration durchführen, vergleichen und erst umschalten, wenn die Zahlen übereinstimmen.
Das Wichtigste in Kürze
- Erfassen Sie Baselines, bevor Sie etwas verschieben: Antwortzeiten, Fehlerraten, Laufzeiten von Batch-Jobs und Zeilenzahlen.
- Legen Sie Pass/Fail-Kriterien und Rollback-Auslöser vor der ersten Welle fest, nicht erst während der Umschaltung.
- Nutzen Sie die Testfunktionen der Migrationswerkzeuge: Testmigrationen in Azure Migrate und die Datenvalidierung von AWS DMS gibt es genau dafür.
- Die Testarten skalieren mit dem Migrationspfad. Ein Lift-and-Shift braucht vor allem Paritätsprüfungen; ein Refactoring braucht vollständige Funktions- und Integrationstests.
- Führen Sie Testmigrationen in einem isolierten Netzwerk durch. Microsoft rät von Testmigrationen in ein produktives virtuelles Netzwerk ab.
- Testen Sie auch nach der Umschaltung weiter: Beobachten Sie Service Level Indicators (SLIs) mindestens über einen vollständigen Geschäftszyklus.
Was ist Cloud-Migrationstesting?
Cloud-Migrationstesting ist die Gesamtheit der Prüfungen, die belegen, dass eine Anwendung, ihre Daten und ihre Infrastruktur nach dem Umzug mindestens so gut funktionieren wie davor. Es läuft über die gesamte Migration, nicht nur am Ende.
Es unterscheidet sich in drei Punkten vom üblichen Release-Testing:
- Die Plattform ändert sich, nicht der Code. Beim Lift-and-Shift bleibt der Code gleich, also testen Sie die Umgebung: Netzwerk, Identität, Storage-Performance, DNS und Zeitzonen.
- Daten ziehen um. Sie müssen belegen, dass jede Zeile und jede Datei unverändert angekommen ist und dass laufende Änderungen bis zur Umschaltung weiter synchronisiert wurden.
- Die Cloud verhält sich anders. Autoscaling, Limits verwalteter Services, regionale Latenz und geteilte Infrastruktur können die Performance verändern, selbst wenn sich sonst nichts geändert hat.
Die Erfolgskriterien bleiben dieselben wie im eigenen Rechenzentrum: Funktionen müssen laufen, Daten vollständig und korrekt sein, und Nutzer dürfen keinen Geschwindigkeitsverlust bemerken.
Die vier Phasen einer Teststrategie für die Migration
Teilen Sie das Testen in vier Phasen auf, jede mit eigenen Nachweisen und eigener Freigabe.
| Phase | Ziel | Wichtigste Prüfungen | Nachweis |
|---|---|---|---|
| 1. Planung und Baseline | Wissen, wie „gut“ heute aussieht | Abhängigkeitskarte, kritische Nutzerpfade, aktuelle Antwortzeiten, Batch-Dauern, Datenvolumen | Baseline-Bericht, vereinbarte Pass/Fail-Kriterien |
| 2. Testmigration | Belegen, dass der Workload auf dem Ziel läuft | Start und Konnektivität, funktionale Smoke-Tests, Integrationen, Datenvalidierung, Performance unter Last | Testergebnisse pro Workload, Fehlerliste |
| 3. Umschaltung | Sicher umschalten, mit Weg zurück | Letzte Datensynchronisation und Validierung, DNS- und Zertifikatsprüfung, Smoke-Tests, Go/No-go | Cutover-Runbook mit Zeiten, unterzeichnetes Go/No-go |
| 4. Nach der Migration | Stabilität bestätigen und optimieren | SLI-Monitoring, Abnahme durch Anwender, Backup- und Restore-Test, Kostencheck | Hypercare-Bericht, geschlossene Fehler |
Phase 1: Planung und Baseline
Beginnen Sie mit einem Inventar der Anwendungen, Datenbanken, Schnittstellen und geplanten Jobs und ordnen Sie diese nach Geschäftsrisiko. Halten Sie für jeden Workload die Zahlen fest, mit denen Sie später vergleichen: p95-Antwortzeit wichtiger Transaktionen, Fehlerrate, Dauer des nächtlichen Batch-Laufs, Datenbankgröße und Zeilenzahlen.
Machen Sie daraus Kriterien. Zum Beispiel: „p95 der Bestellsuche innerhalb von 10 % der Baseline“, „keine Abweichungen in den Finanztabellen“, „nächtlicher Batch endet vor 06:00 Uhr“. Das SRE-Buch von Google definiert einen SLI als „a carefully defined quantitative measure of some aspect of the level of service“ und ein SLO als Zielwert dafür (Google SRE book). Formulieren Sie Ihre Kriterien in dieser Form, wird die Go/No-go-Entscheidung objektiv.
Phase 2: Testmigration
Migrieren Sie eine Kopie des Workloads ins Ziel und testen Sie dort, während die Quelle weiterläuft. Beide großen Plattformen unterstützen das:
- Azure Migrate bietet eine Testmigration, die replizierte VMs in einem von Ihnen gewählten virtuellen Netzwerk startet. Laut Microsofts Leitfaden wird eine Testmigration in ein produktives virtuelles Netzwerk nicht empfohlen, weil offene Verbindungen ins eigene Rechenzentrum doppelte VMs oder DNS-Änderungen verursachen können.
- AWS Application Migration Service (MGN) startet Test-Instanzen aus kontinuierlich replizierten Servern, und die Replikation läuft nach dem Test weiter. AWS nennt es eine Best Practice, mindestens zwei Wochen vor der geplanten Umschaltung zu testen, damit Zeit bleibt, Gefundenes zu beheben.
Nutzen Sie diese Phase, um die Überraschungen zu finden: fest eincodierte IP-Adressen, fehlende Firewall-Regeln, an Hardware gebundene Lizenzprüfungen und Jobs, die Server aufrufen, die Sie zu migrieren vergessen haben.
Phase 3: Umschaltung
Die Umschaltung ist ein geprobtes Runbook und keine Improvisation. Änderungen einfrieren, letzte Datensynchronisation durchführen, Daten validieren, DNS- oder Load-Balancer-Ziele umstellen und Smoke-Tests laufen lassen. Jeder Schritt hat einen Verantwortlichen, eine geplante Zeit und eine Rollback-Aktion.
Legen Sie Rollback-Auslöser im Voraus fest, zum Beispiel: „Schlagen Smoke-Tests fehl oder zeigt die Datenvalidierung 60 Minuten nach dem Umschalten Abweichungen, wird DNS auf die Quelle zurückgesetzt.“ Proben Sie das Rollback mindestens einmal während der Testmigrationen.
Phase 4: Validierung nach der Migration
Vergleichen Sie nach dem Go-live die SLIs mindestens über einen vollständigen Geschäftszyklus mit der Baseline, nach Möglichkeit inklusive Monatsende oder Spitzentagen. Führen Sie Abnahmetests durch, testen Sie eine Wiederherstellung aus den neuen Backups und vergleichen Sie die erste Cloud-Rechnung mit der Schätzung. Erst dann nehmen Sie die Quelle außer Betrieb.
Welche Testarten sollten Sie durchführen?
Stimmen Sie die Testarten auf das Risiko des jeweiligen Workloads ab. Nicht jede Anwendung braucht jeden Test.
| Testart | Was sie belegt | Typische Tools |
|---|---|---|
| Funktional und Regression | Funktionen und Nutzerpfade laufen weiterhin | Selenium, Playwright, vorhandene Testsuiten |
| Integration | APIs, Message Queues, Dateitransfers und Drittanbieter-Services verbinden sich | Contract-Tests, API-Testwerkzeuge, synthetische Transaktionen |
| Datenvalidierung | Jede Zeile und jede Datei ist angekommen und stimmt überein | AWS DMS Data Validation, Prüfsummen, Zeilenzahlen, Datenbank-Diff-Tools |
| Performance und Last | Antwortzeiten und Durchsatz erreichen die Ziele, Autoscaling funktioniert | JMeter, k6, Gatling |
| Security und Compliance | Zugriffe, Verschlüsselung, Netzwerkregeln und Logging sind korrekt | Cloud-Security-Posture-Tools, Schwachstellenscans, IAM-Reviews |
| Resilienz und DR | Der Workload übersteht Ausfälle und lässt sich wiederherstellen | Failover-Übungen, Backup-Restores, AWS Fault Injection Service |
| Abnahme durch Anwender | Fachanwender bestätigen, dass das System einsatzfähig ist | Skriptgestützte UAT mit Freigabe |
Für realistische Lasttests, die Ihrem Spitzenverkehr entsprechen, siehe unseren Lasttest-Service.
Wie validieren Sie Daten während einer Migration?
Validieren Sie Daten auf drei Ebenen: Zählungen, Prüfsummen und Zeile-für-Zeile-Vergleich für kritische Tabellen.
- Zählungen: Zeilen pro Tabelle, Dateien pro Bucket, Gesamtbytes. Schnell und findet grobe Fehler.
- Prüfsummen und Aggregate: Summen von Beträgen, Hashes von Schlüsselspalten. Findet Abschneidungen und Kodierungsprobleme.
- Vergleich auf Zeilenebene: Bei Datenbanken vergleicht die Datenvalidierung von AWS DMS jede Quellzeile mit ihrer Zielzeile und meldet Abweichungen, auch bei Änderungen, die während der laufenden Replikation erfasst wurden.
Zwei praktische Einschränkungen aus der AWS-Dokumentation sollten Sie einplanen: Die Validierung braucht pro Tabelle einen Primärschlüssel oder einen eindeutigen Index, und sie erzeugt zusätzliche Abfragelast auf Quelle und Ziel. Planen Sie aufwendige Validierungsläufe außerhalb der Geschäftszeiten oder führen Sie sie als eigene reine Validierungs-Tasks aus.
Testen Sie auch, was sich absichtlich ändert. Wenn Sie von Oracle auf PostgreSQL konvertieren, unterscheiden sich Datentypen, Collation und Sortierreihenfolge, vergleichen Sie also Abfrageergebnisse und nicht nur gespeicherte Werte. Unser Datenbank-Migrationsservice deckt diese Konvertierungen ab.
Wie sich das Testen mit dem Migrationspfad ändert
- Rehost (Lift-and-Shift): Schwerpunkt auf Umgebungsparität. Prüfen Sie Netzwerk, DNS, Identität, Storage-Durchsatz, Backup-Jobs und Monitoring-Agenten. Funktionstests können ein Smoke-Test plus die kritischen Nutzerpfade sein.
- Replatform: Verlagern Sie eine Datenbank auf einen Managed Service oder eine Anwendung in Container, ergänzen Sie Datenvalidierung, Performance-Tests und Prüfungen der Limits verwalteter Services, etwa der Verbindungszahlen.
- Refactor: Behandeln Sie es wie neue Software. Führen Sie vollständige Funktions-, Integrations- und Performance-Tests durch und begrenzen Sie die Exposition mit Canary- oder Blue/Green-Releases und Feature Flags.
Checkliste für das Cloud-Migrationstesting
- Inventar und Abhängigkeitskarte für die Welle vollständig
- Baselines für kritische Nutzerpfade, Batch-Jobs und Datenvolumen erfasst
- Pass/Fail-Kriterien und Rollback-Auslöser vom Fachverantwortlichen freigegeben
- Testumgebung von Produktivnetzwerken isoliert
- Infrastruktur als Code definiert, damit Test und Produktion übereinstimmen (siehe unseren Terraform-Infrastructure-as-Code-Service)
- Testdaten maskiert, wenn sie personenbezogene Daten enthalten
- Testmigration durchgeführt, Fehler behoben und erneut getestet
- Datenvalidierung für alle Tabellen im Umfang bestanden
- Lasttest bei erwarteter Spitzenlast bestanden
- Security-Review abgeschlossen: IAM, Verschlüsselung, Security Groups, Logging
- Rollback geprobt und zeitlich gemessen
- Cutover-Runbook mit Verantwortlichen und Zeiten freigegeben
- Monitoring-Dashboards und Alarme für die Zeit nach der Migration live
- Backup-Restore auf der neuen Plattform getestet
Wie Opsio Ihnen hilft
Opsio plant und betreibt Cloud-Migrationen mit Tests in jeder Welle. Für SilverRail Technologies hat Opsio den nordischen Unternehmensteil auf AWS verlagert und mit der globalen Organisation zusammengeführt. Die Mobilize-Phase umfasste eine Pilot-Testmigration ausgewählter Workloads, und der Migrationsprozess sowie die AWS-Services wurden anhand dieser Tests angepasst. Die Daten wurden mit nativen PostgreSQL-Werkzeugen nach einem detaillierten Cutover-Plan verschoben, und die Umschaltungen liefen in engen Servicefenstern, um die Auswirkungen auf Kunden zu begrenzen. Lesen Sie die Fallstudie zu SilverRail.
Häufig gestellte Fragen
Was ist eine Teststrategie für die Cloud-Migration?
Ein Plan, der festlegt, welche Tests vor, während und nach jeder Migrationswelle laufen, welche Pass/Fail-Kriterien jeweils gelten und wer freigibt. Er deckt Funktion, Daten, Performance, Security und Rollback ab.
Welche Phasen hat das Cloud-Migrationstesting?
Planung und Baseline, Testmigration, Umschaltung und Validierung nach der Migration. Jede Phase liefert Nachweise, etwa Baseline-Berichte, Testergebnisse, ein unterzeichnetes Go/No-go und einen Hypercare-Bericht.
Wie testet man Daten nach einer Cloud-Migration?
Vergleichen Sie Zeilenzahlen und Prüfsummen aller Tabellen und führen Sie für kritische Daten Vergleiche auf Zeilenebene durch. Bei AWS vergleicht die DMS-Datenvalidierung Quell- und Zielzeilen und meldet Abweichungen; sie braucht pro Tabelle einen Primärschlüssel oder eindeutigen Index.
Wie unterscheidet sich das Testen bei Lift-and-Shift und Refactoring?
Ein Lift-and-Shift braucht vor allem Paritätsprüfungen der Umgebung und der kritischen Nutzerpfade, weil sich der Code nicht ändert. Ein Refactoring braucht vollständige Funktions-, Integrations- und Performance-Tests, da Sie praktisch neue Software ausliefern.
Wie lange sollte man nach der Umschaltung überwachen?
Mindestens einen vollständigen Geschäftszyklus, einschließlich Spitzentagen wie dem Monatsende, bevor Sie die Quellsysteme außer Betrieb nehmen. Halten Sie die Rollback-Option offen, bis die vereinbarten Kriterien erfüllt sind.
Über den Autor
Redaktionelle Standards: Dieser Artikel wurde von einer zertifizierten Fachperson verfasst, die oben als Autor genannt ist. Wir überarbeiten ihn, wenn sich die behandelte Technologie oder Regulierung ändert; die Daten oben zeigen die letzte Aktualisierung. Opsio ist redaktionell unabhängig — wir empfehlen Lösungen nach technischen Kriterien, nicht nach Geschäftsbeziehungen.