Cloud-Migration scheitert selten an der Technik
Sie scheitert an Abhängigkeiten, Lizenzmodellen und Anwendungen, die seit Jahren niemand angefasst hat.
In fast jeder Umgebung läuft eine Anwendung, deren Abhängigkeiten nirgends dokumentiert sind. Sie fällt erst auf, wenn der Server abgeschaltet werden soll. Solche Fälle bestimmen den Zeitplan einer Migration stärker als die Datenmenge.
Dazu kommen Lizenzen, die außerhalb der eigenen Hardware anders rechnen, und Hersteller, die Betrieb nur in bestimmten Umgebungen unterstützen. Wer das erst im Projekt klärt, verhandelt unter Zeitdruck.
Am teuersten ist die dritte Annahme: dass alles in die Cloud muss. Für einen Teil Ihrer Systeme geht die Rechnung auf, für einen anderen nicht. Welcher Teil das ist, entscheidet sich vor dem ersten Migrationsschritt.
Vier Migrationswege und wofür sie taugen
Wofür dieser Weg taugt
Lastspitzen, Test- und Entwicklungsumgebungen, Anwendungen mit schwankendem Bedarf und Standarddienste ohne besondere Auflagen. Umsetzung in Azure als IaaS oder PaaS, entweder als Verschiebung der bestehenden Systeme oder mit Umbau der Anwendung.
Was dagegen spricht
Dauerhaft ausgelastete Systeme werden in der Public Cloud teurer als im eigenen Rechenzentrum. Wer nur verschiebt und nichts umbaut, nimmt das Kostenmodell der alten Umgebung mit und zahlt es monatlich weiter.
Was AVENDIS übernimmt
Aufnahme der Abhängigkeiten, Zielarchitektur, Migration und Kostensteuerung im laufenden Betrieb. Danach läuft die Umgebung im Managed Service weiter. Mehr dazu auf der Seite Public Cloud.
Wofür dieser Weg taugt
Daten mit regulatorischen Auflagen und Anforderungen an Rechtsraum und Betreiber, etwa bei Betroffenheit durch NIS2, DORA oder KRITIS. Betrieb in deutschen Rechenzentren, auf Wunsch als Private Cloud in getrennter Umgebung.
Was dagegen spricht
Das Dienstangebot ist kleiner als bei den Hyperscalern und die Grundkosten liegen höher. Wer Managed-Dienste erwartet, die es dort nicht gibt, baut und betreibt sie selbst.
Was AVENDIS übernimmt
Einordnung der Auflagen, Auswahl der Plattform, Migration und die Dokumentation, die Sie bei Prüfungen vorlegen müssen. Mehr dazu auf der Seite Sovereign Cloud.
Wofür dieser Weg taugt
Exchange, Fileserver und Groupware, die aus der Wartung laufen. Von Exchange On-Premises nach Exchange Online über Cutover, Staged oder Hybrid, ebenso aus Google Workspace, Lotus Notes oder GroupWise. Bei Fusion und Carve-out als Tenant-zu-Tenant-Migration.
Was dagegen spricht
Die Migration selbst ist der kleinere Teil. Public Folder, Shared Mailboxes, gewachsene Freigaben und Zugriffe von Partnern bestimmen den Zeitplan, nicht die Datenmenge. Ohne Rechtekonzept und Anwenderakzeptanz wird die Umgebung danach kaum genutzt.
Was AVENDIS übernimmt
Bestandsaufnahme von Postfächern, Freigaben und Berechtigungen, Migration, Härtung des Tenants mit Conditional Access und MFA sowie Begleitung der Anwender. Welcher der drei Wege passt, steht im Vergleich unter Microsoft 365 Migration.
Wofür dieser Weg taugt
Anwendungen mit konstanter Last, harten Latenzanforderungen oder Herstellervorgaben, die den Betriebsort festlegen. Häufigster Fall ist die Modernisierung der Virtualisierung, etwa von VMware auf Proxmox VE.
Was dagegen spricht
Hardware, Wartung und Bereitschaft bleiben im Haus. Ohne Monitoring und geregelte Betriebsprozesse verschiebt sich das Risiko nur, statt kleiner zu werden.
Was AVENDIS übernimmt
Bewertung der Virtualisierungsplattform, Migration, Monitoring mit openITCOCKPIT und Betrieb als Managed Service. Mehr dazu auf der Seite Proxmox.
Der Weg entscheidet sich je Anwendung
Es gibt keine Cloud-Entscheidung, die für eine ganze Umgebung stimmt. In der Regel verteilen sich die Systeme auf zwei oder drei Zielumgebungen, und ein Teil bleibt, wo er ist. Wer sich auf einen Weg festlegt, bevor die Anwendungen bewertet sind, bezahlt die Festlegung später im Betrieb.
Ablauf einer Migration
Fünf Phasen, jede mit einem Ergebnis, das Sie prüfen können.
- Aufnahme der Umgebung: Anwendungen, Abhängigkeiten, Lizenzen, Datenmengen. Ergebnis ist eine Liste, keine Präsentation.
- Zielbild je Anwendung mit Begründung und Ausschlussgründen. Wir legen die Grundlage vor, entschieden wird bei Ihnen.
- Pilot mit einer abgegrenzten Anwendung. Verfahren, Rückfallweg und Zeitbedarf werden an einem echten Fall gemessen statt geschätzt.
- Migration in Wellen. Fachlich zusammenhängende Systeme wandern gemeinsam, jede Welle mit Rückfallweg und Abnahme.
- Übergang in den Betrieb. Monitoring, Erreichbarkeit und Dokumentation stehen, bevor das Projektteam abzieht.
Wer nach der Migration was tut
Die Zuständigkeit nach der Migration wird häufiger zum Streitpunkt als die Technik. Deshalb steht sie hier vor dem Projekt und nicht danach.
Häufige Fragen
Wie lange steht der Betrieb während der Migration still?
Für die meisten Systeme gar nicht. Migrationen laufen in Wellen, und die Umstellung je Welle liegt im vereinbarten Wartungsfenster. Wo eine Unterbrechung unvermeidlich ist, stehen Dauer und Rückfallweg vorher fest und werden von Ihnen freigegeben.
Was passiert mit Altdaten und Archiven?
Sie werden vor der Migration bewertet: was mitgenommen wird, was archiviert wird und was gelöscht werden kann. Aufbewahrungsfristen und die Entscheidung über Löschungen liegen bei Ihnen, wir liefern die Grundlage und setzen um.
Können wir eine Migration rückgängig machen?
Jede Welle hat einen definierten Rückfallweg mit einem Zeitfenster, in dem er gilt. Das Quellsystem bleibt für eine vereinbarte Frist bestehen. Nach Ablauf dieser Frist ist der Rückfall ein eigenes Vorhaben und kein Handgriff mehr.
Wird es in der Cloud günstiger?
Bei schwankender Last in der Regel ja, bei dauerhaft ausgelasteten Systemen in der Regel nicht. Entscheidend ist das Lastprofil je Anwendung, nicht der Durchschnitt über die gesamte Umgebung. Diesen Vergleich stellen wir vor der Entscheidung auf, nicht danach.
Erfüllen wir mit einer Cloud-Migration NIS2?
Nein. Eine Migration allein erfüllt keine Vorgabe. Sie kann Nachweise vereinfachen, etwa bei Protokollierung und Zugriffskontrolle, ersetzt aber weder Risikomanagement noch Meldeprozesse. Eine Einordnung finden Sie unter NIS2 Readiness.
Was passiert nach der Migration?
Die Umgebung geht in den Managed Service über. Monitoring, Ticketannahme und Betriebsdokumentation stehen zum Zeitpunkt der Übergabe. Wer Sie danach im Störungsfall erreicht, steht unter Direkt-Support.
Reden wir über Ihre Anwendungsliste
Bringen Sie mit, welche Systeme in den nächsten zwölf Monaten anstehen. Wir ordnen sie den Migrationswegen zu und sagen Ihnen, wo wir Aufwand sehen und wo nicht.
