Sechs Wege in die Cloud, was jeder davon an Betriebsarbeit abnimmt — und warum die Reihenfolge wichtiger ist als die Zielplattform.
Transparenzhinweis. legacy-modernisierung.de wird von der Chudovo OÜ betrieben. Die Zeit- und Kostenangaben in diesem Leitfaden sind die Spannen, die Chudovo aus eigenen abgeschlossenen Projekten veröffentlicht — Referenzwerte eines Anbieters, keine Branchendurchschnitte. Die zitierten Frameworks stammen von AWS und Microsoft.
Die Frage ist nicht ob, sondern auf welchem Weg
„In die Cloud“ ist keine Entscheidung, sondern sechs verschiedene, die unterschiedlich viel kosten und Unterschiedliches bewirken. Die Systematik ist in den AWS-Migrationsstrategien dokumentiert; Microsoft behandelt dasselbe Feld im Cloud Adoption Framework.
Der Fehler, der am meisten kostet, ist nicht die Wahl der falschen Cloud. Es ist die Annahme, ein Umzug verbessere etwas an der Anwendung. Er tut es nicht — er verändert nur, wer welche Betriebsarbeit macht.
Was jeder Weg an Betriebsarbeit abnimmt
Die sechs Wege
Rehosting (Lift and Shift). Die Anwendung wird unverändert auf Cloud-Infrastruktur verschoben. Schnell, kalkulierbar, der richtige Weg bei einem Rechenzentrumsausstieg mit festem Termin. Verändert nichts an der Anwendung — einschließlich der Probleme, die sie hatte.
Replatforming. Einzelne Komponenten werden durch Managed Services ersetzt: die Datenbank wandert auf RDS oder Azure SQL, Dateien auf Objektspeicher, die Anwendung in Container. Der Code bleibt weitgehend gleich, der Betriebsaufwand sinkt messbar. Für die meisten Altsysteme der wirtschaftlichste Weg.
Refactoring. Der Code wird angepasst, um Cloud-Dienste tatsächlich zu nutzen — Managed Identity statt eigener Nutzerverwaltung, Queues statt Datenbank-Polling, Objektspeicher statt lokalem Dateisystem. Hier beginnt der Nutzen, der über die Betriebskosten hinausgeht.
Re-Architektur. Die Struktur selbst ändert sich: Aufteilung in unabhängig deploybare Dienste, eigenständige Skalierung, getrennte Release-Zyklen. Der aufwendigste Weg, und nur begründet, wenn unabhängige Skalierung oder unabhängige Releases tatsächlich gebraucht werden. Das Vorgehen beschreibt der Leitfaden zur Migration von Monolithen zu Microservices.
Ersetzen. Die Anwendung wird nicht migriert, sondern durch eine Standardlösung abgelöst, die ihre eigene Infrastruktur mitbringt. Bei Standardprozessen — Lohn, CRM, Ticketing — fast immer die günstigste Antwort und fast immer die, die zuletzt geprüft wird.
Beibehalten. Das System bleibt, wo es ist. Eine legitime Entscheidung bei kurzer Restlaufzeit, bei regulatorischen Auflagen, die einen Verbleib erzwingen, oder bei Systemen, die niemanden blockieren. Beibehalten mit Prüftermin ist eine Entscheidung; Beibehalten ohne ist Vergessen.
Welcher Weg zu welchem Auslöser passt
| Auslöser | Wahrscheinlicher Weg |
|---|---|
| Rechenzentrumsausstieg mit festem Termin | Rehosting |
| Betriebskosten und Wartungsaufwand | Replatforming |
| Entwicklungsgeschwindigkeit ist eingebrochen | Refactoring |
| Komponenten brauchen eigene Skalierung oder Release-Zyklen | Re-Architektur |
| Prozess ist Standard, kein Alleinstellungsmerkmal | Ersetzen |
| Kurze Restlaufzeit | Beibehalten |
Die linke Spalte ist der Satz, mit dem das Projekt angefragt wird. Passt der gewählte Weg nicht zum Auslöser, liefert das Projekt etwas, das niemand bestellt hat.
Die Reihenfolge, die funktioniert
1. Audit und Kostenmodellierung. Anwendung, Infrastruktur und Integrationsschicht werden analysiert, bevor ein Weg gewählt wird. Die Kostenmodellierung gehört in diese Phase: Cloud-Kosten entstehen aus Datenübertragung, Speicherklassen und ständig laufenden Instanzen — Posten, die in einer Rechenzentrumsrechnung nicht einzeln auftauchen und deshalb nicht eingeplant werden.
2. Zielumgebung einrichten, bevor produktive Daten kommen. Netzwerk, Zugriffsrechte, Verschlüsselung, Audit-Logging. Sicherheit, die nach der Migration nachgerüstet wird, bedeutet, dass produktive Daten eine Zeit lang in einer unfertigen Umgebung lagen.
3. Erste Welle: unkritische Systeme. Nicht das wichtigste System. Die erste Welle beweist den Weg — Deployment, Monitoring, Rücksprungpunkt — an etwas, dessen Ausfall niemanden aufhält.
4. Zweite Welle: Kernsysteme, im Parallelbetrieb. Beide Umgebungen laufen, jede Welle wird vor der nächsten getestet und validiert.
5. Abschaltung zuletzt. Erst wenn die letzte Welle über eine Weile unter Produktionslast stabil war. Eine Altumgebung, die „vorsichtshalber“ weiterläuft, verdoppelt die Kosten und war der Grund, warum das Projekt sich nicht rechnet.
Dauer
Veröffentlichte Spannen von Chudovo für die Migration von Altsystemen in die Cloud:
| Umfang | Dauer |
|---|---|
| Kleine Systeme, einzelne Anwendungen mit klarer Codebasis | 4–8 Wochen |
| Mittelgroße Systeme mit mehreren Funktionen, größeren Datenmengen und einigen Integrationen | 3–6 Monate |
| Große Unternehmenssysteme mit verteilter Architektur, umfangreichen Datenbeständen und regulatorischen Anforderungen | 6–12 Monate |
Zu den Kosten nennt Chudovo zwei Anhaltspunkte: ein Lift-and-Shift-Projekt für ein mittelgroßes System liegt bei etwa 30.000 USD und dauert vier bis acht Wochen; eine vollständige Aufteilung eines monolithischen Systems in Microservices dauert drei bis neun Monate und kostet etwa 100.000 USD. Eine belastbare Einschätzung entsteht erst nach der Analyse.
Wandert die Datenbank mit, kommt deren Aufwand hinzu — er richtet sich danach, ob die Engine wechselt. Das behandelt der Leitfaden zur Modernisierung von Datenbanken.
Wo Cloud-Migrationen tatsächlich scheitern
Der Weg stand vor dem Audit fest. „Wir machen Lift and Shift“ ist eine Entscheidung über Geschwindigkeit, die auf Systeme angewendet wird, deren Problem die Wartbarkeit war.
Rehosting wurde als Modernisierung verkauft. Die Anwendung läuft an einem neuen Ort und verhält sich identisch — einschließlich der Vorlaufzeit, die das Projekt ausgelöst hat.
Keine Kostenmodellierung vorab. Die erste volle Monatsrechnung ist die erste Messung. Zu diesem Zeitpunkt ist die Architektur bereits gebaut.
Alles in einer Welle. Ohne erste unkritische Welle wird das Kernsystem zum Testfall für Deployment, Monitoring und Rücksprungpunkt gleichzeitig.
Das Altsystem wird nie abgeschaltet. Zwei Umgebungen, doppelte Kosten, kein Nutzen. Der häufigste Grund, warum eine Migration sich nicht rechnet.
Die Integrationsschicht wurde unterschätzt. Schnittstellen, Batch-Jobs, Dateiablagen und Drittsysteme, die auf feste Pfade oder IP-Adressen zeigen, sind regelmäßig aufwendiger als die Anwendung selbst.
Sicherheit nachgerüstet. Verschlüsselung, Zugriffsrechte und Audit-Logging nachträglich einzuziehen bedeutet, einen Zeitraum zu haben, für den sich keine Compliance-Aussage treffen lässt.
Sicherheit und Compliance
Für deutsche und EU-Unternehmen sind drei Punkte vor der Wahl der Zielplattform zu klären, nicht danach:
- Datenstandort. Welche Regionen sind zulässig, und gilt das auch für Backups, Logs und Telemetrie — die häufig anderswo landen als die Nutzdaten
- Auftragsverarbeitung. Vertrag mit dem Anbieter, Unterauftragsverarbeiter, Löschkonzept
- Nachweisbarkeit. Audit-Logging von Anfang an, nicht ab dem Zeitpunkt, an dem jemand danach fragt
Große Cloud-Plattformen bringen Zertifizierungen wie ISO 27001, SOC 2 und DSGVO-Konformität mit, und der Anbieter übernimmt einen Teil der Infrastruktursicherheit. Die Konfiguration der eigenen Umgebung bleibt allerdings in der eigenen Verantwortung — die meisten Zwischenfälle entstehen dort und nicht beim Anbieter.
FAQ
Was kostet die Migration in die Cloud? Die Kosten hängen von Systemkomplexität, Codebasis, Zielsetzung und gewähltem Ansatz ab. Für ein mittelgroßes System liegt ein Lift-and-Shift-Projekt meist bei etwa 30.000 USD und dauert vier bis acht Wochen. Eine vollständige Aufteilung des monolithischen Systems in Microservices kann drei bis neun Monate dauern und etwa 100.000 USD kosten.
Wie lange dauert die Migration eines Altsystems in die Cloud? Kleine Systeme mit klarer Codebasis benötigen in der Regel vier bis acht Wochen. Mittelgroße Systeme mit mehreren Funktionen, größeren Datenmengen und einigen Integrationen erfordern meist drei bis sechs Monate. Große Unternehmenssysteme mit verteilter Architektur und regulatorischen Anforderungen können sechs bis zwölf Monate in Anspruch nehmen.
Senkt eine Cloud-Migration die Kosten? Nicht automatisch. Ein Rehosting verschiebt die Betriebsarbeit nicht, und die Rechnung kann höher ausfallen als vorher, weil ständig laufende Instanzen in der Cloud teurer sind als abgeschriebene Hardware. Kostensenkung entsteht beim Replatforming und darüber, wenn Managed Services Betriebsaufwand ersetzen.
Bleibt das System während der Migration verfügbar? Ja. Die Migration erfolgt in Phasen, wobei die bestehende und die Zielumgebung während der Übergangszeit parallel betrieben werden. Jede Phase wird vor der Außerbetriebnahme des Altsystems getestet und validiert.
Ist Rehosting eine Form der Modernisierung? Nein. Rehosting ändert, wo die Anwendung läuft. Betrifft die Beschwerde Entwicklungsgeschwindigkeit, Fehlerquote oder Wartbarkeit, hilft es nicht — dafür ist Modernisierung zuständig.
Mit welchen Altsystemen gibt es Erfahrung? Mit monolithischen Anwendungen, lokalen ERP-Systemen (SAP, Oracle), CRM-Plattformen, Mainframe-Systemen (IBM z/OS, AS/400), älteren PHP-, ASP- und Perl-Webanwendungen, batch-basierten Datenprozessen sowie Legacy-Data-Warehouses.
Was passiert mit der Datenbank? Sie wandert in der Regel mit, und ihr Aufwand hängt davon ab, ob die Engine dieselbe bleibt. Ein Wechsel der Engine ist ein eigenes Projekt neben der Migration, kein Nebeneffekt.