Die Tücken der Cloud-Migration „Lift and Shift“ – Wenn es nur so einfach wäre!

Ein Gastbeitrag von Engelbert Epple* Lesedauer: 5 min

Anbieter zum Thema

Wer Schulden macht, muss diese früher oder später begleichen. Das gilt auch für Unternehmen, die ihre IT in die Cloud verlagern. Häufig ist hier zu beobachten, dass Entscheider auf das sogenannte „Lift and Shift“ setzen – Anwendungen und Daten mehr oder weniger unverändert in die Cloud zu verlagern. Doch dabei häuft sich „Technical Debt“ an.

Bevor IT-Systeme in die Cloud wandern, sollte erst einmal im Altbestand gründlich aufgeräumt werden; das erleichtert nicht nur die Migration, sondern macht sie auch günstiger.
Bevor IT-Systeme in die Cloud wandern, sollte erst einmal im Altbestand gründlich aufgeräumt werden; das erleichtert nicht nur die Migration, sondern macht sie auch günstiger.
(Bild: Andrew Gardner - stock.adobe.com)

Dieser Begriff – übersetzt „technische Schulden“ – wird im Software-Engineering verwendet, um mögliche Folgen zu beschreiben, wenn Software technisch schlecht umgesetzt wird, anstatt eine bessere, nachhaltigere Lösung zu entwickeln. Er wird aber auch verwendet, um zu beschreiben, dass Unternehmen nicht „aufräumen“, bevor sie ihre IT in die Cloud verlagern.

Natürlich haben die meisten Unternehmen erkannt, dass der Betrieb ihrer IT in ihren eigenen Rechenzentren nicht mehr der effizienteste Weg ist, um IT-Lösungen für ihr Unternehmen bereitzustellen. Hyperscaler bieten ihnen an, ihre gesamte IT in die Cloud zu verlagern – damit würden sie viel Geld sparen. Sie bieten hohe Rabatte, die dieses sogenannte „Lift and Shift“ sehr kosteneffizient machen. Viele CFOs sehen massive Einsparungen bei den Gesamtbetriebskosten der teilweise sehr alten IT-Systeme, die noch on-premises betrieben werden.

Geht es nach SAP, wird sich der Einsatz von Software wie SAP S/4HANA in Unternehmen in den nächsten Jahren grundlegend ändern. Dafür hat SAP im Jahr 2021 das Programm „Rise with SAP“ eingeführt, bei dem S/4HANA, der Nachfolger der Version SAP ECC, nur noch in der Cloud und nicht mehr on-premises verfügbar sein wird. Ähnlich verhält es sich bei Microsoft mit der Einführung von Microsoft 365, ehemals Office 365.

Die „Consumption Trap“

Sowohl Hyperscaler als auch große Software-Vendoren wollen also Workloads in ihre Clouds verlagern. Die Hyperscaler wollen Rechen- und Speicherkapazität sowie ihre Cloud-nativen Services verkaufen, während Softwareanbieter sich nicht mehr nur mit reinen Lizenzgeschäft begnügen wollen. Warum sollten sie also daran interessiert sein, die IT ihrer Kunden zu „bereinigen“, bevor sie in die Cloud umziehen? Aufräumen könne man später immer noch“ – Aber ist das wirklich sinnvoll?

Ein einfaches Rechenbeispiel macht schnell klar, warum das aus finanzieller Sicht problematisch sein kann. Angenommen, ein Unternehmen hat 1.000 „Einheiten“ der IT. Eine Einheit ist hier ein Platzhalter für die IT-Kosten, die notwendig sind, damit das Unternehmen arbeiten kann. Nehmen wir an, eine Einheit kostet 100 Euro pro Monat. In der Tat hat dieses Unternehmen 100.000 Euro Kosten pro Monat und 1,2 Millionen Euro pro Jahr. Nun bietet ein Hyperscaler dem Unternehmen einen massiven Rabatt – in diesem Fall 50 Prozent.

Dieses Unternehmen spart also 600.000 Euro pro Jahr, wenn die gesamte IT in die Cloud verlagert wird. Die Risiken, eine über 20 Jahre alte IT „einfach so“ in die Cloud zu verlagern, kalkuliert zu diesem Zeitpunkt allerdings noch niemand ein. Hyperscaler finanzieren sogar kleinere Cloud-Migrationen, so dass alles ganz einfach erscheint. Sie berechnen den Workload von 1.000 Einheiten für die nächsten drei, fünf oder gar zehn Jahre mit 600.000 Euro pro Jahr. Der Haken: Der Provider erwartet bei einem hohen Rabatt auch eine entsprechende Auslastung. Der Anreiz, grundsätzlich zu sparen und IT effizienter und nachhaltiger bereitzustellen, entfällt.

Erst einmal aufräumen

Doch wie sieht die Rechnung aus, wenn Unternehmen ihre technischen Schulden im Vorfeld massiv reduzieren? Zunächst empfiehlt sich eine ausführliche Ist-Analyse, ggf. mit Hilfe von Tools wie z.B. eAPM oder SAP-spezifischen Werkzeugen. Diese Analyse sollte innerhalb von drei Monaten durchgeführt werden.

Darauf aufbauend kann eine Roadmap entwickelt werden, aus der hervorgeht, welche Systeme zum Beispiel abgeschaltet werden könnten, welche Applikationen als „retired systems“ (aus Audit- oder Compliance Gründen) bleiben müssten, welche durch neue – ggf. native – Cloud-Lösungen ersetzt werden können und welche Applikationen schließlich doch nach dem Lift-and-Shift-Prinzip migriert werden müssen.

Angenommen, das Unternehmen ist in der Lage, durch einen „Clean-up“-Prozess die IT-Einheiten vor der eigentlichen Migration von 1.000 auf 500 zu reduzieren. Zum einen könnten die vom Hyperscaler versprochenen Einsparungen bereits vor der Migration erzielt werden, zum anderen müssen einfach weniger Workloads in die Cloud migriert werden – was den Prozess schlanker macht.

Natürlich müssen dabei Zeit und Kosten für die genaue Analyse und die Durchführung der Bereinigung einkalkuliert werden, was einen Teil der geplanten Einsparungen reduziert. Allerdings: Dafür verkürzt sich üblicherweise die Vorbereitungsphase zur Migration, ebenso wie die Dauer der Migration selbst. Denn gerade diese Vorbereitungsphase ist beim Lift-and-Shift-Ansatz nicht unerheblich.

Schlankere Migration spart Zeit und Geld

Grundsätzlich gilt: Je mehr Systeme bzw. Landscapes umzuziehen sind, desto mehr Waves und Downtimes sind notwendig. Und genau diese Downtimes sind erfahrungsgemäß selten. Die Fachbereiche sind auf die SAP-Systeme angewiesen – jede Unterbrechung kostet Geld. Dazu kommt das höhere Risiko von Fehlfunktionen nach dem Neustart, wenn komplexe und eng verzahnte Systeme umgezogen werden müssen.

Jetzt Newsletter abonnieren

Täglich die wichtigsten Infos zu Cloud Computing

Mit Klick auf „Newsletter abonnieren“ erkläre ich mich mit der Verarbeitung und Nutzung meiner Daten gemäß Einwilligungserklärung (bitte aufklappen für Details) einverstanden und akzeptiere die Nutzungsbedingungen. Weitere Informationen finde ich in unserer Datenschutzerklärung.

Aufklappen für Details zu Ihrer Einwilligung

Betrachtet man den späteren Betrieb, wird der Hyperscaler aufgrund der geringeren Anzahl an Workload-Einheiten einen geringeren Rabatt gewähren, im Beispiel vielleicht 25 Prozent statt 50 Prozent. Rechnen wir dann noch einmal nach: Noch bevor die IT überhaupt in die Cloud verlagert wird, hat das Unternehmen seine Kosten bereits halbiert. Nach der Cloud-Migration zahlt es bei 25 Prozent Rabatt nur noch 450.000 Euro zahlen – also weniger als beim reinen Lift-and-Shift-Ansatz.

Aus IT-Sicht ist die Reduzierung der technischen Schulden ein Muss. Warten Unternehmen mit der Optimierung ihrer Infrastruktur zu lange, steigen die Kosten enorm. Gehen sie diese notwendige Aufgabe hingegen rechtzeitig an, bleiben sie wettbewerbsfähig. Gerade die Migration in die Cloud bietet aus IT-Sicht die beste Gelegenheit zum Aufräumen.

Der Mythos von „Lift and Shift“

Bei der Migration von IT-Systemen einschließlich der installierten Software in die Cloud geht es nicht einfach darum, einen Server hier abzuschalten und ihn in einem anderen Rechenzentrum wieder einzuschalten. Es handelt sich immer um einen Mix aus Re-Hosting, Re-Deployment sowie Dekommissionierung und Implementierung neuer Anwendungen und auch Lift and Shift. Ein Re-Hosting bzw. Re-Deployment ist vergleichbar mit einer Herztransplantation: Die wichtigsten IT-Systeme samt ihrer Daten sollen „verpflanzt" werden. Misslingt diese Operation, leidet das gesamte Unternehmen massiv.

Der Clean-up-first-Ansatz mindert das Risiko bereits dadurch, dass genau analysiert wird, was umziehen soll und wie es zusammenhängt. Darüber hinaus muss bei der Wave-Planung darauf geachtet werden, dass ein koexistenter, flexibler Betrieb während der Migration gegeben ist. Das Betriebsteam stellt sicher, dass die noch nicht umgezogenen Systeme (CMO – Current Mode of Operation) und die bereits migrierten Systeme (FMO – Future Mode of Operation) auch während des Umzugs ihre Services bereitstellen: Der Geschäftsbetrieb darf nicht unterbrochen werden – insbesondere dann nicht, wenn dieser Doppelbetrieb über 12 Monate oder länger aufrechterhalten werden muss.

Die 5 wichtigsten Empfehlungen für eine SAP2Cloud-Migration sind:

  • 1. Die „Consumption Falle“ vermeiden, kein Lock-Angebot des Cloud-Providers unterschreiben.
  • 2. Die genaue Ist-Analyse insbesondere der Abhängigkeiten minimiert das Risiko.
  • 3. Clean-up-first: Die Reduktion der Altlasten vor der Migration macht diese schlanker.
  • 4. Flexibler Betrieb während der Migration ist essenziell und beugt Service-Unterbrechungen vor.
  • 5. Dekommissionierung der Altsysteme nicht vergessen.


* Der Autor Engelbert Epple ist Enterprise Architect bei Capgemini mit Schwerpunkt IT-Infrastruktur im Bereich Cloud Infrastructure Services.

Bildquelle: Capgemini Deutschland GmbH

(ID:49409510)