Illustration Absmeier foto ki designer

Rehosting bringt Anwendungen schnell in die Cloud – aber noch nicht in die Zukunft. Wer Architektur, Betrieb und Verantwortung unverändert übernimmt, verlagert technische Schulden und Sicherheitsrisiken und riskiert dauerhaft hohe Kosten. Entscheidend ist deshalb nicht nur der Migrationspfad, sondern ein verbindlicher Modernisierungsplan.

Management Summary

Rehosting ist ein taktischer Beschleuniger, keine abgeschlossene Cloud-Transformation.
Ohne Zielarchitektur wandern technische Schulden, Betriebsaufwand und Sicherheitsrisiken mit.
Cloud-Kosten sinken nicht automatisch: FinOps schafft Transparenz, ersetzt aber keine Modernisierung.
Ownership entscheidet: Budget, Product Owner, Governance und Modernisierungs-Backlog müssen vor dem Go-live feststehen.
Erfolg zeigt sich an Wirkung, nicht an Serverzahlen: Maßgeblich sind Liefergeschwindigkeit, Stabilität, Kosten und Geschäftsnutzen.

Warum Unternehmen auf Rehosting setzen

Beim Lift & Shift, auch Rehosting genannt, wandert eine Anwendung nahezu unverändert aus dem eigenen Rechenzentrum oder einer bestehenden Hosting-Umgebung in eine Cloud-Infrastruktur. Architektur, Code, Betriebsmodell und Abhängigkeiten bleiben zunächst bestehen. Das entspricht der Definition von Rehosting in der AWS Prescriptive Guidance. Das verkürzt Analyse-, Anpassungs- und Testphasen und begrenzt das unmittelbare Migrationsrisiko. Muss Hardware kurzfristig ersetzt werden, läuft Herstellersupport aus, wird ein Rechenzentrum geschlossen oder drängt eine regulatorische Frist, kann dieser Geschwindigkeitsvorteil entscheidend sein.

Kritisch ist daher nicht das Rehosting selbst, sondern die Annahme, die Modernisierung werde nach dem Umzug zwangsläufig folgen. Mit dem Go-live entfällt häufig genau der operative Druck, der das Vorhaben ausgelöst hat: Der Altserver ist abgeschaltet, die Sicherheitsauflage formal erfüllt, der Audit-Termin bestanden. Das Projekt gilt als abgeschlossen, Budget und Team werden abgezogen. Technisch läuft jedoch weiterhin derselbe Code mit denselben Abhängigkeiten und Engpässen – nun lediglich auf gemieteter Infrastruktur.

Altlasten wandern in die Cloud

Unveränderte Legacy-Anwendungen nutzen zentrale Cloud-Eigenschaften meist nur eingeschränkt. Monolithische Anwendungen lassen sich häufig nur als Ganzes skalieren, zustandsbehaftete Komponenten und lokale Dateisysteme erschweren einen elastischen und ausfallsicheren Betrieb, fest gekoppelte Schnittstellen behindern Automatisierung, und veraltete Datenbankversionen können den Wechsel auf gemanagte Plattformdienste erschweren oder verhindern. Das Ergebnis ist eine Anwendung, die zwar in der Cloud läuft, operativ aber weiterhin wie im klassischen Rechenzentrum behandelt werden muss.

Skalierbarkeit: Ressourcen bleiben dauerhaft überdimensioniert, weil Lastspitzen nicht elastisch abgefangen werden können.
Verfügbarkeit: Einzelne Instanzen oder zentrale Komponenten bleiben Single Points of Failure.
Automatisierung: Manuelle Deployments und Konfigurationsänderungen verlängern Durchlaufzeiten und erhöhen die Fehlerquote.
Observability: Logs, Metriken und Traces sind nicht durchgängig integriert; Fehleranalyse und Ursachenbehebung dauern länger.
Wartbarkeit: Veraltete Runtimes, Bibliotheken und proprietäre Abhängigkeiten erschweren Patches und Releases.

Cloud-Preise, Rechenzentrumsbetrieb

Auf dem Papier ist die Anwendung nun in der Cloud, im Betrieb bleibt sie jedoch ähnlich aufwendig wie zuvor. Gleichzeitig greift das verbrauchsabhängige Preismodell des Providers. Dauerhaft laufende virtuelle Maschinen, überdimensionierte Instanzen, ungenutzter Speicher, Datentransfer und ungünstige Lizenzmodelle können erwartete Einsparungen mindern oder aufzehren. Fehlen zudem einheitliche Tags und Kostenstellen, lassen sich Ausgaben weder einer Anwendung noch einem Geschäftsprozess oder einem Verantwortlichen sauber zuordnen.

Eine belastbare Wirtschaftlichkeitsrechnung darf sich deshalb nicht auf Infrastrukturpreise beschränken. In den Total Cost of Ownership gehören Betriebsaufwand, Lizenzen, Support, Security-Maßnahmen, Ausfallrisiken, Datentransfer, Qualifizierung und die Opportunitätskosten verzögerter Produktänderungen. FinOps-Praktiken wie konsequentes Tagging, Budgets, Kostenalarme, Rightsizing, Abschaltregeln und regelmäßige Reviews schaffen Transparenz. Die FinOps Foundation ordnet insbesondere Kostenallokation über Konten, Tags, Labels und Metadaten sowie iterative Optimierung als zentrale Fähigkeiten ein. Eine strukturell ineffiziente Architektur können diese Praktiken jedoch nicht kompensieren.

Ohne Ownership bleibt die Modernisierung liegen

Migrationsprojekte verfügen in der Regel über Team, Budget, Meilensteine und Eskalationswege. Für die anschließende Modernisierung gilt das häufig nicht. Sie gehört zwar zur strategischen Erzählung, aber nicht zum verbindlichen Lieferumfang. Nach dem Go-live löst sich das Projektteam auf, während der Betrieb an eine andere Einheit übergeht. Zwischen Projekt, Plattformteam, Anwendungsbetrieb und Fachbereich entsteht eine Verantwortungslücke.

Migration und Modernisierung müssen deshalb als zusammenhängendes Programm gesteuert werden. Bereits der Projektauftrag sollte Zielarchitektur, Modernisierungsbudget, einen verantwortlichen Product Owner und einen verbindlichen Architektur-Review enthalten. Ein gemeinsames Steuerungsgremium aus Fachbereich, Entwicklung, Betrieb, Informationssicherheit, Finanzen und Enterprise Architecture sorgt dafür, dass technische, wirtschaftliche und regulatorische Ziele nicht auseinanderlaufen.

Sicherheit bleibt Unternehmensaufgabe

Cloud-Sicherheit folgt einem Modell geteilter Verantwortung: Der Provider schützt die zugrunde liegende Infrastruktur; die Pflichten des Kunden hängen vom gewählten Servicemodell ab und sind bei IaaS umfangreicher als bei stärker gemanagten Diensten. Für Daten, Identitäten, Berechtigungen und die sichere Konfiguration der genutzten Services bleibt das Unternehmen verantwortlich. AWS beschreibt diese Trennung als »Security of the Cloud« und »Security in the Cloud« und weist ausdrücklich darauf hin, dass die Kundenpflichten vom gewählten Dienst abhängen. Werden überprivilegierte Konten, fest codierte Zugangsdaten, ungepatchte Komponenten oder unklare Datenflüsse unverändert übernommen, wandert auch das Risiko mit. Der Standortwechsel allein verbessert weder das Sicherheitsniveau noch die Auditfähigkeit.

Zum Mindestprogramm gehören daher ein Review von Identitäts- und Berechtigungsmodell, Verschlüsselung und Schlüsselmanagement, Schwachstellen- und Patchmanagement, manipulationssichere Protokollierung, Backup und Restore sowie regelmäßig getestete Notfall- und Wiederanlaufverfahren. Zusätzlich sind Datenresidenz, Aufbewahrungsfristen, regulatorische Nachweise und Provider-Abhängigkeiten zu bewerten. Das Google Cloud Well-Architected Framework nennt unter anderem Redundanz, fehlertolerantes Design, Monitoring und automatisierte Wiederherstellung als Bausteine zuverlässiger Systeme. Allein die Wahl einer Cloud-Region schafft daher noch keine Resilienz; sie entsteht durch eine bewusst entworfene und erprobte Betriebsarchitektur.

Welche Anwendung braucht welchen Pfad?

Strategie	Sinnvoll, wenn	Kritischer Punkt
Rehost	Zeitdruck besteht und die Anwendung technisch stabil ist.	Altlasten und Kosten bleiben zunächst bestehen; die Modernisierung braucht Termin und Budget.
Relocate	Eine bestehende virtualisierte Plattform weitgehend unverändert in eine kompatible Cloud-Umgebung verschoben werden soll.	Der Plattformwechsel allein modernisiert weder Anwendung noch Betriebsmodell.
Replatform	Einzelne Komponenten mit vertretbarem Aufwand auf gemanagte Dienste wechseln können.	Tests, Betriebsprozesse, Datenmigration und Lizenzfolgen früh klären.
Refactor oder Rearchitect	Wartbarkeit, Skalierbarkeit, Änderbarkeit oder Resilienz geschäftskritisch sind.	Schrittweise vorgehen und technische Maßnahmen an messbare Geschäftsergebnisse koppeln.
Repurchase oder Replace	Eine Standard- oder SaaS-Lösung den fachlichen Bedarf ausreichend abdeckt.	Prozessanpassung, Datenübernahme, Integration und Anbieterbindung bewerten.
Retire oder Retain	Die Anwendung entbehrlich ist oder ein Umzug derzeit keinen Nutzen stiftet.	Abschaltung oder Verbleib bewusst entscheiden und regelmäßig überprüfen.

Einordnung: Die Strategiebegriffe orientieren sich an der AWS-Systematik der »7 Rs«. Microsoft verwendet im Cloud Adoption Framework eine erweiterte Einteilung, die unter anderem Refactor, Rearchitect, Rebuild und Replace getrennt ausweist.

Entscheidend sind Geschäftskritikalität, Änderungsfrequenz, technischer Zustand, Daten- und Compliance-Anforderungen, erwartete Restlaufzeit sowie verfügbare Kompetenzen. Eine selten geänderte Anwendung kurz vor der Ablösung rechtfertigt selten ein umfassendes Refactoring. Ein digitaler Kernprozess mit hoher Änderungsdynamik kann durch dauerhaftes Rehosting dagegen zum Innovationshemmnis werden.

Sieben Schritte aus der Rehosting-Falle

Portfolio erfassen: Anwendungen, Abhängigkeiten, Datenflüsse, Kosten, Risiken und Verantwortlichkeiten transparent machen.
Zielbild festlegen: Definieren, welche geschäftlichen und technischen Ergebnisse die Cloud-Nutzung liefern soll.
Pfad je Anwendung wählen: Rehost, Relocate, Replatform, Refactor beziehungsweise Rearchitect, Repurchase beziehungsweise Replace, Retire oder Retain nachvollziehbar entscheiden.
Migration absichern: Testkonzept, Rollback, Security-Kontrollen, Betriebsübergabe und Kostenüberwachung verbindlich planen.
Modernisierungs-Backlog finanzieren: Technische Schulden, Architekturmaßnahmen und Betriebsverbesserungen priorisieren und budgetieren.
Ownership sichern: Product Owner, Plattformteam und Fachbereich an gemeinsame, messbare Ziele binden.
Regelmäßig überprüfen: Architektur, Kosten, Risiken und Nutzen in festen Intervallen neu bewerten.

Was eine erfolgreiche Cloud-Migration wirklich zeigt

Die Zahl migrierter Server ist kein ausreichender Erfolgsnachweis. Relevanter sind Bereitstellungsdauer beziehungsweise Change Lead Time, Deployment-Frequenz, Change Fail Rate, Failed Deployment Recovery Time, Verfügbarkeit, Automatisierungsgrad, offene Sicherheitsbefunde, Kosten pro Transaktion oder Nutzer und der Anteil stillgelegter Altkomponenten. DORA führt aktuell fünf Kennzahlen zur Softwarebereitstellung: Change Lead Time, Deployment Frequency, Failed Deployment Recovery Time, Change Fail Rate und Deployment Rework Rate. Ergänzend braucht es geschäftliche Kennzahlen: Wie schnell lassen sich neue Produkte, Schnittstellen oder regulatorische Anforderungen umsetzen? Verkürzt sich die Zeit von der Idee bis zur produktiven Nutzung? Werden Entwicklung und Betrieb tatsächlich entlastet?

Fünf Irrtümer, die Modernisierung ausbremsen

»Nach dem Umzug haben wir mehr Zeit.« Ohne reservierte Kapazität verliert die Modernisierung gegen das nächste dringende Vorhaben.
»Die Cloud senkt automatisch die Kosten.« Einsparungen entstehen erst durch passende Architektur, Betriebsdisziplin und Kostentransparenz.
»Der Provider übernimmt die Sicherheit.« Im Shared-Responsibility-Modell bleiben zentrale Pflichten beim Unternehmen.
»Cloud-native ist immer das Ziel.« Der angemessene Modernisierungsgrad richtet sich nach Geschäftsnutzen, Risiko und Restlaufzeit.
»Mit dem Go-live ist das Projekt beendet.« Der Go-live markiert den Beginn einer neuen Betriebs- und Verbesserungsphase.

Fazit: Ohne Anschlussplan bleibt die Cloud Kulisse

Lift & Shift ist kein Fehlansatz, sondern ein taktisches Instrument. Es kann Zeit gewinnen, Risiken begrenzen und den Weg für weitere Veränderungen freimachen. Zum Problem wird Rehosting, wenn der Infrastrukturwechsel als abgeschlossene Transformation gilt. Unternehmen sollten deshalb bereits vor der Migration Zielarchitektur, Budget, Ownership, Sicherheitskontrollen und messbare Modernisierungsergebnisse festlegen. Fehlt dieser Anschlussplan, wird die Cloud lediglich zum neuen Standort für alte Probleme – und der vermeintliche Startpunkt zur Endstation.

Albert Absmeier & KI

FAQ: Lift & Shift und Cloud-Modernisierung

1. Was bedeutet Lift & Shift?

Lift & Shift beziehungsweise Rehosting bezeichnet die weitgehend unveränderte Verlagerung einer Anwendung auf Cloud-Infrastruktur. Code, Architektur und Betriebsmodell bleiben zunächst bestehen.

2. Wann ist Rehosting sinnvoll?

Vor allem bei hohem Zeitdruck, auslaufendem Support, bevorstehenden Rechenzentrumsschließungen oder klar begrenzten technischen Risiken. Es sollte als taktischer Zwischenschritt verstanden werden.

3. Warum sinken die Kosten nicht automatisch?

Legacy-Anwendungen nutzen Elastizität und gemanagte Dienste häufig nur eingeschränkt. Überdimensionierte Instanzen, Dauerbetrieb, Datentransfer und Lizenzen können Einsparungen mindern oder aufzehren.

4. Welche technischen Schulden wandern mit?

Typisch sind monolithische Architekturen, veraltete Laufzeitumgebungen, lokale Dateisysteme, enge Kopplung, manuelle Deployments und fehlende Observability.

5. Wer trägt nach der Migration die Sicherheitsverantwortung?

Im Shared-Responsibility-Modell schützt der Provider die Cloud-Infrastruktur. Das Unternehmen bleibt – abhängig vom Servicemodell – unter anderem für Daten, Identitäten, Berechtigungen und sichere Konfigurationen verantwortlich.

6. Wie verhindert man, dass die Modernisierung liegen bleibt?

Mit einem verbindlichen Zielbild, reserviertem Budget, einem Product Owner, einem priorisierten Modernisierungs-Backlog und fest terminierten Architektur-Reviews.

7. Welche Alternativen gibt es zum Rehosting?

Je nach Anwendung kommen Relocate, Replatform, Refactor beziehungsweise Rearchitect, Repurchase beziehungsweise Replace, Retire oder Retain infrage.

8. Welche Rolle spielt FinOps?

FinOps schafft Transparenz über Zuordnung, Budgets und Verbrauch, unterstützt Rightsizing und etabliert regelmäßige Kostenreviews. Eine ungeeignete Architektur ersetzt es jedoch nicht.

9. Woran lässt sich der Migrationserfolg messen?

Nicht allein an migrierten Servern, sondern an Liefergeschwindigkeit, Change Fail Rate, Wiederherstellungszeit, Verfügbarkeit, Automatisierung, Sicherheitslage, Kosten pro Nutzungseinheit und geschäftlichem Nutzen.

10. Was ist die wichtigste Managemententscheidung?

Vor dem Go-live festzulegen, ob Rehosting Endzustand oder Zwischenstufe ist – und für den nächsten Schritt Verantwortung, Finanzierung, Termine und messbare Ergebnisse verbindlich zu machen.

Management Summary, FAQ und Bild wurden mit Hilfe von KI erstellt

Quellen und weiterführende Hinweise

AWS Prescriptive Guidance: »About the migration strategies«. Definition und Einordnung der sieben Migrationsstrategien Retire, Retain, Rehost, Relocate, Repurchase, Replatform und Refactor/Re-architect. https://docs.aws.amazon.com/prescriptive-guidance/latest/large-migration-guide/migration-strategies.html
AWS: »Shared Responsibility Model«. Abgrenzung von Provider- und Kundenverantwortung sowie Unterschiede nach gewähltem Cloud-Service. https://aws.amazon.com/de/compliance/shared-responsibility-model/
Microsoft Learn: »Auswählen Ihrer Cloudmigrationsstrategien«. Entscheidungshilfe zu Retire, Retain, Rehost, Replatform, Refactor, Rearchitect, Rebuild und Replace. https://learn.microsoft.com/de-de/azure/cloud-adoption-framework/plan/select-cloud-migration-strategy
FinOps Foundation: »Allocation« und »FinOps Phases«. Kostenallokation mithilfe von Konten, Tags, Labels und Metadaten sowie der iterative Zyklus Inform, Optimize und Operate. https://www.finops.org/framework/capabilities/allocation/ und https://www.finops.org/framework/phases/
DORA: »DORA’s software delivery performance metrics«. Aktuelle Definition der fünf Software-Delivery-Kennzahlen. https://dora.dev/guides/dora-metrics/
Google Cloud: »Well-Architected Framework – Reliability« und »Detect potential failures by using observability«. Empfehlungen zu Resilienz, Redundanz, Monitoring, Logs, Metriken und Traces. https://docs.cloud.google.com/architecture/framework/reliability und https://docs.cloud.google.com/architecture/framework/reliability/observability

Kommentar

Lift & Shift: Startpunkt in der Theorie, Endstation in der Praxis

Von Nadine Riederer

Immer noch werden viele Migrationsprojekte mit derselben Intention gestartet: Die Systeme müssen aus akuten Gründen schnell in eine neue Umgebung (ganz konkret: in die Cloud), die eigentliche Modernisierung folgt danach.

Das ist einerseits mit Blick auf den IT-Alltag verständlich, birgt aber andererseits das mehr als wahrscheinliche Risiko, Projekte nach dem Umzug ruhen zu lassen – bis die eigentliche Modernisierung vergessen ist. Erklären lässt sich dieses Phänomen nicht allein mit fehlender Sorgfalt einzelner Projektbeteiligter oder falschen Strukturen. Es liegt an einem Mechanismus, der sich unabhängig von Branche oder Unternehmensgröße immer wiederholt: Der eigentliche Anlass für die Migration verschwindet mit dem Umzug in die Cloud. Die Aufgabe, die eigentlich dahinterstand, bleibt ungelöst.

Wo ein akutes Problem gelöst werden muss, zum Beispiel ein auslaufender Support, eine Sicherheitslücke oder ein Auditor, der nicht mehr wegsieht, ist der Treiber selten architektonische Überzeugung, sondern ganz schlicht die Not. Sobald die Systeme in der Cloud laufen, fällt der Druck logischerweise ab. Operation geglückt. Der Server gilt nicht mehr als veraltet, die Warnung ist hinfällig. Verändert hat sich aber in Wirklichkeit wenig. Derselbe Code, dieselben Abhängigkeiten, dieselben technischen Schulden – nur an einem anderen Ort.

In der Praxis verschwindet mit dem operativen Druck oft auch jeder, der sich noch zuständig fühlt. Das Migrationsprojekt hatte ein Team, ein Budget, eine Deadline. Die Modernisierung danach hat nichts davon. Sie war vielleicht die Begründung für das Projekt, aber nicht dessen Inhalt. Ist die Migration abgeschlossen, ist auch das Team weg, verteilt auf das nächste dringende Thema.

Das Ergebnis kennt vermutlich jeder, der lange genug in der IT arbeitet: ein System, das auf dem Papier zukunftsfähig aussieht und in Wirklichkeit genauso mühsam zu warten ist wie vorher. Jetzt aber mit einem Cloud-Anbieter, der bei jeder Änderung mitverdient. Dabei würde kaum jemand auf die Idee kommen, einen Versicherungsvertrag abzuschließen und ihn danach nie wieder zu überprüfen, nur weil er beim Abschluss richtig war. Bei Systemen in der Cloud passiert allerdings genau dieses Szenario im großen Stil: der Abschluss der Migration wird mit dem Ende des Projekts verwechselt.

Der Unterschied ist: Bei einer Versicherung sorgt die jährliche Beitragsrechnung ganz automatisch für einen Anlass, noch einmal hinzuschauen. Bei einer Cloud-Migration gibt es diesen Anlass nicht von selbst, er muss eingeplant werden. Das heißt konkret: ein Modernisierungstermin, der im selben Projektauftrag steht wie die Migration selbst, mit eigenem Budget und eigenem Verantwortlichen, der nicht mit dem Migrationsteam verschwindet. Ohne diese Schritte bleibt Lift & Shift das, wofür es nie gedacht war: nicht der erste Schritt einer Transformation, sondern ihr vorzeitiges Ende.

*Nadine Riederer ist CEO des IT-Dienstleisters Avision.

7099 Artikel zu „Cloud Kosten“

Cloud Computing | Digitale Transformation | Geschäftsprozesse | Industrie 4.0 | News | Outsourcing | Rechenzentrum | Services

Industrie will mit Cloud Kosten senken, Effizienz erhöhen und Märkte erschließen

11. Juli 2018

Mehrheit sieht große Herausforderungen bei Komplexität und Datenintegration in der Multi-Cloud. Eine Studie hat den aktuellen Stand sowie künftige Entwicklungen in deutschen und schweizerischen Fertigungsunternehmen bei der Nutzung von Cloud Services untersucht. Demnach sieht die Industrie einen großen Wertbeitrag von Cloud-Lösungen vor allem bei den geschäftlichen Herausforderungen Kosten- und Effizienzdruck im IT-Betrieb (78 %), Erschließung…