Im ersten Teil dieser Serie haben wir beleuchtet, warum Lift and Shift verlockend erscheint – und welche Fallstricke dahinterstecken. Doch die eigentlich spannende Frage lautet: Was ist die Alternative? Wie sieht ein moderner, cloud-nativer Ansatz aus – und lohnt sich der Aufwand?

In diesem Artikel vergleichen wir beide Wege anhand eines konkreten Szenarios: einer klassischen .NET-Webanwendung, die jahrelang lokal lief und nun in die Cloud soll. Wir schauen uns an, wie ein typisches Lift-and-Shift-Setup aussieht, wie die Cloud-Native-Variante funktioniert – und wann sich welcher Weg wirtschaftlich rechnet.

“Die Cloud verwaltet Infrastruktur – wenn man sie lässt.”

Typisches Lift-and-Shift-Setup am Beispiel einer .NET-Webanwendung

Stellen wir uns ein mittelständisches Unternehmen vor, das seit Jahren eine interne Webanwendung betreibt: Kundenverwaltung, Auftragssystem, vielleicht ein kleines CRM. Die Anwendung läuft auf einem eigenen Server im Keller oder in einem gemieteten Rechenzentrum. Das Setup ist klassisch gewachsen – und funktioniert.

Nun steht die Entscheidung an: Die Hardware altert, der Wartungsvertrag läuft aus, und man will „in die Cloud”. Der einfachste Weg ist Lift and Shift – die Anwendung wird 1 übertragen.

So sieht das typische Setup aus:

Webserver: Der lokale IIS-Server wird durch eine Azure Virtual Machine ersetzt. Windows Server, IIS, ASP.NET – alles bleibt, wie es war, nur dass die Maschine jetzt in Azure läuft statt im eigenen Rechenzentrum.

Datenbank: Der SQL Server, der bisher lokal auf einem dedizierten Server lief, wird ebenfalls als VM in Azure provisioniert. Die Datenbank selbst bleibt unverändert, die Verbindungsstrings werden angepasst – fertig.

Dateispeicher: Dokumente, Uploads oder Logs lagen bisher auf einer Netzwerkfreigabe. In der Cloud wird das durch Azure Fileshare abgebildet – ein Netzwerklaufwerk in der Cloud, das sich wie eine klassische Windows-Freigabe verhält.

Authentifizierung: Bisher authentifizierten sich Nutzer über das lokale Active Directory. In Azure wird das durch Azure AD Domain Services nachgebildet – eine verwaltete AD-Instanz, die das alte System simuliert.

Monitoring & Logging: Bisher wurden Logs in Textdateien geschrieben oder zentral in System Center gesammelt. In der Cloud wird rudimentär Azure Monitor integriert, oft aber nur, um die VM-Metriken zu überwachen – nicht die Anwendung selbst.

Das Ergebnis: Die Anwendung läuft „wie vorher”, aber auf fremder Hardware. Alle Wartungsaufgaben bleiben erhalten: Windows-Updates müssen manuell eingespielt werden, die Datenbank muss gepatcht werden, Backups müssen konfiguriert und überwacht werden. Man zahlt Cloud-Preise, arbeitet aber wie im eigenen Rechenzentrum.

Das ist der entscheidende Punkt: Man hat die Last verlagert, aber nicht abgegeben.

Cloud-Native-Alternative im gleichen Szenario

Doch es geht auch anders. Eine cloud-native Architektur nutzt die verwalteten Dienste der Cloud-Plattform – und gibt Verantwortung ab, wo es sinnvoll ist.

Webserver: Statt einer virtuellen Maschine wird die Anwendung auf Azure App Service gehostet – einer Platform-as-a-Service-Lösung (PaaS), die das Betriebssystem, den Webserver und viele Sicherheitsaspekte automatisch verwaltet. Alternativ lässt sich die Anwendung containerisieren und auf Azure Kubernetes Service (AKS) betreiben – was mehr Flexibilität bietet, aber auch etwas mehr Know-how erfordert.

Datenbank: Statt SQL Server auf einer VM nutzt man Azure SQL Database – eine vollständig verwaltete Datenbank. Microsoft kümmert sich um Backups, Hochverfügbarkeit, Skalierung und Sicherheitspatches. Die Anwendung greift darauf zu wie auf jede andere SQL-Datenbank – aber ohne dass man sich um die Infrastruktur darunter kümmern muss.

Speicher: Dokumente und Dateien landen nicht mehr auf einer Netzwerkfreigabe, sondern in Azure Blob Storage oder Azure Data Lake – skalierbaren, kostengünstigen Objektspeichern, die für Cloud-Workloads optimiert sind. Der Zugriff erfolgt über REST-APIs oder SDKs, was moderne Anwendungen ohnehin verwenden.

Authentifizierung: Statt eine simulierte Active-Directory-Umgebung zu betreiben, wird direkt Azure Active Directory B2C oder Managed Identities genutzt. Das bedeutet: moderne, sichere Authentifizierung ohne eigene Server, ohne Passwort-Hashes, ohne Legacy-Protokolle.

Monitoring & Logging: Mit Application Insights wird die Anwendung durchgängig überwacht – nicht nur die Infrastruktur, sondern auch Anfragen, Fehler, Performance-Engpässe und Nutzerverhalten. Logs werden automatisch gesammelt, indiziert und durchsuchbar gemacht. Skalierung erfolgt automatisch bei Lastspitzen, und das Fehlerhandling wird durch Health Checks und Self-Healing-Mechanismen unterstützt.

Das Ergebnis: Die Cloud verwaltet Infrastruktur, Skalierung, Sicherheit und viele wiederkehrende Aufgaben. Das Team konzentriert sich auf die eigentliche Geschäftslogik – nicht auf Systempflege.

Vergleich und Abwägung

Beide Ansätze haben ihre Berechtigung – aber sie lösen unterschiedliche Probleme.

Kontrolle vs. Entlastung
Lift and Shift bietet Kontrolle: Man weiß genau, wie das System aufgebaut ist, und kann tief in die Konfiguration eingreifen. Doch diese Kontrolle erkauft man sich mit Verantwortung. Jedes Update, jede Sicherheitslücke, jede Skalierungsanforderung liegt in der eigenen Hand.

Cloud-Native hingegen gibt Verantwortung ab – bewusst. Man verliert zwar die Kontrolle über manche Details, gewinnt aber Zeit und Stabilität. Die Cloud übernimmt das, was sie besser kann als jedes interne Team: Verfügbarkeit, Skalierung, Sicherheitspatches.

Initialer Aufwand vs. langfristige Kosten
Lift and Shift ist schnell umgesetzt – aber das ist nur der Anfang. Die laufenden Kosten bleiben hoch: VM-Instanzen laufen rund um die Uhr, Speicher wird überdimensioniert provisioniert, und die Administrationszeit bleibt konstant.

Cloud-Native erfordert initial mehr Aufwand: Die Anwendung muss angepasst werden, neue Dienste müssen integriert werden, und das Team muss sich mit PaaS-Konzepten vertraut machen. Doch langfristig sinken die Betriebskosten deutlich – sowohl finanziell als auch personell.

Integrierte Features vs. manuelle Nachrüstung
Ein oft unterschätzter Unterschied liegt in den integrierten Features. Bei Cloud-Native sind Authentifizierung, Autorisierung, Backup, Logging und Skalierung bereits Teil der Plattform. Man aktiviert sie, konfiguriert sie – und sie funktionieren.

Im Lift-and-Shift-Bereich muss man all das manuell nachrüsten: Backup-Strategien entwickeln, Monitoring-Tools installieren, Skalierungs-Scripte schreiben. Das kostet nicht nur Zeit, sondern ist auch fehleranfällig.

Entwicklerzeit auf Unternehmensprobleme fokussiert
Der vielleicht wichtigste Unterschied: Bei Cloud-Native verbringt das Entwicklungsteam mehr Zeit mit der Lösung von Unternehmensproblemen – und weniger mit Systempflege. Statt sich um Betriebssystem-Updates oder Datenbankreplikation zu kümmern, können sie neue Features entwickeln, Prozesse optimieren oder die User Experience verbessern.

KI-Unterstützung senkt Portierungsaufwand
Mit modernen KI-Tools wie GitHub Copilot, Azure Dev Tools oder spezialisierter AI-Assistenz sinkt der Aufwand für die Portierung zusätzlich. Code kann analysiert, automatisch migriert und an Cloud-Dienste angepasst werden. Was früher Wochen dauerte, lässt sich heute in Tagen bewältigen – wenn man die richtigen Werkzeuge einsetzt.

Der wirtschaftliche Blick: Wann lohnt sich eine Neuentwicklung?

Die entscheidende Frage für jedes Unternehmen lautet: Ab wann lohnt sich der Umbau? Wann ist es sinnvoll, die bestehende Anwendung zu modernisieren, statt sie einfach zu verlagern?

Die Kostenrealität einer VM-Landschaft
Eine typische Azure-VM für eine mittelgroße Webanwendung kostet schnell 200 bis 500 Euro pro Monat – je nach Größe, Region und Reserved-Instance-Rabatten. Dazu kommen Kosten für Datenbankserver, Speicher, Backups und Datentransfer. Über fünf Jahre summiert sich das auf 15.000 bis 30.000 Euro – nur für die Infrastruktur.

Hinzu kommt die Arbeitszeit: Wenn ein Systemadministrator 10 Stunden pro Monat mit Wartung, Updates und Monitoring beschäftigt ist, sind das bei einem Stundensatz von 80 Euro weitere 9.600 Euro über fünf Jahre. Insgesamt also rund 25.000 bis 40.000 Euro – für ein System, das technisch auf dem Stand von vor zehn Jahren bleibt.

Die Alternative: Cloud-Native mit geringeren Betriebskosten
Eine cloud-native Architektur mit Azure App Service und Azure SQL Database kostet in vergleichbaren Szenarien oft nur 60 bis 70 Prozent der VM-Kosten – und das bei deutlich geringerem Administrationsaufwand. Wenn der Wartungsaufwand auf 2 Stunden pro Monat sinkt, spart man allein an Arbeitszeit über 7.000 Euro in fünf Jahren.

Einmalaufwand für die Portierung
Der Umbau einer bestehenden .NET-Anwendung auf eine cloud-native Architektur kostet je nach Komplexität zwischen 20.000 und 80.000 Euro. Das klingt nach viel – aber verteilt auf fünf Jahre relativiert sich das: Die Ersparnis durch geringere Betriebskosten gleicht die Investition oft schon nach zwei bis drei Jahren aus.

Kriterien für die Entscheidung
Nicht jede Anwendung sollte modernisiert werden. Die Entscheidung hängt von mehreren Faktoren ab:

• Zukunftsplan der Software: Wird die Anwendung noch zehn Jahre genutzt? Oder ist sie ein Auslaufmodell, das bald ersetzt wird? Bei kurzer Restlaufzeit kann Lift and Shift sinnvoll sein.

• Integrationsfähigkeit: Muss die Anwendung mit modernen APIs, Microservices oder Drittanbietern kommunizieren? Dann spricht vieles für Cloud-Native.

• Anpassbarkeit: Wie flexibel ist die Software? Kann man sie anpassen, oder ist sie eine proprietäre Black Box? Bei unflexiblen Legacy-Systemen bleibt manchmal nur Lift and Shift – oder eine Neuanschaffung.

• Regulatorische Anforderungen: Unterliegt die Anwendung strengen Compliance-Vorgaben? Manche Branchen verlangen bestimmte Zertifizierungen oder Datenhaltungsmodelle, die nur mit bestimmten Cloud-Diensten kompatibel sind.

• Abhängigkeit vom Softwarehersteller: Wird die Lösung noch aktiv weiterentwickelt? Gibt es Roadmaps für Cloud-Kompatibilität? Oder ist die Software ein Auslaufmodell, bei dem langfristig ohnehin eine Ablösung ansteht?

Beispielrechnung: 5 Jahre VM-Betrieb vs. Cloud-Native-Portierung

Nehmen wir ein konkretes Szenario:

Lift and Shift über 5 Jahre:

• VM-Kosten: 300 €/Monat = 18.000 €
• SQL-VM: 200 €/Monat = 12.000 €
• Speicher, Backup, Netzwerk: 50 €/Monat = 3.000 €
• Administrationszeit: 10 Std./Monat × 80 €/Std. × 60 Monate = 48.000 €
• Gesamtkosten: 81.000 €

Cloud-Native über 5 Jahre:

• App Service: 150 €/Monat = 9.000 €
• Azure SQL Database: 120 €/Monat = 7.200 €
• Blob Storage, Monitoring: 30 €/Monat = 1.800 €
• Administrationszeit: 2 Std./Monat × 80 €/Std. × 60 Monate = 9.600 €
• Einmaliger Portierungsaufwand: 40.000 €
• Gesamtkosten: 67.600 €

Die Ersparnis liegt bei rund 13.400 Euro – und das bei einem System, das moderner, wartungsärmer und zukunftssicherer ist.

---

Die Entscheidung zwischen Lift and Shift und Cloud-Native ist keine technische Glaubensfrage, sondern eine wirtschaftliche Abwägung. Wer langfristig plant, Kosten senken und Entwicklerzeit sinnvoll einsetzen will, kommt an einer modernen Architektur kaum vorbei.

Im nächsten Teil dieser Serie schauen wir uns an, wie eine Migration in der Praxis abläuft – welche Schritte notwendig sind, welche Stolpersteine lauern und wie man das Risiko minimiert. Denn die beste Architektur nützt nichts, wenn die Migration scheitert.