Cloud-Migration klingt auf den ersten Blick nach einem klaren Modernisierungsschritt: Anwendungen und Server aus dem eigenen Rechenzentrum in die Cloud verschieben, Infrastruktur reduzieren und anschließend von mehr Flexibilität profitieren.
In der Praxis funktioniert dieser Plan nicht immer so einfach.
Gerade beim sogenannten Lift-and-Shift werden bestehende Systeme nahezu unverändert aus der lokalen Infrastruktur in eine Cloud-Umgebung übertragen. Das kann für bestimmte Workloads sinnvoll sein. Es kann aber ebenso dazu führen, dass Unternehmen ihre bisherigen technischen Einschränkungen einfach in eine andere Umgebung verschieben – und dafür anschließend deutlich mehr bezahlen.
Die entscheidende Frage lautet deshalb nicht:
„Wie bekommen wir unsere Server möglichst schnell in die Cloud?“
Sondern:
„Welche Workloads sollten tatsächlich in die Cloud, welche sollten verändert werden und welche sollten besser vorerst lokal bleiben?“
Diese Unterscheidung entscheidet maßgeblich darüber, ob eine Cloud-Migration langfristig Vorteile bringt oder zu einem dauerhaften Kosten- und Komplexitätsproblem wird.
Was bedeutet Lift-and-Shift bei einer Cloud-Migration?
Beim Lift-and-Shift-Ansatz wird eine bestehende Anwendung oder ein bestehender Server möglichst unverändert in die Cloud übertragen.
Ein Unternehmen betreibt beispielsweise einen virtuellen Windows-Server mit einer bestimmten Anwendung im eigenen Rechenzentrum. Bei der Migration wird daraus eine virtuelle Maschine in der Cloud. Betriebssystem, Anwendung, Datenbank und teilweise auch die bestehende Architektur bleiben weitgehend gleich.
Der große Vorteil liegt auf der Hand: Die Migration kann schneller und mit weniger Veränderungen an der Anwendung durchgeführt werden.
Das ist besonders interessant, wenn:
- ein Rechenzentrum kurzfristig abgelöst werden muss,
- Hardware ausläuft,
- ein Unternehmen schnell Kapazitäten benötigt,
- eine Anwendung nicht ohne Weiteres verändert werden kann,
- ein kurzfristiger Migrationszeitplan eingehalten werden muss,
- oder zunächst Erfahrungen mit der Cloud gesammelt werden sollen.
Lift-and-Shift ist deshalb keineswegs grundsätzlich falsch.
Das Problem entsteht, wenn der Ansatz als Standardlösung für jede Anwendung verwendet wird.
Eine ineffiziente Anwendung bleibt auch in der Cloud ineffizient. Ein überdimensionierter Server bleibt überdimensioniert. Eine schlecht geplante Datenbank benötigt weiterhin Ressourcen. Und eine Anwendung, die bisher dauerhaft auf leistungsfähiger Hardware lief, kann in einem nutzungsabhängigen Cloud-Modell plötzlich deutlich höhere laufende Kosten verursachen.
Warum „einfach verschieben“ häufig teurer wird als erwartet
Die Kosten einer lokalen Infrastruktur sind für viele Unternehmen relativ leicht zu kalkulieren.
Es gibt Server, Storage, Netzwerkkomponenten, Lizenzen, Wartungsverträge, Stromversorgung, Kühlung und gegebenenfalls Kosten für ein Rechenzentrum.
In der Cloud verändert sich das Kostenmodell.
Statt eine Infrastruktur einmal anzuschaffen und über mehrere Jahre abzuschreiben, entstehen laufende Kosten für unterschiedliche Ressourcen und Dienste.
Dazu können unter anderem gehören:
- Compute-Ressourcen
- Arbeitsspeicher
- Storage
- Snapshots
- Backups
- Datenübertragungen
- Netzwerkkomponenten
- öffentliche IP-Adressen
- Managed Services
- Datenbanken
- Monitoring
- Security-Dienste
- Logging
- zusätzliche Hochverfügbarkeitsfunktionen
Dadurch kann eine virtuelle Maschine, die auf dem Papier ähnlich leistungsfähig wie ein lokaler Server ist, langfristig erheblich andere Betriebskosten verursachen.
Besonders problematisch wird es, wenn Unternehmen nur die Kosten der virtuellen Maschine betrachten.
Eine Cloud-Rechnung besteht selten ausschließlich aus „Serverkosten“.
Der häufigste Denkfehler: Nur die VM-Kosten vergleichen
Ein klassischer Fehler bei einer Migration ist der direkte Vergleich:
Lokaler Server = X Euro pro Monat
gegen
Cloud-VM = Y Euro pro Monat
Dieser Vergleich greift zu kurz.
Eine produktive Anwendung benötigt möglicherweise zusätzlich Speicher, Backups, Netzwerkverbindungen, Monitoring, Sicherheitsfunktionen und Datenübertragungen.
Auch die Architektur rund um die VM kann Kosten erzeugen.
Ein Unternehmen kann beispielsweise feststellen, dass die eigentliche Rechenleistung vergleichsweise günstig ist, während Storage, Backup und Netzwerk einen erheblichen Teil der monatlichen Rechnung ausmachen.
Deshalb sollte eine Cloud-Kalkulation immer die gesamte Architektur betrachten.
Die entscheidende Kennzahl lautet nicht:
„Was kostet diese VM?“
Sondern:
„Was kostet dieser Workload im realen Betrieb?“
Welche Workloads eignen sich für Lift-and-Shift?
Nicht jede Anwendung benötigt sofort eine vollständige Modernisierung.
Lift-and-Shift kann beispielsweise sinnvoll sein, wenn eine Anwendung:
- technisch stabil läuft,
- nur noch wenige Jahre benötigt wird,
- kaum verändert werden soll,
- von einer bekannten virtuellen Umgebung abhängig ist,
- kurzfristig aus einem Rechenzentrum heraus muss,
- oder aufgrund von Abhängigkeiten nicht kurzfristig modernisiert werden kann.
Auch bei älteren Anwendungen kann Lift-and-Shift ein pragmatischer Zwischenschritt sein.
Entscheidend ist jedoch, dass das Unternehmen diese Entscheidung bewusst trifft.
Eine Migration sollte nicht nach dem Prinzip erfolgen:
„Wir verschieben erst einmal alles und schauen später.“
Denn aus einem temporären Zustand kann sehr schnell eine dauerhafte Architektur werden.
Wann Rehosting zum Problem wird
Besonders kritisch wird Lift-and-Shift bei Anwendungen, die ursprünglich für eine klassische lokale Infrastruktur entwickelt wurden.
Ein Beispiel:
Eine Anwendung benötigt dauerhaft vier virtuelle CPUs, 16 GB RAM und schnellen Storage. Lokal läuft sie auf einem ohnehin vorhandenen VMware- oder Hyper-V-Cluster.
In der Cloud wird daraus möglicherweise eine dauerhaft laufende virtuelle Maschine.
Technisch funktioniert die Anwendung weiterhin.
Aber der ursprüngliche Vorteil der Cloud wird möglicherweise nicht genutzt.
Die Anwendung läuft einfach auf einer anderen Infrastruktur.
Sie nutzt weder automatische Skalierung noch serverlose Komponenten, Managed Databases oder andere Cloud-Dienste, die eine moderne Architektur effizienter machen könnten.
Das Unternehmen hat damit zwar eine Cloud-Migration durchgeführt, aber noch keine echte Cloud-Optimierung.
Lift-and-Shift ist nicht gleich Cloud-Modernisierung
Dieser Unterschied wird häufig unterschätzt.
Eine Migration kann verschiedene Ebenen haben:
| Ansatz | Was passiert? | Typischer Aufwand |
|---|---|---|
| Rehost | Anwendung wird nahezu unverändert verschoben | niedrig |
| Replatform | Plattform wird teilweise angepasst | mittel |
| Refactor | Anwendung wird technisch grundlegend modernisiert | hoch |
| Retire | Nicht mehr benötigte Anwendung wird abgeschaltet | sehr niedrig |
| Retain | Anwendung bleibt zunächst lokal | niedrig |
Lift-and-Shift entspricht im Wesentlichen dem Rehosting.
Das kann der richtige erste Schritt sein. Es ist aber nicht automatisch das richtige langfristige Ziel.
Replatforming: Der Mittelweg zwischen Migration und Modernisierung
Beim Replatforming wird eine Anwendung nicht vollständig neu entwickelt, aber gezielt an die neue Umgebung angepasst.
Ein Unternehmen könnte beispielsweise eine bestehende Datenbank nicht mehr selbst auf einer virtuellen Maschine betreiben, sondern einen geeigneten Managed Database Service verwenden.
Oder eine Anwendung wird so angepasst, dass sie bestimmte Cloud-Funktionen nutzen kann.
Der Vorteil:
Die bestehende Anwendung muss nicht komplett neu entwickelt werden, gleichzeitig können Teile der Infrastruktur effizienter betrieben werden.
Für viele mittelständische Unternehmen kann genau dieser Ansatz interessant sein.
Denn eine vollständige Modernisierung aller Anwendungen ist häufig weder wirtschaftlich noch organisatorisch sinnvoll.
Refactoring: Wenn die Anwendung selbst verändert werden muss
Beim Refactoring wird die Anwendung wesentlich stärker verändert.
Monolithische Anwendungen können beispielsweise in mehrere Komponenten aufgeteilt werden. Abhängigkeiten werden reduziert, Datenbanken angepasst und Anwendungen für automatische Skalierung oder moderne Plattformdienste vorbereitet.
Das kann langfristig Vorteile bringen.
Allerdings ist Refactoring wesentlich komplexer als Lift-and-Shift.
Es benötigt:
- Entwicklerkapazitäten,
- Architekturplanung,
- Tests,
- Zeit,
- Dokumentation,
- Migrationskonzepte,
- und eine klare Vorstellung vom zukünftigen Betrieb.
Deshalb sollte nicht jede Anwendung automatisch refaktoriert werden.
Die richtige Strategie hängt vom geschäftlichen Wert, technischen Zustand und erwarteten Lebenszyklus der Anwendung ab.
Die wichtigste Frage: Wie lange wird die Anwendung noch benötigt?
Eine Anwendung, die in sechs Monaten abgeschaltet werden soll, benötigt möglicherweise keine umfangreiche Cloud-Modernisierung.
Eine geschäftskritische Anwendung, die noch zehn Jahre betrieben werden soll, sollte dagegen anders bewertet werden.
Genau deshalb gehört der Business Lifecycle zu den wichtigsten Faktoren einer Cloud-Migration.
Für jede Anwendung sollte möglichst früh geklärt werden:
- Wie wichtig ist sie für das Unternehmen?
- Wie viele Benutzer arbeiten damit?
- Welche Systeme hängen davon ab?
- Wie lange soll sie weiterbetrieben werden?
- Wie häufig verändert sie sich?
- Wie stark schwankt die Auslastung?
- Welche Daten verarbeitet sie?
- Welche Compliance-Anforderungen gelten?
- Welche Verfügbarkeit wird benötigt?
Erst danach lässt sich sinnvoll entscheiden, ob Rehost, Replatform, Refactor, Retain oder Retire sinnvoll ist.
Die versteckten Kosten liegen oft außerhalb der Anwendung
Bei einer Cloud-Migration konzentrieren sich Unternehmen häufig auf die eigentliche Anwendung.
Dabei entstehen zusätzliche Kosten oft an anderer Stelle.
Backup und Recovery
Produktive Cloud-Systeme benötigen weiterhin Backups.
Dabei sollte nicht nur der Speicherbedarf betrachtet werden. Auch Aufbewahrungszeiten, Recovery Points, zusätzliche Backup-Infrastrukturen und Wiederherstellungsszenarien beeinflussen die Kosten.
Ein Backup-Konzept muss deshalb bereits vor der Migration geplant werden.
Netzwerk und Datenübertragung
Datenverkehr zwischen verschiedenen Cloud-Diensten oder zwischen Cloud und lokalem Rechenzentrum kann Kosten und zusätzliche technische Komplexität verursachen.
Besonders relevant wird das bei hybriden Umgebungen.
Wenn eine Anwendung in der Cloud läuft, die Datenbank aber weiterhin lokal betrieben wird, entsteht eine Abhängigkeit über das Netzwerk.
Das kann nicht nur Kosten verursachen.
Auch Latenz und Verfügbarkeit werden zu wichtigen Faktoren.
Monitoring und Logging
In einer größeren Cloud-Umgebung entstehen schnell große Mengen an Logs und Monitoring-Daten.
Diese Informationen sind für Security, Fehleranalyse und Compliance wichtig.
Sie müssen aber ebenfalls gespeichert, verarbeitet und teilweise archiviert werden.
Hochverfügbarkeit
Eine einzelne virtuelle Maschine ist nicht automatisch eine hochverfügbare Anwendung.
Wer höhere Verfügbarkeit benötigt, muss die Architektur entsprechend gestalten.
Das kann zusätzliche Instanzen, redundante Komponenten, Load Balancing oder andere Dienste erfordern.
Damit steigt nicht nur die technische Komplexität, sondern auch der Ressourcenverbrauch.
Warum hybride Cloud-Architekturen besonders genau geplant werden müssen
Viele Unternehmen werden auch nach einer Cloud-Migration nicht vollständig cloudbasiert arbeiten.
Das ist nicht ungewöhnlich.
Ein Teil der Systeme bleibt beispielsweise aus technischen, regulatorischen oder wirtschaftlichen Gründen lokal.
Damit entsteht eine hybride Umgebung.
Hybrid kann sinnvoll sein – aber sie benötigt eine klare Architektur.
Problematisch wird es, wenn sich im Laufe der Zeit eine unübersichtliche Mischung aus lokalen Servern, Cloud-VMs, SaaS-Anwendungen, VPN-Verbindungen und verschiedenen Identitätsdiensten entwickelt.
Dann steigt der administrative Aufwand.
Ein Unternehmen sollte deshalb nicht nur fragen:
„Was migrieren wir?“
sondern auch:
„Wie sieht unsere Zielarchitektur nach der Migration aus?“
Die richtige Reihenfolge: Erst analysieren, dann migrieren
Eine erfolgreiche Cloud-Migration beginnt nicht mit dem Kopieren von virtuellen Maschinen.
Sie beginnt mit einer Bestandsaufnahme.
Dabei sollten mindestens folgende Informationen erfasst werden:
| Bereich | Wichtige Fragen |
|---|---|
| Anwendungen | Welche Anwendungen gibt es? |
| Abhängigkeiten | Welche Systeme kommunizieren miteinander? |
| Auslastung | Wie stark werden Ressourcen tatsächlich genutzt? |
| Daten | Wie groß sind Datenmengen und Wachstum? |
| Verfügbarkeit | Welche Systeme sind geschäftskritisch? |
| Sicherheit | Welche Schutzmaßnahmen sind erforderlich? |
| Compliance | Welche Anforderungen gelten? |
| Kosten | Was kostet der Workload heute? |
| Zukunft | Wie lange wird die Anwendung benötigt? |
Gerade die tatsächliche Auslastung ist wichtig.
Ein Server mit acht CPUs ist nicht automatisch ein Workload, der dauerhaft acht Cloud-CPUs benötigt.
Historische Monitoring-Daten können zeigen, welche Ressourcen tatsächlich gebraucht werden.
Rightsizing sollte vor und nach der Migration stattfinden
Rightsizing bedeutet, Ressourcen an den tatsächlichen Bedarf anzupassen.
Das klingt banal, wird aber in der Praxis häufig übersehen.
Ein Server, der über Jahre mit großzügig dimensionierten Ressourcen betrieben wurde, wird bei einer Lift-and-Shift-Migration möglicherweise exakt so groß in die Cloud übertragen.
Damit wird eine lokale Überdimensionierung zu einer laufenden Cloud-Ausgabe.
Besser ist:
Messen → analysieren → dimensionieren → migrieren → erneut messen → optimieren
Nach der Migration sollte erneut geprüft werden:
- CPU-Auslastung
- Arbeitsspeicher
- Storage
- Netzwerk
- Performance
- Spitzenlasten
- Betriebszeiten
Erst dadurch lässt sich feststellen, ob die gewählte Ressourcengröße tatsächlich zum Workload passt.
Nicht jeder Server muss rund um die Uhr laufen
Ein weiterer Vorteil moderner Cloud-Umgebungen besteht darin, Ressourcen zeitabhängig zu betreiben.
Das ist insbesondere für Entwicklungs-, Test- oder bestimmte interne Systeme interessant.
Wenn eine Umgebung nur während der Arbeitszeit benötigt wird, kann es wirtschaftlich sinnvoll sein, sie außerhalb dieser Zeiten herunterzufahren.
Das funktioniert allerdings nicht für jede Anwendung.
Produktive Systeme, Schnittstellen und abhängige Dienste benötigen häufig eine permanente Verfügbarkeit.
Auch hier gilt:
Nicht pauschal optimieren, sondern Workload für Workload entscheiden.
Cloud-Kosten benötigen laufendes FinOps
Cloud-Kosten sind keine einmalige Kalkulationsaufgabe.
Sie verändern sich mit:
- Nutzerzahlen,
- Datenmengen,
- Workloads,
- Speicherbedarf,
- Architektur,
- Traffic,
- neuen Services,
- Änderungen an Anwendungen.
Deshalb gewinnt FinOps für Unternehmen mit relevanter Cloud-Nutzung an Bedeutung.
Dabei geht es nicht nur darum, Rechnungen zu reduzieren.
Es geht darum, technische Nutzung und wirtschaftliche Verantwortung miteinander zu verbinden.
IT-Teams sollten beispielsweise nachvollziehen können:
- Welche Anwendung verursacht welche Kosten?
- Welche Abteilung nutzt welche Ressourcen?
- Welche Systeme sind dauerhaft überdimensioniert?
- Welche Ressourcen werden kaum genutzt?
- Welche Kosten entstehen durch Backups?
- Wo gibt es unnötigen Datenverkehr?
Ohne Transparenz wird Cloud-Kostenoptimierung schnell zu einem Ratespiel.
Tagging und Kostenstellen werden wichtiger
Eine strukturierte Cloud-Umgebung sollte Ressourcen möglichst eindeutig zuordnen können.
Dafür können beispielsweise Tags oder vergleichbare Metadaten verwendet werden.
Sinnvolle Kategorien können sein:
- Anwendung
- Abteilung
- Kunde
- Umgebung
- Projekt
- Verantwortlicher
- Kostenstelle
Damit lässt sich später besser nachvollziehen, wo Kosten entstehen.
Das ist besonders wichtig, wenn eine Cloud-Umgebung nicht mehr aus wenigen Testsystemen, sondern aus zahlreichen produktiven Workloads besteht.
Sicherheit darf nicht erst nach der Migration kommen
Eine Cloud-Migration verändert auch die Sicherheitsarchitektur.
Identitäten, Berechtigungen, Netzwerkzugriffe, Endgeräte und Anwendungen müssen zusammen betrachtet werden.
Ein häufiges Missverständnis lautet:
„Der Cloud-Anbieter ist für die Sicherheit verantwortlich.“
Das ist zu vereinfacht.
Cloud-Anbieter sichern ihre Infrastruktur und stellen zahlreiche Sicherheitsfunktionen bereit. Für die konkrete Konfiguration, Identitäten, Berechtigungen, Daten und Anwendungen bleiben Unternehmen jedoch weiterhin verantwortlich.
Deshalb sollte Security Bestandteil der Migrationsplanung sein.
Dazu gehören unter anderem:
- Identity and Access Management
- Multi-Faktor-Authentifizierung
- Least Privilege
- Netzwerksegmentierung
- Verschlüsselung
- Backup
- Logging
- Monitoring
- Endpoint Security
- Notfallplanung
Was Unternehmen vor einer Migration messen sollten
Vor dem ersten Migrationsschritt sollte möglichst eine belastbare Ausgangsbasis existieren.
Dazu gehören beispielsweise:
Performance
Wie stark sind CPU, RAM, Storage und Netzwerk tatsächlich ausgelastet?
Kosten
Was kostet der bestehende Workload heute inklusive Betrieb, Hardware, Wartung, Backup und Personalaufwand?
Verfügbarkeit
Wie häufig kommt es zu Ausfällen?
Abhängigkeiten
Welche anderen Anwendungen benötigen diesen Server?
Datenvolumen
Wie groß sind Datenbestand und erwartetes Wachstum?
Recovery
Wie lange darf die Anwendung ausfallen und wie viele Daten dürfen im Notfall verloren gehen?
Diese Werte helfen später dabei, die Cloud-Umgebung nicht nur technisch, sondern auch wirtschaftlich zu bewerten.
Eine Cloud-Migration sollte in Wellen erfolgen
Eine große Umgebung sollte möglichst nicht als ein einziger riesiger Migrationsschritt betrachtet werden.
Ein gestaffeltes Vorgehen reduziert Risiken.
Analyse
Zunächst werden Anwendungen, Server, Datenbanken und Abhängigkeiten erfasst.
Bewertung
Danach wird für jeden Workload eine geeignete Strategie bestimmt.
Pilot
Ein begrenzter Workload wird migriert und unter realistischen Bedingungen getestet.
Erste Migrationswelle
Weitere Anwendungen mit überschaubarem Risiko folgen.
Optimierung
Ressourcen, Netzwerk, Sicherheit und Kosten werden überprüft.
Kritische Systeme
Erst danach sollten besonders geschäftskritische Workloads migriert werden.
Dieses Vorgehen liefert außerdem praktische Erfahrungen, bevor große Teile der Infrastruktur verändert werden.
Die fünf wichtigsten Fragen vor jeder Migration
Bevor ein Server oder eine Anwendung in die Cloud verschoben wird, sollten Verantwortliche mindestens diese Fragen beantworten:
Warum soll dieser Workload überhaupt in die Cloud?
Nicht jede Anwendung benötigt zwingend eine Cloud-Plattform.
Welche Alternative gibt es zu Lift-and-Shift?
Vielleicht ist Replatforming wirtschaftlicher oder eine lokale Modernisierung sinnvoller.
Was kostet der Workload vollständig?
Nicht nur Compute berücksichtigen, sondern auch Storage, Backup, Netzwerk, Monitoring und Betrieb.
Welche Abhängigkeiten bestehen?
Ein scheinbar unabhängiger Server kann mit mehreren anderen Systemen verbunden sein.
Was passiert nach der Migration?
Eine Migration ist kein Endpunkt. Monitoring, Optimierung, Security und Kostenkontrolle müssen anschließend weiterlaufen.
Wann On-Premises weiterhin sinnvoll sein kann
Cloud ist kein automatischer Ersatz für jede lokale Infrastruktur.
Es gibt Workloads, bei denen eine lokale Umgebung weiterhin sinnvoll sein kann.
Zum Beispiel bei:
- sehr stabiler und vorhersehbarer Auslastung,
- speziellen Hardwareanforderungen,
- niedriger Latenz,
- bestimmten Produktionssystemen,
- bestehenden Investitionen,
- speziellen regulatorischen Anforderungen,
- oder Anwendungen, die technisch nur schwer in eine Cloud-Architektur übertragen werden können.
Die Entscheidung sollte deshalb nicht ideologisch getroffen werden.
Die Frage lautet nicht:
„Cloud oder On-Premises?“
Sondern:
„Welche Betriebsform passt zu diesem konkreten Workload?“
Eine gute Cloud-Strategie ist keine reine Migrationsstrategie
Unternehmen sollten Cloud-Migration deshalb nicht nur als Infrastrukturprojekt betrachten.
Es handelt sich um eine Kombination aus:
- IT-Architektur,
- Security,
- Kostenmanagement,
- Betriebsprozessen,
- Anwendungen,
- Datenmanagement,
- Identitätsmanagement
- und Business-Anforderungen.
Wer nur Server verschiebt, verändert möglicherweise die Infrastruktur.
Wer gleichzeitig die Workloads bewertet, Abhängigkeiten reduziert, Ressourcen optimiert und die Zielarchitektur plant, kann dagegen die eigentlichen Vorteile der Cloud nutzen.
Fazit: Lift-and-Shift kann der Anfang sein – aber nicht immer das Ziel
Lift-and-Shift hat seine Berechtigung.
Wenn ein Unternehmen schnell aus einem Rechenzentrum heraus muss oder eine Anwendung kurzfristig in eine andere Infrastruktur übertragen werden soll, kann Rehosting eine pragmatische Lösung sein.
Problematisch wird es, wenn daraus automatisch die langfristige Strategie für sämtliche Systeme wird.
Denn eine Cloud macht eine bestehende Architektur nicht automatisch effizienter.
Ein überdimensionierter Server bleibt überdimensioniert. Eine unnötige Anwendung bleibt unnötig. Eine schlecht dokumentierte Abhängigkeit bleibt eine Abhängigkeit.
Deshalb sollte vor jeder Cloud-Migration geklärt werden, welcher Workload tatsächlich migriert werden soll, warum er migriert werden soll und welche Zielarchitektur wirtschaftlich und technisch sinnvoll ist.
Für Unternehmen ist häufig nicht die schnellste Migration die entscheidende Größe, sondern die Qualität der Entscheidungen vor der Migration.
Eine erfolgreiche Cloud-Strategie beginnt deshalb nicht mit dem Verschieben von Servern.
Sie beginnt mit einer ehrlichen Analyse der eigenen IT.
FAQ zur Cloud-Migration und Lift-and-Shift
Was bedeutet Lift-and-Shift?
Lift-and-Shift bezeichnet die Migration einer Anwendung oder eines Servers in eine neue Infrastruktur, ohne die Anwendung grundlegend zu verändern. In der Cloud wird häufig eine bestehende virtuelle Maschine nahezu unverändert als Cloud-VM betrieben.
Ist Lift-and-Shift grundsätzlich schlecht?
Nein. Lift-and-Shift kann bei bestimmten Workloads sinnvoll sein, insbesondere wenn eine schnelle Migration erforderlich ist oder eine Anwendung kurzfristig ohne größere technische Veränderungen verlagert werden soll. Entscheidend ist, ob der Ansatz zum jeweiligen Workload passt.
Warum kann Lift-and-Shift in der Cloud teuer werden?
Eine lokal überdimensionierte oder dauerhaft laufende Infrastruktur kann in einem nutzungsabhängigen Cloud-Modell höhere laufende Kosten verursachen. Zusätzlich können Storage, Backup, Netzwerk, Monitoring und weitere Dienste Kosten verursachen.
Was ist der Unterschied zwischen Rehost und Replatform?
Beim Rehosting wird eine Anwendung weitgehend unverändert verschoben. Beim Replatforming wird die Anwendung oder ihre Plattform gezielt angepasst, um bestimmte Vorteile der neuen Umgebung besser zu nutzen.
Muss jedes Unternehmen vollständig in die Cloud wechseln?
Nein. Abhängig von Anwendungen, Kosten, Sicherheitsanforderungen, Latenz, Compliance und bestehenden Investitionen kann eine hybride oder teilweise lokale Infrastruktur sinnvoll sein.
Wie lässt sich eine Cloud-Migration vorbereiten?
Eine gute Vorbereitung beginnt mit einer Bestandsaufnahme der Anwendungen, Server, Daten, Abhängigkeiten, Auslastungen, Sicherheitsanforderungen und aktuellen Betriebskosten. Anschließend sollte für jeden Workload eine geeignete Migrationsstrategie festgelegt werden.
Was sollte nach einer Cloud-Migration kontrolliert werden?
Nach der Migration sollten unter anderem Performance, Ressourcenauslastung, Sicherheit, Backup, Netzwerkverkehr und tatsächliche Kosten überprüft werden. Gerade beim Lift-and-Shift kann sich nach einigen Wochen zeigen, dass Ressourcen angepasst oder Workloads anders betrieben werden sollten.
Wie lassen sich Cloud-Kosten dauerhaft kontrollieren?
Transparente Zuordnung von Ressourcen, regelmäßiges Rightsizing, Monitoring, Abschalten nicht benötigter Ressourcen und ein strukturiertes FinOps-Modell helfen dabei, Cloud-Kosten dauerhaft nachvollziehbar und steuerbar zu machen.
