Beispiel für Cloud-Migration im Mittelstand

Der Montagmorgen beginnt mit einem Produktionsalarm: Das Kundenportal reagiert zu langsam, der nächtliche Import ist fehlgeschlagen und für einen Hotfix muss ein Administrator manuell auf einen Server zugreifen. Ein Beispiel für eine Cloud Migration im Mittelstand zeigt, warum das selten ein reines Infrastrukturproblem ist. Wer nur Server verlagert, nimmt bestehende Engpässe mit. Wer Architektur, Betrieb und Lieferprozesse modernisiert, schafft dagegen eine belastbare Grundlage für Wachstum.

Dieses anonymisierte, aber typische Szenario betrifft einen deutschen Hersteller mit rund 500 Beschäftigten. Vertrieb, Servicepartner und Kunden nutzen ein zentrales Portal für Bestellungen, Ersatzteile und technische Dokumentationen. Die Anwendung läuft auf virtuellen Maschinen im eigenen Rechenzentrum. Releases finden alle sechs bis acht Wochen statt, Kapazitäten werden langfristig geplant, und Betriebserfahrung liegt bei wenigen Personen. Die Plattform ist geschäftskritisch, aber sie bremst das Geschäft zunehmend aus.

Ausgangslage: Nicht der Server ist das eigentliche Problem

Die bestehende Plattform funktioniert grundsätzlich. Gerade das macht Entscheidungen schwierig: Es gibt keinen offensichtlichen Totalausfall, der eine sofortige Ablösung erzwingt. Gleichzeitig häufen sich operative Reibungsverluste. Entwicklungs- und Testumgebungen unterscheiden sich von der Produktion. Deployments erfolgen mit Handgriffen und Abstimmungen über mehrere Teams. Sicherheitsupdates konkurrieren mit Fachanforderungen um knappe Wartungsfenster.

Hinzu kommt ein typisches Kostenproblem: Die Hardware ist für Lastspitzen ausgelegt, die nur wenige Male im Jahr auftreten. Im Alltag bleibt ein erheblicher Teil der Kapazität ungenutzt. Neue Funktionen, etwa ein Händlerbereich oder Schnittstellen für Großkunden, benötigen zusätzliche Infrastruktur und verlängern die Durchlaufzeit. Die Frage lautet daher nicht: "Müssen wir in die Cloud?" Sie lautet: "Welche betrieblichen und geschäftlichen Engpässe wollen wir mit der Migration konkret beseitigen?"

Für das Unternehmen wurden vier messbare Ziele definiert: Releases sollten von mehreren Wochen auf wenige Tage verkürzt werden, kritische Ausfälle früher erkennbar sein, saisonale Last ohne manuelle Eingriffe abgefangen werden und die Kosten pro Plattform transparent werden. Diese Ziele verhindern, dass die Migration zu einem Technikprojekt ohne überprüfbaren Nutzen wird.

Das Beispiel Cloud-Migration im Mittelstand: Der realistische Zielzustand

Ein häufiger Fehler wäre gewesen, die virtuellen Maschinen unverändert zu einem Cloud-Anbieter zu verschieben. Dieser Lift-and-Shift-Ansatz kann sinnvoll sein, wenn ein Rechenzentrum kurzfristig verlassen werden muss oder Abhängigkeiten zunächst unkalkulierbar sind. Er reduziert den Aufwand zu Beginn, beseitigt aber weder manuelle Deployments noch fehlende Transparenz. Zudem können dauerhaft laufende, überdimensionierte Instanzen in der Cloud teuer werden.

Im Beispiel wurde deshalb ein schrittweiser Zielzustand festgelegt. Die Web-Anwendung und ihre Hintergrundjobs wurden containerisiert. Statische Inhalte und Dokumente wanderten in einen Objektspeicher. Die relationale Datenbank blieb zunächst bewusst als zentral verwalteter Dienst bestehen, statt sie vorschnell in viele technische Komponenten aufzuteilen. Das senkte den Betriebsaufwand und reduzierte das Risiko für die erste Migrationsphase.

Die Container laufen auf einer Kubernetes-Plattform, die für produktive Workloads ausgelegt ist. Wichtig ist dabei nicht Kubernetes als Selbstzweck. Entscheidend sind standardisierte Auslieferungen, klar definierte Ressourcen, kontrollierte Skalierung und ein Betriebsmodell, das auch bei Urlaub, Personalwechsel oder einem Incident funktioniert. Für kleinere Anwendungen kann eine verwaltete Container-Plattform die wirtschaftlichere Wahl sein. Die passende Technologie richtet sich nach Lastprofil, Teamkompetenz, Integrationen und Verfügbarkeitsanforderungen.

Migration in kontrollierten Etappen statt Big Bang

Die technische Umstellung begann nicht mit einem Cutover-Termin, sondern mit einer belastbaren Bestandsaufnahme. Das Team erfasste Abhängigkeiten zu ERP, Identity Provider, E-Mail-Versand, Dateifreigaben und externen Partner-Schnittstellen. Besonders relevant waren Datenflüsse: Welche Daten verlassen das Unternehmen, wo werden sie verarbeitet und welche Aufbewahrungs- oder Schutzanforderungen gelten?

Danach wurde die Cloud-Basis aufgebaut. Netzwerksegmente, Zugriffsrollen, Verschlüsselung, Protokollierung und Backup-Regeln wurden als Infrastrukturcode versioniert. Damit entsteht kein undokumentiertes Setup, das nur einzelne Administratoren verstehen. Änderungen lassen sich prüfen, wiederholen und nachvollziehen. Zugleich wird Sicherheit in den Bereitstellungsprozess integriert, statt sie erst kurz vor dem Go-live zu prüfen.

Erst reproduzierbar ausliefern, dann produktiv umschalten

Parallel zur Infrastruktur wurde eine CI/CD-Pipeline eingeführt. Jeder Merge löst automatisierte Tests, Sicherheitsprüfungen und den Build eines versionierten Artefakts aus. Die Bereitstellung in Test- und Staging-Umgebungen erfolgt über denselben Prozess wie später in Produktion. Das reduziert Fehler durch abweichende Konfigurationen und schafft eine klare Rückfalloption, falls eine Version Probleme verursacht.

Für die Datenbank wurde eine Replikation eingerichtet. Während die alte Plattform weiterlief, synchronisierte sich der Datenbestand in die neue Umgebung. Funktionale Tests, Lasttests und ein Wiederherstellungstest zeigten nicht nur, ob die Anwendung startet, sondern ob sie unter realistischen Bedingungen verlässlich arbeitet. Erst nachdem Messwerte, Schnittstellen und Betriebsabläufe stimmten, erfolgte die Umschaltung in einem geplanten Wartungsfenster.

Ein Big Bang wäre hier unnötig riskant gewesen. Die stufenweise Migration verlangte zwar mehr Disziplin bei Schnittstellen und Datenabgleichen. Dafür blieb die Plattform während des Umbaus verfügbar, und das Team konnte Annahmen anhand echter Betriebsdaten korrigieren.

Betrieb ist Teil der Migration, nicht die Phase danach

Nach dem Go-live beginnt die Arbeit, die über den Erfolg entscheidet. Im Beispiel wurden technische Metriken wie Antwortzeiten, Fehlerraten, Datenbankauslastung und Ressourcennutzung mit fachlichen Signalen verbunden. Dazu gehörten fehlgeschlagene Bestellungen, verzögerte Imports und nicht zugestellte Bestätigungen. Ein Dashboard allein löst keinen Incident. Es schafft aber die Voraussetzung, Ursachen früher einzugrenzen und Verantwortliche gezielt zu alarmieren.

Auch die Bereitschaft wurde klar geregelt: Welche Störungen müssen sofort behandelt werden, welche können bis zum nächsten Werktag warten, und wer entscheidet bei einem Rollback? Runbooks dokumentieren wiederkehrende Abläufe wie das Wiederherstellen eines Backups oder die Analyse eines fehlgeschlagenen Deployments. Das ist keine Bürokratie. Es verringert die Abhängigkeit von Einzelpersonen und macht Reaktionen unter Zeitdruck verlässlicher.

Die Resultate im Beispiel werden nicht allein an Cloud-Diensten gemessen. Entscheidend ist der Ablauf: Neue Funktionen können nach automatisierten Prüfungen mehrfach pro Woche ausgeliefert werden. Lastspitzen während einer Ersatzteilaktion werden über Skalierungsregeln abgefangen. Störungen werden anhand definierter Service-Level-Ziele bewertet. Und das interne Team investiert weniger Zeit in manuelle Wartung, weil wiederholbare Aufgaben automatisiert sind.

Cloud-Kosten müssen steuerbar bleiben

Mehr Flexibilität führt nicht automatisch zu niedrigeren Kosten. In der Cloud wird Verbrauch sichtbar und variabel. Ohne klare Verantwortlichkeiten entstehen oft dauerhaft laufende Testumgebungen, übergroße Datenbanken oder ungenutzte Speicherbestände. Deshalb gehörte FinOps von Beginn an zur Umsetzung.

Im Szenario wurden Kosten nach Umgebung, Produktbereich und verantwortlichem Team zugeordnet. Budgets und Warnschwellen machten Abweichungen früh sichtbar. Ressourcen erhielten verbindliche Tags, und nicht produktive Umgebungen wurden außerhalb benötigter Zeiten heruntergefahren. Für planbare Grundlasten prüfte das Unternehmen vergünstigte Nutzungsmodelle, während variable Last bewusst flexibel blieb.

Dabei gilt: Die günstigste Konfiguration ist nicht immer die wirtschaftlichste. Eine kleinere Datenbankinstanz kann Kosten senken, aber bei hoher Auslastung die Nutzererfahrung verschlechtern und operative Arbeit erzeugen. FinOps bedeutet daher nicht pauschal sparen. Es bedeutet, technische Entscheidungen mit Verbrauch, Risiko und Geschäftsnutzen zu verbinden.

Was Mittelständler aus dem Beispiel mitnehmen sollten

Die Migration war erfolgreich, weil sie kein isoliertes Infrastrukturvorhaben blieb. Geschäftsziele, Anwendungsarchitektur, Sicherheitsanforderungen, Delivery-Prozess und Betrieb wurden gemeinsam betrachtet. Wo interne Kapazitäten begrenzt sind, braucht es einen Partner, der nicht nach dem Architekturworkshop aussteigt, sondern Verantwortung bis zum produktionsreifen Betrieb übernimmt. devRocks verbindet diese Perspektive aus Engineering, Automatisierung und dauerhaftem Plattformbetrieb.

Der sinnvollste erste Schritt ist selten die Auswahl eines Cloud-Produkts. Er ist eine ehrliche Bewertung der kritischen Anwendung: Welche Ausfälle kosten wirklich Geld? Wo warten Teams auf manuelle Freigaben? Welche Last ist planbar, welche volatil? Und welche Kompetenzen sollen dauerhaft intern aufgebaut werden? Wer diese Fragen konkret beantwortet, kann eine Migration so zuschneiden, dass sie nicht nur neue Infrastruktur liefert, sondern im Alltag schneller, sicherer und wirtschaftlicher arbeitet.