Die meisten Cloud-Migrationen scheitern nicht in der Cloud. Sie scheitern an einer Architektur-Entscheidung, die niemand bewusst getroffen hat.
Das klingt zugespitzt, ist aber das Muster hinter den teuren Projekten: Ein Unternehmen verschiebt seine Anwendung „in die Cloud", weil das Rechenzentrum ausläuft oder der Vorstand ein Cloud-Ziel ausgegeben hat. Die Software bleibt dieselbe, nur läuft sie jetzt auf gemieteter statt eigener Hardware. Sechs Monate später ist die Rechnung höher als vorher, die Anwendung nicht schneller, und niemand kann sagen, was eigentlich besser geworden ist.
Cloud-Migration und Software-Architektur sind keine zwei getrennten Themen, sondern dieselbe Entscheidung aus zwei Blickwinkeln. Die Frage ist nie nur „Wohin verlagern wir das?", sondern immer auch „In welcher Form?". Dieser Guide führt durch beide: die Wege in die Cloud, die Architektur-Grundsatzfrage dahinter und den pragmatischen Pfad, der für die meisten Mittelständler richtig ist.
Cloud-Migration ist eine Architektur-Entscheidung, keine Infrastruktur-Aufgabe
Der erste Reflex bei einer Cloud-Migration ist der falsche: Man behandelt sie als Umzug. Server abbauen, woanders wieder aufbauen, Kabel umstecken. Tatsächlich entscheidet sich der Erfolg an einer Frage, die mit Servern wenig zu tun hat: wie viel von der bestehenden Struktur man mitnimmt und wie viel man unterwegs neu ordnet.
Genau hier setzt das etablierte Raster der Cloud-Migration an, das Amazon Web Services als „7 R's" bekannt gemacht hat. Es sind sieben grundsätzliche Wege, eine Anwendung in die Cloud zu bringen, und sie unterscheiden sich nicht in der Technik, sondern im Grad der Veränderung an der Architektur:
| Strategie | Was passiert | Wann sinnvoll |
|---|---|---|
| Rehost („Lift & Shift") | Anwendung 1:1 in die Cloud verschieben, kein Codeumbau | Schnell raus aus dem alten Rechenzentrum, Zeitdruck, wenig Ressourcen |
| Relocate | Ganze virtualisierte Umgebung auf Hypervisor-Ebene verlagern (z. B. VMware-Workloads nach VMware Cloud on AWS), ohne Betriebssystem oder Anwendung zu ändern | Großer VMware-Bestand, der am Stück umziehen soll |
| Replatform („Lift, Tinker & Shift") | Verlagern plus gezielte Optimierung, etwa eigene DB → Managed Service | Betriebsaufwand senken, ohne den Code neu zu bauen |
| Repurchase („Drop & Shop") | Eigenentwicklung durch ein SaaS-Produkt ersetzen | Standardprozess, für den es gute fertige Software gibt |
| Refactor / Re-architect | Anwendung umbauen, um Cloud-Eigenschaften wirklich zu nutzen | Wenn das Altsystem die Skalierung bremst und die Anwendung strategisch ist |
| Retire | Abschalten, was niemand mehr braucht | Altlasten, die im Migrationsaudit auffallen |
| Retain | Bewusst (vorerst) lassen, wo es ist | Was sich nicht lohnt oder rechtlich gebunden ist |
Kurz gesagt: Je weiter unten in dieser Tabelle, desto mehr Architektur-Arbeit und desto mehr potenzieller Nutzen. Rehost ist der schnellste Weg und liefert am wenigsten. Refactor ist der teuerste und liefert am meisten, sofern die Anwendung es wert ist.
Der häufigste Fehler im Mittelstand ist, alles per Rehost zu verschieben und auf den Cloud-Effekt zu warten, der nie kommt. Eine Anwendung, die auf einen einzigen großen Server ausgelegt ist, wird in der Cloud nicht plötzlich elastisch. Sie wird nur teurer, weil du jetzt für Bereitschaft zahlst, die du vorher abgeschrieben hattest. Replatforming ist für die meisten der bessere Default: managed Datenbank, managed Container, weniger Betrieb, ohne gleich die halbe Codebasis anzufassen. Und Refactor hebst du dir für die ein, zwei Systeme auf, die wirklich dein Geschäft tragen.
Monolith, Microservices oder modularer Monolith: die Architektur-Grundsatzfrage
Sobald „Refactor" auf dem Tisch liegt, steht die eigentliche Frage der Software-Architektur im Raum: Wie schneidest du die Anwendung? Und hier hält sich seit Jahren ein Missverständnis, das mehr Mittelstands-Budgets verbrannt hat als jeder Cloud-Anbieter: dass „modern" gleichbedeutend mit „Microservices" sei.
Es gibt im Kern drei Architektur-Muster, zwischen denen du wählst.
Der Monolith ist eine Anwendung, die als ein Stück gebaut, getestet und ausgeliefert wird. Lange galt das als Synonym für „Altlast". Zu Unrecht. Ein gut geschnittener Monolith ist für die meisten Anwendungen die schnellste und billigste Art, Software zu bauen und zu betreiben.
Microservices zerlegen dieselbe Anwendung in viele kleine, unabhängig auslieferbare Dienste, die über das Netzwerk miteinander reden. Das gibt großen Organisationen mit vielen parallel arbeitenden Teams Unabhängigkeit und erkauft sie mit einem verteilten System, das ungleich schwerer zu betreiben, zu überwachen und zu debuggen ist.
Der modulare Monolith ist der pragmatische Mittelweg, der sich gerade durchsetzt: eine Anwendung, die nach außen als ein deploybares Stück läuft, intern aber in klar abgegrenzte Module mit sauberen Grenzen geschnitten ist. Du bekommst die Ordnung von Microservices ohne die Betriebskosten eines verteilten Systems.
Ein Beispiel macht den Unterschied greifbar. Nimm einen B2B-Shop mit den Bereichen Katalog, Preisfindung, Checkout und Rechnungsstellung. Als Microservices wären das vier separat deploybare Dienste mit vier Datenbanken, die über das Netzwerk kommunizieren: maximale Unabhängigkeit, maximaler Betriebsaufwand. Als modularer Monolith sind es vier Module in einer Anwendung, jedes mit klarer Grenze und eigener interner Schnittstelle, aber gemeinsam ausgeliefert. Braucht die Preisfindung später wirklich eigene Skalierung, weil sie unter Last steht, lässt sie sich genau an dieser vorbereiteten Grenze als eigener Dienst herauslösen. Du zahlst die Komplexität erst, wenn du sie brauchst, nicht vorsorglich am ersten Tag.
Microservices: der teuerste Weg, ein Problem zu lösen, das du vielleicht nicht hast
Jetzt die unbequeme Wahrheit, gegen die ein Teil der Branche immer noch ankämpft: Für die meisten Mittelständler sind Microservices die falsche Wahl. Nicht, weil die Technik schlecht wäre, sondern weil sie ein Problem lösen, das du wahrscheinlich nicht hast, und dafür Kosten erzeugen, die du sicher hast.
Das prominenteste Beispiel dafür kommt nicht von einem Microservices-Skeptiker, sondern aus dem Maschinenraum von Amazon. Das Prime-Video-Team beschrieb 2023 öffentlich, wie es ein verteiltes, serverlos aufgebautes Werkzeug zur Audio- und Videoqualitäts-Überwachung wieder zu einer einzigen, monolithischen Anwendung zusammengeführt hat und damit die Betriebskosten dieses Bausteins um über 90 Prozent senkte. Wichtig zur Einordnung: Das betraf einen einzelnen Baustein, nicht Prime Video als Ganzes, und andere Teile des Dienstes laufen weiter als Microservices. Aber die Lehre sitzt. Selbst ein Unternehmen, das Microservices erfunden zu haben scheint, baut sie dort zurück, wo sie der falsche Schnitt waren.
Die Rechnung ist unromantisch. Jeder Microservice braucht eigene Auslieferung, eigene Überwachung, eigene Fehlersuche über Netzwerkgrenzen hinweg. Was im Monolithen ein simpler Funktionsaufruf ist, wird im verteilten System ein Netzwerk-Call, der langsamer ist und auf neue Arten kaputtgehen kann. Diesen Aufwand trägt ein Konzern mit fünfzig Entwicklerteams locker, weil er dafür Team-Unabhängigkeit bekommt, die er dringend braucht. Ein Mittelständler mit acht Entwicklern bekommt nur den Aufwand.
Die Faustregel, die wir Kunden in dieser Situation an die Hand geben: Microservices sind eine Antwort auf ein Organisations-Problem, nicht auf ein Technik-Problem. Wenn du nicht mehrere Teams hast, die sich beim Ausliefern gegenseitig blockieren, hast du das Problem nicht, das Microservices lösen. Dann ist der modulare Monolith fast immer die bessere Architektur, und du behältst die Option, später einzelne Module herauszulösen, ohne sie dir heute teuer zu erkaufen.
API-Entwicklung: das Bindegewebe, das über Erfolg entscheidet
Es gibt einen Moment, an dem jede Architektur-Entscheidung ihre Quittung bekommt: wenn das nächste System angebunden werden soll. Eine neue Mobile-App, ein Marktplatz-Konnektor, ein ERP-Wechsel. Genau dann zeigt sich, ob die Schnittstellen tragen oder ob jede Anbindung ein eigenes kleines Projekt wird. API-Entwicklung ist deshalb nicht der dekorative Teil am Schluss, sondern die tragende Struktur. In einer Cloud-Architektur reden Dienste, Datenbanken, externe Systeme und Frontends über APIs miteinander. Sind die schlecht geschnitten, vererbt sich jede schlechte Entscheidung an alles, was daran hängt.
Ein API-first-Ansatz dreht die übliche Reihenfolge um: Du entwirfst den Vertrag der Schnittstelle, bevor du die Implementierung dahinter baust. Das hat einen handfesten Vorteil. Frontend, Mobile-App und Drittsysteme können gegen den vereinbarten Vertrag entwickeln, während das Backend noch entsteht. Die Schnittstelle wird zur Planungsgrundlage statt zum Nebenprodukt, und die Teams blockieren sich nicht gegenseitig, weil alle wissen, worauf sie sich verlassen können.
Drei Grundsätze, die sich in der Praxis bewähren:
- Verträge sind verbindlich, nicht beiläufig. Eine API ist ein Versprechen an alle, die sie nutzen. Ändert sich das Versprechen unangekündigt, brechen Integrationen reihenweise. Versioniere bewusst und dokumentiere jede Änderung, statt stillschweigend umzubauen.
- Schneide entlang der Fachlichkeit, nicht entlang der Datenbanktabellen. Eine gute API bildet ab, was der Nutzer fachlich tun will, nicht, wie die Tabelle intern aussieht. Das ist der Unterschied zwischen einer Schnittstelle, mit der man gern arbeitet, und einer, die jeder umgeht und durch eigene Workarounds ersetzt.
- Behandle Sicherheit und Rate-Limiting als Teil des Designs. Eine offene API ohne klare Authentifizierung und Drosselung ist keine Schnittstelle, sondern ein Einfallstor. Beides gehört in den Entwurf, nicht in eine spätere Härtungsrunde.
Kurz gesagt: Eine saubere API-Schicht ist das, was eine Cloud-Architektur erweiterbar hält. Sie ist auch der Punkt, an dem sich später entscheidet, ob du ein Modul ohne Schmerzen herauslösen kannst oder ob du es nur mit der Brechstange aus dem Rest reißt.
Der Entscheidungs-Pfad: ein pragmatisches Vorgehen
Theorie hilft wenig, wenn am Montag die Entscheidung ansteht. Deshalb der Pfad, den wir in der Praxis empfehlen, bewusst in dieser Reihenfolge, weil jede Stufe die nächste vorbereitet.
Zuerst klärst du den Geschäftswert pro System, nicht die Technik. Welche Anwendung trägt direkt Umsatz oder Differenzierung, welche ist Standard-Betrieb? Diese Antwort entscheidet, welche der 7 R's pro System richtig ist. Eine austauschbare Standardanwendung gehört in „Repurchase" (ein SaaS kaufen) oder „Replatform", nicht in ein teures Refactor.
Dann wählst du die Migrationsstrategie pro System statt pauschal. Kein Unternehmen kommt mit einer einzigen der 7 R's aus. Ein realistisches Portfolio mischt: das meiste per Rehost oder Replatform, ein kleinerer Teil Refactor für die strategischen Systeme, ein paar Altlasten in Retire. Wer alles refactored, verbrennt Budget. Wer alles nur rehostet, holt den Cloud-Nutzen nie ab.
Erst für die Systeme, die ein echtes Refactor verdienen, stellt sich die Architektur-Frage. Und da lautet der Default: modularer Monolith, sauber geschnitten, mit klaren API-Grenzen. Microservices nur dort, wo ein nachweisbares Organisations- oder Skalierungsproblem es rechtfertigt, nicht, weil es modern klingt.
| Situation | Empfehlung |
|---|---|
| Rechenzentrum läuft aus, Zeitdruck | Rehost / Replatform, Architektur später |
| Standardprozess, gutes SaaS verfügbar | Repurchase |
| Strategisches Kernsystem bremst Wachstum | Refactor → modularer Monolith |
| Mehrere Teams blockieren sich beim Deployment | Refactor → gezielt Microservices an den Reibungsstellen |
| System ohne Zukunft, aber noch in Betrieb | Retire planen, vorerst Retain |
Wo es schiefgeht: die teuren Fehler
Drei Muster tauchen immer wieder auf, und alle drei kosten richtig Geld.
Das erste ist der Big-Bang-Umstieg. Alles auf einmal migrieren und neu schneiden, ein Stichtag, Daumen drücken. Das Bild dazu ist typisch: Freitagabend wird umgestellt, am Montag steht das halbe Unternehmen, und ein Zurück gibt es nicht, weil die alte Umgebung schon abgebaut wurde. Der belastbare Weg ist schrittweise: ein System nach dem anderen, mit der Möglichkeit, an jeder Stelle zurückzurudern. Eine Migration ohne Rückweg ist keine Migration, sondern ein Sprung ohne Netz.
Das zweite ist die Architektur, die niemand entschieden hat. Microservices, weil ein neu eingestellter Entwickler sie aus seinem letzten Job kennt. Ein bestimmter Cloud-Dienst, weil er gerade auf einer Konferenz gezeigt wurde. Eine Message-Queue, weil sie „später sicher nützlich" ist. Architektur, die aus solchen Einzelentscheidungen zusammenwächst statt aus einer bewussten Wahl, wird teuer und lässt sich kaum noch zurückbauen. Genau das war die These am Anfang dieses Textes.
Das dritte ist die vergessene Kostenkontrolle. Die Cloud rechnet pro Nutzung ab, und das ist Fluch und Segen zugleich. Ein typisches Muster: Eine Testumgebung wird hochgefahren und nie wieder abgeschaltet, ein überdimensionierter Datenbank-Knoten läuft monatelang im Leerlauf mit, und am Quartalsende fragt sich die Geschäftsführung, warum die Cloud teurer ist als das alte Rechenzentrum. Ohne klare Verantwortung für Kosten wächst die Rechnung still vor sich hin, weil niemand das Abschalten ungenutzter Ressourcen besitzt. Cloud-Kostenkontrolle gehört von Tag eins ins Projekt, nicht als Aufräumaktion, wenn die erste Schock-Rechnung kommt.
Die ehrliche Zusammenfassung
Cloud-Migration und Software-Architektur sind eine zusammenhängende Entscheidung, und die meisten Fehler entstehen, weil sie als zwei behandelt werden. Verschiebe nicht blind in die Cloud und hoffe auf einen Effekt. Entscheide pro System, was es wert ist, und wähle die Migrationsstrategie danach. Für die wenigen Systeme, die ein echtes Refactor verdienen, ist der modulare Monolith mit sauberen APIs in den allermeisten Mittelstands-Fällen die richtige Architektur, nicht das, was auf der letzten Konferenz am lautesten beworben wurde.
Am Anfang stand die These, dass Migrationen nicht in der Cloud scheitern, sondern an einer ungetroffenen Entscheidung. Der Umkehrschluss ist die eigentliche gute Nachricht: Es kostet kein zusätzliches Budget, diese Entscheidung bewusst zu treffen. Es kostet nur, sie zu vertagen.
Wenn ihr vor genau dieser Frage steht und eine ehrliche Einschätzung wollt, statt einer Architektur, die zufällig zum Lieblingswerkzeug des Anbieters passt: Das ist die Art von Entscheidung, bei der sich ein Gespräch mit jemandem lohnt, der beide Seiten gebaut hat. Wie wir an individuelle Business-Software und Systemarchitektur und Design herangehen, findest du auf unseren Leistungsseiten.