Written by:
Last Published:
15. September 2026
•
Kann man durch den Wechsel in die Cloud wirklich 40–50 % sparen?
Ja. Aber nicht so, wie Sie denken.
Die meisten Unternehmen, die über Cloud-Einsparungen sprechen, stellen es sich wie ein physikalisches Gesetz vor: „Wechsel von teurer On-Premise-Infrastruktur zu skalierbarer Cloud, und die Kosten sinken.“ Sauber. Und logisch. Aber falsch. Die Realität ist komplexer. Es geht weniger um die Technologie als vielmehr um das, wofür Sie tatsächlich bezahlen im Moment.
Die meisten Unternehmen haben jedoch keine Ahnung davon. Sie sehen einen Posten für „Infrastrukturkosten“ und haken das Thema ab. Dann versuchen sie zu modernisieren, ohne die versteckten Kosten zu erfassen – wie Lizenzen aus mehrjährigen Verträgen, redundante Hardware oder ein Betriebsteam, das nur dazu da ist, Altsysteme am Laufen zu halten. Solange man diese Fäden nicht entwirrt, wirkt Modernisierung riskant. Die gute Nachricht: Das ist sie auch, bis sie es nicht mehr ist.
Hier beginnt unsere Geschichte. TrustPortal, eine in Großbritannien ansässige Fintech- und Automatisierungsplattform, verbrannte Geld mit veralteter Infrastruktur. Sie hatten nicht das Ziel, 40–50 % zu sparen. Was sie taten, war zu verstehen, wofür sie tatsächlich bezahlten – und diese Klarheit veränderte alles.
So sehen die meisten Altsystemkosten in der Realität aus. Unterteilen wir sie in drei Bereiche: Softwarelizenzen (oft an mehrjährige Verträge mit Strafgebühren gebunden), Infrastruktur und Hosting (manchmal redundant, immer historisch teuer) sowie den operativen Arbeitsaufwand (die unsichtbare Steuer). Die meisten Unternehmen erfassen den Arbeitsaufwand nicht als Kostentreiber, obwohl sie es sollten. Ein Betriebsteam, das nur damit beschäftigt ist, Altsysteme am Laufen zu halten, ist im Vergleich zu Cloud-nativen Teams, die durch Automatisierung arbeiten, totes Kapital.
TrustPortal war ein mittelständisches, global agierendes Unternehmen. Ihre Altsystem-Infrastruktur sah nach Standard aus: Unternehmensdatenbanken, alte Anwendungsserver, On-Premise-Speicher, ein Managed-Hosting-Modell. Doch das machte die Kosten unsichtbar: Sie waren verstreut. Lizenzen fielen unter das IT-Budget, Infrastruktur unter die Gebäudeverwaltung und der Arbeitsaufwand unter den operativen Bereich. Die Finanzabteilung konnte das Gesamtbild nicht sehen, weshalb die Geschäftsführung die Modernisierung nicht rechtfertigen konnte.
Die meisten Kosten für Altsysteme lassen sich in drei Muster unterteilen:
Rechnen Sie das zusammen. Die meisten mittelständischen Unternehmen verfügen über eine Infrastruktur im Wert von mehreren Millionen Pfund, die keinen Wettbewerbsvorteil bietet. Sie ist einfach nur... da. Läuft.
Die meisten Unternehmen verstecken diese Kosten in verschiedenen Budgets. Wahrscheinlich tun Sie das auch.
Systematische Modernisierung erfordert Konsequenz. Welche Systeme generieren Umsatz? Welche verursachen nur Kosten? Und welche sind so eng mit Compliance-Vorgaben verknüpft, dass eine Migration regulatorischen Selbstmord bedeuten würde?
TrustPortal stand vor einer echten Herausforderung: Ihr Kernsystem für die Zahlungsabwicklung war aus regulatorischen und prüfungstechnischen Gründen an eine Legacy-Infrastruktur gebunden. Eine Neugestaltung für die Cloud hätte Jahre gedauert und Millionen gekostet. Das war keine Option. Stattdessen teilten sie ihre Workloads nach einem einfachen Prinzip auf:
In die Cloud migrieren: Die zentrale RPA- und Automatisierungsplattform von TrustPortal, Kunden-Dashboards, interne Reporting-Tools und Systeme zur Mitarbeiterproduktivität. Diese unterlagen keinen Compliance-Beschränkungen. Sie basierten auf modernen Architekturen (Angular, NodeJS, containerisierte Deployments in der Cloud-Infrastruktur), generierten echten Geschäftswert und waren direkt für Kunden zugänglich.
Legacy beibehalten: Zahlungsabwicklung. Die zentrale Transaktionsverarbeitung. Der regulatorische Aufwand war zu hoch. Das Risiko einer gescheiterten Migration war inakzeptabel.
Hybrid: Benutzeridentitätssysteme und Betrugserkennung. Diese mussten sowohl mit den Legacy- als auch mit den Cloud-Systemen kommunizieren. Daher wurde die Arbeitslast aufgeteilt: Cloud für die kundenorientierten Bereiche, Legacy für den sensiblen Kern.
Das Ergebnis: 70 % ihrer Infrastruktur wurden in die Cloud verlagert. 30 % blieben als Legacy-Systeme bestehen. Eine hybride Architektur.
Warum ist diese Aufteilung so wichtig? Weil sie realistisch ist. Die meisten Unternehmen gehen davon aus, dass „Cloud-Migration“ bedeutet, dass „alles in die Cloud wandert“. Das ist nicht der Fall. Es kann nicht alles migriert werden, wenn man den Umsatzfluss aufrechterhalten und die Regulierungsbehörden zufriedenstellen will. Der hybride Ansatz des Fintech-Unternehmens ermöglichte es, dort aggressiv zu modernisieren, wo es sicher war, und strategisch vorzugehen, wo es am meisten zählte. Einsparungen bei den Lizenzkosten ergaben sich aus den 70 %, die migriert wurden. Alles andere war reines Risikomanagement.
Die technische Migration war ehrgeizig, aber methodisch durchdacht. Sie dauerte Monate, nicht Jahre, und erforderte einen klaren Plan, ein festes Budget und dedizierte Kapazitäten im Team.
Die Modernisierung umfasste folgende Schritte:
Technische Migration: Datenreplikation, Refactoring der Anwendung (insbesondere der Wechsel zu modernen Frameworks wie Angular und NodeJS), Tests und Validierung. Das Team nutzte einen agilen Entwicklungsprozess in mehreren Wellen, um Risiken zu minimieren und Feedback einzuholen.
Parallelbetrieb: Das Fintech-Unternehmen betrieb das Altsystem und die Cloud über einen längeren Zeitraum parallel. Warum? Zur Absicherung. Sollte die Cloud-Bereitstellung katastrophal scheitern, konnte innerhalb von Stunden statt Tagen auf das Altsystem zurückgegriffen werden. Dieses Sicherheitsnetz ermöglichte es dem Team, schneller zu arbeiten, da es keine Angst vor unumkehrbaren Entscheidungen haben musste. Der psychologische Wert eines solchen Notausgangs wird oft unterschätzt.
Umschulung des Teams: Das Betriebsteam kannte die alte Infrastruktur in- und auswendig. Kubernetes, Cloud-Observability-Plattformen, Kostenmanagement-Tools oder CI/CD-Pipelines waren jedoch Neuland. Das Unternehmen investierte in externe Schulungen sowie interne Workshops und gab dem Team die nötige Zeit zum Lernen. Einige Mitarbeiter verließen das Unternehmen in dieser Phase: Die Veränderungen waren zu umfangreich und zu schnell. Andere blieben und entwickelten sich von „Infrastruktur-Verwaltern“ zu Architekten.
Umstellung der Tools: Der Wechsel von herkömmlichem Monitoring und Logging zu Cloud-nativen Tools verlief unruhiger als erwartet. Die neuen Tools erzeugten mehr Alarme. Das Team musste die Systeme erst feinabstimmen, konfigurieren und lernen, was in einer Cloud-Umgebung als „normal“ gilt.
Notfallplanung: Unerwartete Neugestaltungen der Cloud-Architektur, Datentransferkosten und Performance-Optimierungen, die eine Umstrukturierung der Anwendungsabfragen erforderten. Das waren echte Kosten – wenig glamouröse Ausgaben, die im Business Case aufgefangen werden mussten.
Doch was sie am meisten überraschte: Die Cloud-Rechnung war höher als im ersten Monat erwartet. Die Datentransferkosten waren beträchtlich. Während der Performance-Optimierung wurden Ressourcen überdimensioniert bereitgestellt. Das Betriebsteam wusste noch nicht, wie Cloud-Kosten zu optimieren sind (ein anderes Paradigma: Man zahlt für Rechenleistung, nicht für Hardware). Es dauerte daher Monate, bis die Konfigurationen tatsächlich Cloud-effizient waren. Genau hier liegt die Lücke zwischen „Wir sind in die Cloud umgezogen“ und „Wir betreiben die Cloud effizient“, die die meisten Unternehmen übersehen.
Die Cloud-Modernisierung von TrustPortal führte zu einer 40–50%igen Senkung der Betriebskosten, das das Ergebnis systematischer, methodischer Arbeit über mehrere Dimensionen hinweg ist.
Woher kamen die Einsparungen? Das typische Muster sieht so aus:
Lizenzierung: Mehrjährige Altverträge liefen aus. Das Unternehmen hat sie nicht verlängert. Kosten eliminiert.
Infrastruktur: Cloud-Hosting für 70 % der Arbeitslast war nach der Optimierung kostengünstiger als die On-Premise-Infrastruktur zuzüglich der Managed-Hosting-Vereinbarung. Nicht so dramatisch wie erhofft, aber spürbar.
Personelle Umstrukturierung: Das Unternehmen hat das Ops-Team nicht entlassen, sondern umstrukturiert. Die Teammitglieder wechselten in die Bereiche Platform Engineering (Aufbau von Infrastructure-as-Code-Pipelines, interne Tools), Site Reliability Engineering (Observability und Incident Response) und andere Rollen mit höherer Hebelwirkung. Gleiche Mitarbeiterzahl, anderer Output. Das schuf Kapazitäten für neue Projekte. Keine „Einsparungen“ im buchhalterischen Sinne, aber eine Wertschöpfung, die es vorher nicht gab.
Betriebliche Effizienz: Automatisierte Deployment-Pipelines, vorhersehbare Skalierung, weniger manuelle Eingriffe. Die Anzahl der Vorfälle ging zurück. Die Zeit, die für die Fehlerbehebung bei der alten Infrastruktur aufgewendet wurde, verringerte sich. Das summiert sich mit der Zeit.
Der Bereich von 40–50 % (statt einer einzelnen Zahl) spiegelt die Realität wider, dass im ersten Jahr einmalige Kosten (Migration, Umschulung, Puffer) anfielen. Ab dem zweiten Jahr ist die Entwicklung vorhersehbarer. Zudem hat das Unternehmen seine Cloud-Nutzung ausgeweitet (neue Funktionen und Plattformkapazitäten), aber das Wachstum hat die Kosten nicht proportional gesteigert. Das liegt daran, dass die Cloud skaliert, die alte Infrastruktur jedoch nicht. Genau dieser Hebeleffekt sorgt für die langfristigen Erfolge.
Kosten sind nicht der einzige Maßstab. Auch der Betrieb hat sich grundlegend verändert.
Vorher: Das Ops-Team arbeitete reaktiv. Deployments waren manuell, skriptbasiert und fehleranfällig. Das Monitoring glich einem Chaos aus Alarmfluten: zu viele Fehlalarme, zu viele Benachrichtigungen für Probleme, die sich von selbst lösten. Skalierung erforderte Hardwarebeschaffung und monatelang im Voraus genehmigte Budgets.
Nachher: Automatisierung steht an erster Stelle. Continuous-Deployment-Pipelines führen containerisierte Anwendungen auf Cloud-Infrastruktur aus. Vorhersehbare Skalierung (die Cloud übernimmt das). Das Monitoring ist anfangs zwar lauter, aber nach der Feinabstimmung tatsächlich intelligent. Auf Vorfälle kann schneller reagiert werden, da das Team nicht ständig zwischen der Fehlerbehebung bei Altsystemen und neuer Arbeit hin- und herwechseln muss.
Die personelle Veränderung: Aus vier klassischen Ops-Ingenieuren wurden zwei Plattform-Ingenieure, zwei Site Reliability Engineers sowie eine flexible Unterstützung durch externe Dienstleister. Die Personalstärke blieb (größtenteils) gleich, doch die Hebelwirkung veränderte sich. Die Plattform-Ingenieure verantworten Infrastructure-as-Code, CI/CD-Pipelines, interne Tools und die Container-Strategie. Die SREs kümmern sich um Observability und Incident Response. Beide Rollen sind hochwirksam und schwer zu ersetzen. Die alten Rollen waren stark auf die Ausführung fokussiert, aber wenig wirkungsvoll.
Der versteckte Gewinn: Durch Automatisierung gewonnene Zeit. Das Plattform-Team konnte nun einen größeren Teil der Anwendungsinfrastruktur übernehmen. Funktionen wurden schneller bereitgestellt und kundenrelevante Vorfälle gingen um 60 % zurück. Dieser Effekt verstärkt sich mit der Zeit.
Die Herausforderung: Cloud-Observability ist anders; die Logs sind verrauschter und Traces komplexer. Das Team musste neue Denkmodelle für das Debugging verteilter Systeme und containerisierter Deployments erlernen. Es gab Monate, in denen sich die Zunahme der Alerts wie ein Rückschritt anfühlte. Das war es jedoch nicht – sie sahen lediglich das, was die alte Infrastruktur zuvor verborgen hatte.
Wenn sie dieses Projekt noch einmal starten würden, gäbe es vier Änderungen:
Ermitteln Sie zuerst Ihre tatsächlichen Legacy-Kosten. Bevor Sie eine Modernisierung rechtfertigen können, müssen Sie wissen, wovon Sie sich verabschieden. Beginnen Sie mit einem Audit: Lizenzen, Infrastruktur, Arbeitsaufwand – alles. Führen Sie dies in einer einzigen Tabelle zusammen.
Starten Sie mit einem schnellen Erfolgserlebnis. Migrieren Sie nicht zuerst Ihren umsatzgenerierenden Kern. TrustPortal ging hier klug vor: Sie begannen mit internen Tools und Kunden-Dashboards, während sie parallel ihre neue Cloud-native Plattform aufbauten. Geringes Risiko. Hoher Lerneffekt. Wäre dieses Pilotprojekt gescheitert, hätten sie zwar Zeit und Geld verloren, aber nicht das Vertrauen ihrer Kunden. Wählen Sie eine isolierte, nicht kritische, aber kostenintensive Workload oder ein System aus. Modernisieren Sie dies zuerst. Lernen Sie daraus und skalieren Sie dann.
Betreiben Sie Legacy- und Cloud-Systeme länger parallel, als Sie für nötig halten. Der psychologische Wert eines Notausgangs rechtfertigt die Kosten. Dieses Sicherheitsnetz ermöglichte es dem Team, schneller zu agieren, da sie keine Angst vor unumkehrbaren Entscheidungen haben mussten. Planen Sie das Budget dafür von Anfang an ein.
Investieren Sie frühzeitig in die Umschulung und Neuausrichtung Ihres Teams. Dies war der schwierigste Teil. Infrastruktur-Teams definieren ihre Identität über das „Am-Laufen-Halten von Systemen“. Cloud-Modernisierung macht diese Identität obsolet. Sie verlangen von ihnen, neue Tools und Paradigmen zu erlernen und zu akzeptieren, dass ihr altes Fachwissen plötzlich weniger wert ist. TrustPortal hat das gut gelöst: Sie haben es als Chance für wirkungsvollere Aufgaben (Plattform-Engineering, SRE, Infrastructure-as-Code) umgedeutet. Nicht jeder war davon überzeugt. Einige gingen. Das ist normal. Aber diejenigen, die blieben, wurden zu Architekten. Investieren Sie also in diesen Übergang. Es zahlt sich aus.
Systematische Cloud-Modernisierung ist sinnvoll, wenn:
Wenn alle vier Punkte auf Sie zutreffen, lohnt es sich wahrscheinlich, eine Modernisierung in Betracht zu ziehen. Wenn nur einer oder zwei zutreffen, rechnen Sie es genau durch, bevor Sie sich festlegen.
Wenn Sie sich hier wiederfinden, fangen Sie klein an.
Erstens: Audit. Erfassen Sie Ihre aktuellen Legacy-Ausgaben. Lizenzen, Infrastruktur, Personal. Jeden Euro. Tragen Sie alles in eine Tabelle ein. Diese Basislinie ist Ihr Kompass.
Zweitens: Identifizieren Sie ein Pilotprojekt. Ein System, eine Arbeitslast, ein Team. Etwas mit klaren Grenzen und messbaren Auswirkungen. Bei dem Fintech-Unternehmen waren es interne Tools und Kunden-Dashboards, die von Dutzenden Mitarbeitern genutzt wurden, nicht umsatzkritisch, aber teuer im Betrieb auf der Legacy-Infrastruktur. Modernisieren Sie das. Messen Sie das Ergebnis. Zeitaufwand, Kosten, Reibungsverluste im Team, unerwartete Probleme. Lassen Sie diese Erkenntnisse in Ihren nächsten Schritt einfließen.
Drittens: Erstellen Sie Ihren Business-Case. „Wir haben X Euro für die Migration ausgegeben, Y Euro an Betriebskosten gespart und Z als Bonus erhalten (schnellere Deployments, weniger Vorfälle, bessere Team-Moral).“ Das überzeugt. Die meisten Unternehmen überspringen diesen Schritt und wundern sich dann, warum die Geschäftsführung die zweite Runde nicht finanziert.
Wenn Sie bereit sind, diesen Prozess zu starten, Imaginary Cloud unterstützt Unternehmen bei der Konzeption und Umsetzung von Modernisierungsstrategien. Wir haben diese Entscheidungen schon oft begleitet. Lassen Sie uns über Ihr Vorhaben sprechen.
Cloud-Modernisierung ist keine Magie, sondern Methodik.
Verschaffen Sie sich einen Überblick über Ihre tatsächlichen Ausgaben. Beginnen Sie mit einem risikoarmen Projekt. Betreiben Sie parallele Systeme länger, als Sie es für nötig halten (die Absicherung ist es wert). Schulen Sie Ihr Team zu Geschäftspartnern um, statt sie als Verwalter veralteter Infrastruktur zu sehen. Messen Sie alles akribisch. Feiern Sie Erfolge und seien Sie offen für unerwartete Kosten – beides wird vorkommen.
Das Fintech-Unternehmen sparte durch systematisches Vorgehen 40–50 %. Das können Sie wahrscheinlich auch. Aber nur, wenn Sie zunächst verstehen, wo genau Sie Einsparungen erzielen können.
Das hängt von Ihrem Workload-Mix und den versteckten Kosten in Ihrer Legacy-Infrastruktur ab. Bei Workloads mit hohen Lizenzkosten (Unternehmensdatenbanken, Middleware, kommerzielle Monitoring-Tools) sind oft über 50 % möglich. Bei Betriebsabläufen mit geringerem Overhead sind es eher 20–30 %. Die meisten mittelständischen Unternehmen haben jedoch versteckte Altsystem-Kosten, die 40 % und mehr realistisch machen, sofern Sie zuvor eine Bestandsaufnahme durchführen.
Wenn die Führungsebene während der Parallelbetriebsphase die Geduld verloren hätte. In dieser Zeit sind die Kosten am höchsten und die Vorteile noch nicht sichtbar. Der CFO des Fintech-Unternehmens musste vier Monate lang konsequent am Plan festhalten. Wäre dieses Engagement geschwankt, hätten sie Abstriche gemacht und die Migration destabilisiert. Organisatorische Disziplin wird oft unterschätzt.
Wahrscheinlich nicht, wenn darüber Umsätze abgewickelt werden. Die regulatorischen Anforderungen sowie der Prüf- und Risikoaufwand sind zu hoch. Ein hybrider Ansatz ist hier die beste Lösung. Modernisieren Sie alles, was diesen Kern umgibt. Lassen Sie den Kern selbst langweilig und stabil.
Der Break-even wurde im 6. Monat erreicht. Operative Verbesserungen (schnellere Deployments, bessere Observability, containerisierte Skalierbarkeit) bemerkte das Team jedoch schon früher, etwa ab dem 8. Monat, als der Parallelbetrieb endete und sie vollständig auf Cloud-Betrieb umstellten.
Nein. Aber die Cloud ist kein magisches Werkzeug zur Kostensenkung. Sie ist ein Hebel. Wenn Sie eine aufgeblähte Legacy-Infrastruktur mit hohen Lizenzgebühren und manuellen Prozessen betreiben, kann die Cloud Ihre Effizienz vervielfachen. Wenn Ihr aktuelles Setup bereits schlank ist, bringt die Cloud möglicherweise keine großen Einsparungen. Die Rechnung muss stimmen.
Falls Sie sich erst einmal über Modernisierung informieren möchten. Die Geschichte von Sedna zeigt einen anderen Ansatz und ein anderes Ergebnis bei der Modernisierung von Altsystemen.
Wenn Sie jedoch bereit sind, von Fallstudien zum Handeln überzugehen, kontaktieren Sie Imaginary Cloud. Wir unterstützen Unternehmen bei der Konzeption und Umsetzung von Modernisierungsstrategien, die auf realen Rahmenbedingungen und echtem ROI basieren.
Echte Infrastrukturen sind komplex. Lassen Sie uns über Ihre sprechen.
Alexandra Mendes ist Senior Growth Specialist bei Imaginary Cloud und verfügt über mehr als 3 Jahre Erfahrung in der Erstellung von Texten über Softwareentwicklung, KI und digitale Transformation. Nach Abschluss eines Frontend-Entwicklungskurses erwarb Alexandra einige praktische Programmierkenntnisse und arbeitet nun eng mit technischen Teams zusammen. Alexandra ist begeistert davon, wie neue Technologien Wirtschaft und Gesellschaft prägen. Sie liebt es, komplexe Themen in klare, hilfreiche Inhalte für Entscheidungsträger umzuwandeln.
People who read this post, also found these interesting:
