Written by:
Last Published:
01. September 2026
•
Infrastruktur ist teuer. Ihr Finanzteam weist auf die Quartalsrechnung hin. Sie betrachten den Posten (meist Anbieterlizenzen) und fragen sich: Was wäre, wenn wir einfach alles neu schreiben würden?
Geht es bei einer Fallstudie zur Modernisierung von Altsystemen immer um teure Neuentwicklungen? Nein.
Eine maritime Kommunikationsplattform, Sedna, hat es bewiesen. Mit einem schrittweisen Ansatz, der das Team schlank und das Risiko überschaubar hielt, konnten die Infrastrukturkosten um 80 % gesenkt werden. Keine jahrelange Neuentwicklung. Kein Wegwerfen des Alten und kompletter Neustart. Stattdessen eine gründliche Überarbeitung der Systeme, die am meisten Probleme bereiteten.
Das ist es, was CTOs wirklich hören müssen. Nicht das Standard-Beratungs-Playbook oder „Best Practices“, die aus tausend Unternehmen destilliert wurden. Sie müssen die wahre Geschichte hören: Was hat sich geändert, warum hat es funktioniert und was sollten Sie als Erstes tun?
Lassen Sie uns über den Ansatz von Sedna sprechen, die technischen Entscheidungen, auf die es ankam, und wie Sie Ihre eigene Modernisierung durchführen, ohne das Unternehmen aufs Spiel zu setzen.
Kurz gesagt: Legacy-Modernisierung ist der Prozess der Umgestaltung veralteter Systeme – meist monolithische Strukturen mit technischer Schuld oder plattformabhängige Lösungen –, um Kosten zu senken, die Skalierbarkeit zu verbessern und die technische Autonomie zurückzugewinnen. Es handelt sich nicht um eine komplette Neuentwicklung, sondern um eine strategische Nachrüstung.
Stellen Sie es sich wie die Renovierung eines alten Hauses vor, statt es abzureißen. Sie stärken das Fundament, erneuern die Verkabelung und erhalten die Grundsubstanz. Das Gebäude bleibt während der gesamten Zeit bewohnbar. Sie müssen nicht ausziehen, während der Umbau läuft.
In der Softwareentwicklung bedeutet dies, Systeme, auf die Ihr Team angewiesen ist (und die meist teuer in Wartung und Betrieb sind), schrittweise zu modernisieren. Sie könnten ein kostspieliges Drittanbieter-Tool durch eigenen Code ersetzen oder Workloads von dedizierter Infrastruktur auf Serverless umstellen. Vielleicht geht es auch einfach darum, technische Schulden abzubauen, die sich über fünf Jahre angesammelt haben.
Das ist deshalb so wichtig, weil es sich von dem unterscheidet, was die meisten Unternehmen versuchen. Eine komplette Neuentwicklung setzt voraus, dass Sie Zeit und Budget haben, um alles andere zu stoppen. Ein Lift-and-Shift in die Cloud setzt voraus, dass Ihre Architektur von Haus aus zu AWS passt. Modernisierung ist leiser und iterativ. Sie ermöglicht es Ihnen, den Mehrwert zu beweisen, bevor Sie Milliarden in die nächste Phase investieren.
Sedna entwickelte Produkte für die maritime Kommunikation (Stream und Pulse), die Teams in der Schifffahrt und Lieferkette bei der Koordination unterstützen. (Siehe die vollständige Fallstudie.) Es ging um ein wachsendes Produkt, ein wachsendes Team, wachsende Komplexität... und eine wachsende Rechnung.
Der Knackpunkt war Tray.io, eine Workflow-Integrationsplattform von Drittanbietern, die wichtige Aufgaben übernahm: die Anbindung externer Systeme, die Datenverarbeitung und die Orchestrierung der Geschäftslogik zwischen den Diensten. Doch mit dem Wachstum des Unternehmens stiegen auch die Lizenzkosten. Mehr Workflows bedeuteten höhere Gebühren, mehr Komplexität führte zu aufwendigeren Tray.io-Konfigurationen und einer höheren Wartungslast für das Kern-Entwicklungsteam.
Doch hier liegt die Falle: Die Workflows befanden sich außerhalb der Codebasis. Sie existierten in der Benutzeroberfläche von Tray.io, sodass Entwickler sie weder versionieren, in CI/CD-Pipelines testen noch in Pull Requests überprüfen konnten. Wenn etwas kaputtging, konnte das Ops-Team nicht einfach ein Deployment zurückrollen; stattdessen musste man sich in die Plattform des Anbieters einloggen und direkt in der Produktion Fehler beheben.
Sedna stand also vor der Frage, die sich den meisten wachsenden Unternehmen stellt: Akzeptieren wir die Kosten und machen einfach weiter, oder investieren wir sechs Monate, um das Problem zu lösen?
Sie entschieden sich für Letzteres. Aber sie stürzten sich nicht direkt in eine vollständige Migration. Zuerst wurde optimiert.
Die erste Phase der Modernisierung bei Sedna bestand aus einer strategischen Optimierung – bestehende Tray.io-Workflows wurden gestrafft und unnötige Komplexität wurde vor jeder Neuentwicklung eliminiert. Das hat sich ausgezahlt und das Risiko der Migration minimiert.
Die meisten Unternehmen überspringen diesen Schritt. Sie sehen die Kosten, sehen eine potenzielle Lösung und versuchen sofort den großen Wurf. Sedna nicht. Sie verbrachten vier Wochen damit, ihre Tray.io-Workflows zu prüfen, redundante Schritte zu entfernen, ähnliche Muster zu konsolidieren und das Beste aus der Plattform herauszuholen.
Der Erfolg war unmittelbar. Allein durch die effizientere Nutzung sanken die Lizenzkosten. Das Engineering-Team setzte sich intensiv mit den Workflows auseinander (was existiert, was ist defekt, was ist wirklich wichtig). Und entscheidend war: Sie lieferten einen Proof of Concept. Als die Geschäftsführung die frühen Kosteneinsparungen sah, war das Business Case für Phase 2 offensichtlich.
Dies ist die erste Regel der Modernisierung: Optimieren Sie, bevor Sie migrieren. Es kostet weniger, senkt das Risiko für die nächste Phase und verschafft Ihnen oft genug Spielraum, damit Sie sich beim Umbau der Kernsysteme nicht im Krisenmodus befinden.
Sedna entwickelte eine maßgeschneiderte Lösung auf AWS unter Verwendung von Lambda-Funktionen zur Workflow-Orchestrierung und ersetzte die Tray.io-Plattform durch eigenen Code, der über CI/CD und Terraformbereitgestellt wurde. Das Ergebnis war die vollständige Kontrolle über den Code, Versionierung, Testbarkeit und eine Senkung der Infrastrukturkosten um 80 %.
Die Migration erfolgte sorgfältig. Sedna holte sich Spezialisten (einen Backend-Entwickler und einen Full-Stack-Entwickler von Imaginary Cloud) an die Seite ihres Kernteams, um die Workflows Schritt für Schritt von Tray.io zu AWS Lambda zu migrieren.
Die Architektur sieht wie folgt aus: Jeder Tray.io-Workflow wurde in eine Reihe von Lambda-Funktionen umgewandelt. AWS Step Functions orchestrieren die Pipeline (und verwalten Wiederholungsversuche, Fehlerbehandlung und Zustandsübergänge). Die Funktionen selbst bestehen aus reinem JavaScript, sind in Git gespeichert und werden wie jeder andere Code versioniert und getestet.
Dieser Wechsel brachte drei unmittelbare Vorteile:
- Erstens: Kosten. Ein serverloses Modell bedeutet, dass Sie für die tatsächliche Ausführungszeit bezahlen und nicht für feste Lizenzgebühren.
- Zweitens: Eigenverantwortung. Workflows befinden sich nun direkt in Ihrer Codebasis, sind in Pull Requests überprüfbar und können vor der Bereitstellung getestet werden.
- Drittens: Geschwindigkeit. Wenn das Engineering-Team ein neues Feature veröffentlichen möchte, muss es nicht mehr darauf warten, dass ein von einer operativen Fachkraft entworfener Tray.io-Workflow fertiggestellt wird.
Das Ergebnis war eine Senkung der Ausgaben für Anbieterlizenzen und die zugehörige Infrastruktur um 80 %. Doch noch wichtiger als diese Zahl war, dass das Team seine Autonomie zurückgewonnen hatte.
Kostensenkungen bei der Modernisierung von Altsystemen basieren in der Regel auf drei Hebeln: der Abschaffung teurer Drittanbieter-Tools, der Umstellung von Workloads auf serverlose Wirtschaftsmodelle und der Verlagerung von Engineering-Kapazitäten von der Wartung hin zur Entwicklung neuer Funktionen.
Da das Verständnis dieser Hebel die Grundlage für Ihre eigene Modernisierungsstrategie bildet, schauen wir uns jeden einzelnen genauer an.
Tray.io leistete zwar wichtige Arbeit, war aber auch mit Fixkosten verbunden, die mit zunehmender Komplexität stiegen. Mehr Workflows bedeuteten höhere Kosten. Und mehr Raffinesse bedeutete eine teurere Tarifstufe. Die Plattform wurde zu einer Obergrenze dafür, wie viele Integrationen sich das Unternehmen leisten konnte.
Durch die Migration zu AWS Lambda wechselte Sedna von „Zahlen für Funktionen“ zu „Zahlen für die Ausführung“. Ein Workflow, der 100-mal am Tag läuft, kostet fast nichts. Ein Workflow, der einmal pro Stunde läuft, kostet ebenso wenig. Sie bezahlen für die verbrauchte Rechenleistung, nicht für die Produktstufe eines Anbieters.
Dies ist der erste Hebel: Prüfen Sie, welche Drittanbieter-Tools teuer und proprietär sind und welche kostengünstig und standardisiert. Ihr Identitätsanbieter? Wahrscheinlich den Preis wert. Ihre Workflow-Orchestrierung? Ein Kandidat für eine interne Lösung.
Die Preisgestaltung von Lambda wirkt auf den ersten Blick oft abschreckend. Pro Aufruf fühlt es sich teuer an, doch bei hohem Volumen ist es äußerst großzügig. Wenn Sie tausend Workflow-Ausführungen am Tag haben, kostet Lambda weniger als ein einziger dedizierter Server.
Der entscheidende Punkt ist: Serverless eliminiert die Fixkosten für die Infrastruktur. Sie zahlen nicht für Rechenleistung, egal ob die Workflows laufen oder nicht. An einem Dienstagmorgen, wenn wenig los ist, zahlen Sie fast nichts. An einem Freitagnachmittag, wenn die Integrationen auf Hochtouren laufen, skaliert der Preis mit der Nachfrage.
Für Sedna bedeutete dies eine Umstellung der Kostenstruktur von monatlichen Lizenzgebühren auf nutzungsbasierte Cloud-Kosten. Das Ergebnis? Eine Ersparnis von 80 %.
Hier ist der versteckte Hebel, den Finanzteams oft übersehen. Als die Workflows noch in Tray.io liefen, mussten sie vom Betriebsteam verwaltet, überwacht, bei Fehlern repariert und bei Änderungen an den Integrationen aktualisiert werden.
Mit Lambda liegt all das in der Verantwortung des Kernteams. Da der Code in Git versioniert und testbar ist, ist der Aufwand sogar geringer. Das Engineering-Team wechselte von der „Wartung einer Drittanbieter-Plattform“ zur „Verwaltung einer eigenen Codebasis“. Die Zeit des Teams verlagerte sich von reaktivem Handeln – also dem Beheben defekter Integrationen – hin zu proaktiver Arbeit durch die Bereitstellung neuer Funktionen.
Das Engagement für Sedna umfasste einen Backend-Entwickler und einen Full-Stack-Entwickler für etwa sechs Monate – das sind reale Kosten. Doch der Ertrag war nachhaltig, da das Kernteam dauerhaft entlastet wurde.
Sedna migrierte die Workflow-Orchestrierung von Tray.io zu AWS Lambda unter Verwendung von JavaScript und Kotlin, containerisierte Funktionen für Portabilität und baute CI/CD-Pipelines mit Terraform auf. Der Wechsel von einer Drittanbieter-Plattform zu eigenem Code verschaffte ihnen volle Kontrolle und Skalierbarkeit.
Schauen wir uns an, wie sie das genau umgesetzt haben, denn das technische Muster ist entscheidend.
Tray.io-Workflows waren monolithisch (große Konfigurationen, die mehrere Dinge nacheinander ausführten). Lambda-Workflows sind granular. Jeder Schritt wird zu einer eigenen Funktion.
Stellen Sie sich das so vor: Kundendaten treffen ein. Eine Lambda-Funktion validiert die Daten. Wenn sie gültig sind, lädt eine weitere Funktion sie in die Datenbank. Wenn sie ungültig sind, protokolliert eine dritte Funktion den Fehler und benachrichtigt das Betriebsteam. AWS Step Functions orchestriert diese Pipeline, indem es basierend auf dem Ergebnis der vorherigen Funktion entscheidet, welche Funktion als Nächstes ausgeführt wird.
Warum dieses Muster? Testbarkeit. Jede Funktion ist klein, hat eine klare Aufgabe und kann isoliert per Unit-Test geprüft werden. Ein Entwickler kann npm test lokal ausführen und die Logik vor der Bereitstellung verifizieren. Versuchen Sie das mal mit einem Tray.io-Workflow – da stecken Sie bei der Fehlersuche in der Produktion fest.
Backend: JavaScript auf Lambda. Reines Node.js ohne anbieterabhängige Frameworks. Sollte Sedna jemals von AWS weg migrieren müssen, laufen die Funktionen überall dort, wo Node.js unterstützt wird.
Infrastruktur: AWS Lambda für die Rechenleistung, Step Functions für die Orchestrierung, RDS oder DynamoDB für die Datenhaltung, API Gateway für externe Integrationen.
Deployment: Terraform für Infrastructure-as-Code (reproduzierbar, versionskontrolliert). GitHub Actions für CI/CD. Sobald ein Entwickler ein Workflow-Update pusht, führt die Pipeline Tests aus und stellt bei Erfolg die Anwendung in der Produktionsumgebung bereit.
Monitoring: CloudWatch für Logs, X-Ray für verteiltes Tracing. Wenn ein Workflow fehlschlägt, kann das Ops-Team genau sehen, welche Funktion den Fehler verursacht hat und warum.
Hier sind die Fallstricke, auf die Sedna gestoßen ist und die sie gelöst haben.
Kaltstarts. Lambda-Funktionen benötigen nach einer Leerlaufzeit einen Moment zum Starten. Bei Workflows, die sofort reagieren müssen, ist das relevant. Sedna hat dies durch Provisioned Concurrency auf kritischen Pfaden gelöst. Man zahlt etwas mehr, um Funktionen warmzuhalten. Das lohnt sich bei latenzempfindlichen Integrationen.
Zustandsverwaltung. Workflows sind zustandsbehaftet. Sie müssen wissen, bei welchem Schritt sie sich befinden und welche Daten sie verarbeiten. Lambda ist zustandslos. AWS Step Functions übernimmt dies, indem der Workflow-Status in einer eigenen Datenbank gespeichert wird. Das ist zuverlässig, erfordert aber die Einarbeitung in einen weiteren Dienst.
Fehlerbehandlung. In Tray.io waren Workflow-Fehler oft unbemerkt oder undurchsichtig. In Lambda müssen Sie Retry-Logik, Dead-Letter-Queues und Fehlerbenachrichtigungen explizit definieren. Sedna hat dies in ihre Step-Functions-Vorlage integriert. Jeder Workflow erhält standardmäßig dieselbe Wiederholungsstrategie (drei Versuche, exponentielles Backoff), sofern diese nicht überschrieben wird.
Tests vor der Produktion. Hier glänzt Lambda. Das Team von Sedna schreibt jetzt Tests für Workflows wie für jeden anderen Code auch. Vor einem Deployment durchläuft die gesamte Pipeline Tests mit Staging-Daten. Das ist zwar langsamer als die UI von Tray.io, aber weitaus zuverlässiger.
Bevor Sie davon ausgehen, dass Lambda für alles die richtige Wahl ist, lassen Sie uns über die Grenzen sprechen.
Lang laufende Prozesse. Lambda hat ein 15-minütiges Timeout. Wenn Ihr Workflow nach 15 Minuten noch läuft, benötigen Sie eine andere Architektur (Fargate, Kubernetes, herkömmliche VMs).
Workloads mit hohem Volumen und extrem konstanter Auslastung. Wenn Sie 10 Millionen Ereignisse pro Tag bei absolut vorhersehbarer Last verarbeiten, sind ein dedizierter Server oder ein Kubernetes-Cluster möglicherweise günstiger als Serverless. Die Rechnung ändert sich, sobald Ihre Auslastung so konstant ist, dass Sie ohnehin immer für Ihre Mindestkapazität bezahlen.
Anwendungen mit hohem Statusbedarf. Lambda ist zustandslos. Wenn Ihr Workflow einen komplexen Status über mehrere Schritte hinweg beibehalten muss, verlagern Sie diese Last auf eine Datenbank oder einen externen Speicher. Das funktioniert zwar, erhöht aber die Komplexität.
Sednas Workflows, wie etwa Integrationen zwischen externen Systemen, waren perfekt für Lambda geeignet. Sporadisch, kurzlebig, ereignisgesteuert. Wenn Ihr Profil anders aussieht, sollten Sie den Kostenvergleich genauer unter die Lupe nehmen.
Die meisten Modernisierungsprojekte scheitern an menschlichen Entscheidungen, wie etwa „Rip-and-Replace“-Ansätzen ohne Tests, dem Ignorieren neuer Vendor-Lock-ins, der Unterschätzung der Teamkapazitäten, schleichender Funktionserweiterung (Scope Creep) und fehlenden Erfolgskennzahlen. Phasenweise Vorgehensweisen mit klaren Meilensteinen verhindern all diese fünf Punkte.
Die Versuchung ist groß: „Lass uns das Ganze komplett in [neue Technologie] neu schreiben.“ Es fühlt sich sauberer, schneller und befriedigender an als schrittweises Refactoring.
Sedna lehnte dies ab. Phase 1 (Optimierung) validierte den Business Case und minimierte das Risiko für Phase 2. Als die Geschäftsführung erste Kosteneinsparungen sah, war das Argument für die Migration offensichtlich. Als das Engineering auf Implementierungsprobleme stieß, lagen echte Daten vor, um gegenzusteuern.
Wenn Sie direkt zu einem kompletten Rewrite übergehen, setzen Sie das Unternehmen auf eine Zeitschätzung von Leuten, die genau das noch nie zuvor gemacht haben. Fangen Sie klein an, testen Sie einen einzelnen Workload und beweisen Sie, dass es funktioniert.
Sie sind der Abhängigkeit von Tray.io entkommen, aber jetzt sind Sie von AWS abhängig.
Das ist ein berechtigtes Anliegen, aber es ist handhabbar. Sednas Ansatz: Containerisierung der Funktionen (Docker), Verwendung von Standardbibliotheken (Node.js, keine AWS-SDKs in der Kernlogik) und Vermeidung von AWS-spezifischen Diensten, wo immer möglich. Sollte AWS jemals problematisch werden, können die Funktionen mit minimalen Änderungen auf Google Cloud Run oder Azure Functions ausgeführt werden.
Der Unterschied zwischen gutem und schlechtem Lock-in ist die Portabilität. Gutes Lock-in bedeutet, dass Sie einen Dienst (AWS Lambda) nutzen, den mehrere Anbieter bereitstellen. Schlechtes Lock-in bedeutet, dass Ihre gesamte Geschäftslogik von einer herstellerspezifischen API abhängt, die Sie nirgendwo anders replizieren können.
Ihr Kernteam ist ausgelastet, weil es Funktionen bereitstellt, Fehler behebt und auf Kundenanfragen reagiert. Und jetzt sollen sie auch noch die Infrastruktur modernisieren?
Das funktioniert nicht und führt oft zu halbfertigem Code, verpassten Fristen und einem Kernteam, das zu gestresst ist, um klar zu denken. Sedna hat stattdessen für sechs Monate Spezialisten von Imaginary Cloud hinzugezogen. Sie arbeiteten Seite an Seite mit dem Kernteam, entwickelten die Muster, und anschließend übernahm das Kernteam die Verantwortung.
Wenn Sie dies intern ohne externe Hilfe umsetzen, planen Sie ein entsprechendes Budget ein. Stellen Sie Ingenieure für die Modernisierung ab. Verlangen Sie nicht, dass dies nebenbei erledigt wird.
Sedna blieb fokussiert. Phase 1 optimierte das bestehende Tray.io-Setup. Phase 2 migrierte die Workflows zu Lambda. Das war alles. Erst nach Abschluss beider Phasen wurden neue Funktionen hinzugefügt (Workflow-Versionierung, Unterstützung für alle Teams, Funktion für gesendete Nachrichten).
Jeder neue Punkt im Projektumfang erhöht das Risiko. Halten Sie Ihre Modernisierung fokussiert. Sie können Funktionen und technische Verbesserungen im selben Sprint ausliefern, aber lassen Sie diese nicht miteinander verschmelzen.
Definieren Sie vorab: Was messen Sie? Kosten pro Workflow? Latenz? Fehlerrate? Arbeitsstunden für die Wartung?
Sedna hatte klare Kennzahlen. Kostensenkung (Ziel: 70 %, erreicht: 80 %). Zeit bis zur Bereitstellung eines neuen Workflows (vorher: Engpass im Betrieb, nachher: am selben Tag). Fehlerrate (beibehalten, dann verbessert). Wenn Sie auf diese Zahlen verweisen können, haben Sie den Beleg für die nächste Modernisierungsinitiative.
Beginnen Sie mit einem vierwöchigen Audit: Erfassen Sie alle Altsysteme, identifizieren Sie Kostentreiber sowie technische Schulden und priorisieren Sie nach Auswirkung und Risiko. Testen Sie dann eine einzelne Arbeitslast, um Kosteneinsparungen und technische Machbarkeit nachzuweisen, bevor Sie skalieren.
Wenn Sie es mit der Modernisierung ernst meinen, finden Sie hier den tatsächlichen Fahrplan, den Sedna umgesetzt hat – angepasst an Ihren Kontext.
Tun Sie dies zuerst. Überspringen Sie diesen Schritt nicht.
Listen Sie jedes Altsystem, jedes Drittanbieter-Tool und jede Integration auf, von der Ihr Unternehmen abhängt. Erfassen Sie für jedes Element: jährliche Kosten, aufgewendete Arbeitsstunden für die Wartung und Kritikalität (können wir darauf verzichten? Blockiert es Produktfunktionen?).
Führen Sie dieses Audit abteilungsübergreifend in Technik, Betrieb und Finanzen durch. Sie werden überrascht sein, was Sie finden: alte Verträge, für die noch gezahlt wird, Tools, deren Nutzen niemand mehr kennt, oder Infrastruktur, die dieselbe Arbeitslast doppelt ausführt, weil niemand sie dokumentiert hat.
Ergebnis: Eine priorisierte Liste von Migrationskandidaten. Nutzen Sie diese Matrix: Kostenauswirkung (hoch/mittel/niedrig) vs. technisches Risiko (hoch/mittel/niedrig). Beginnen Sie mit hohen Kosten und geringem Risiko. Vermeiden Sie hohe Kosten bei hohem Risiko, bis Sie bewiesen haben, dass der Ansatz funktioniert.
Ergebnis am Ende von Woche 4: Zustimmung der Geschäftsführung. Sie wissen, was Sie modernisieren und warum.
Während Sie die Migration planen, holen Sie das Maximum aus dem bestehenden System heraus. Entfernen Sie redundante Workflows (wie bei Sedna), refactoren Sie teure Abfragen, aktualisieren Sie veraltete Abhängigkeiten und löschen Sie Code, der seit zwei Jahren nicht mehr angefasst wurde.
Diese Phase ist wenig spektakulär, aber hier erzielen die meisten Unternehmen 20–30 % Kosteneinsparungen ohne jedes Risiko. Zudem beweist sie dem Unternehmen, dass Modernisierung greifbare Ergebnisse liefert.
Ergebnis: Erste Kostensenkungen. Frühe Dynamik. Der Beweis, dass Ihr Team liefern kann.
Planen Sie während der Optimierung die Migration für Ihre Pilot-Workload.
Wählen Sie eine Workload mit hohem ROI, aber geringem Risiko. Bei Sedna war dies die Workflow-Orchestrierung: geschäftskritisch, aber vom Kernprodukt isoliert. Starten Sie den Pilotversuch nicht mit Ihrer Hauptdatenbank oder Ihrer Authentifizierungsebene. Wählen Sie etwas in sich Geschlossenes.
Proof of Concept: Migrieren Sie einen Workflow vollständig. Messen Sie: Kosten, Latenz, Fehlerrate, investierte Teamzeit. Funktioniert der neue Ansatz? Ist er günstiger? Ist er schneller? Dokumentieren Sie das Muster.
Team: Leitender Architekt und Spezialisten (falls Sie externe Hilfe hinzuziehen) sowie ein Kernteammitglied. Die Person aus dem Kernteam lernt das Muster und übernimmt die Verantwortung, sobald die Spezialisten das Projekt verlassen.
Ergebnis: Ein validierter Ansatz. Kostenmodell. Zeitplan für Phase 2. Der Nachweis, dass dies für das eigentliche Projekt funktioniert.
Ergebnis bis Ende Woche 12: Grünes Licht für die Migration aller weiteren Bereiche.
Übertragen Sie das Pilotmuster auf alle Workloads. Gestaffelter Rollout: Shadow (neues System läuft parallel, Ausgabe wird ignoriert), dann Canary (5 % des Traffics auf das neue System, 95 % auf das alte), dann vollständige Umstellung (gesamter Traffic auf das neue System).
Lassen Sie das alte und das neue System zwei Wochen lang parallel laufen. Sollte etwas schiefgehen, ist ein sofortiger Rollback möglich – legen Sie einfach den Schalter um. Dieses Sicherheitsnetz ist die kurzfristige operative Komplexität wert.
Ergebnis: Alle Workloads migriert. Kostenziel erreicht. Keine Produktionsvorfälle.
Modernisierung ist nicht abgeschlossen, wenn alles migriert wurde. Sie ist erst dann beendet, wenn Sie das neue System optimiert und die Vorteile realisiert haben.
Überwachen Sie CloudWatch, Kostenzuordnung und Leistungs-Baselines. Optimieren Sie: reservierte Kapazitäten für vorhersehbare Workloads, architektonische Anpassungen basierend auf Produktionsmustern sowie Funktionsanfragen, die nun umsetzbar sind (Sedna hat hier Workflow-Versionierung und neue Nachrichtenunterstützung hinzugefügt).
Dokumentieren Sie, was funktioniert hat, was nicht und welche Muster für die nächste Modernisierung hilfreich sind.
Woche 4: Go/No-Go-Entscheidung basierend auf dem Audit. Rechtfertigt die Kosteneinsparung den Aufwand? Zieht das Team an einem Strang?
Woche 12: Go/No-Go-Entscheidung basierend auf den Pilot-Ergebnissen. Hat der neue Ansatz funktioniert? Ist er kostengünstiger? Hat das Team Vertrauen in die Lösung?
Falls eine Antwort „Nein“ lautet, sind Sie nicht gescheitert. Sie haben dazugelernt. Passen Sie den Plan an und versuchen Sie es erneut. Sedna hätte feststellen können, dass der Pilot nicht funktioniert, und den Ansatz ändern können. Da er jedoch erfolgreich war, war Phase 2 der logische nächste Schritt.
Das hängt vom Umfang ab. Sednas zweiphasiger Ansatz dauerte etwa sechs Monate (Optimierung + Migration). Ein größeres System könnte 12 bis 18 Monate in Anspruch nehmen. Entscheidend ist nicht die Geschwindigkeit, sondern die Wertschöpfung in jeder Phase, anstatt eines „Big Bang“-Rewrite, das zwei Jahre dauert und ohne Puffer endet.
Phasenweises Vorgehen bedeutet, dass jede Phase die nächste finanziert. Die Optimierung in Phase 1 kann die Migration in Phase 2 finanzieren. Die Migration in Phase 2 verschafft dem Team Zeit, Funktionen für Phase 3 bereitzustellen. Sie setzen nicht vorab Milliarden ein, sondern investieren schrittweise.
Sie betreiben das neue System parallel zum alten, bis Sie sich sicher sind. Sollte die Produktion ausfallen, schalten Sie sofort auf das alte System zurück. Sie haben nichts gelöscht. Sedna ließ Tray.io während der Lambda-Migration zwei Wochen lang als Sicherheitsnetz weiterlaufen.
Parallelbetrieb ist operativ aufwendiger (Sie betreiben beide Systeme, überwachen beide und debuggen möglicherweise beide). Aber es ist die Versicherungspolice, die das Management ruhig schlafen lässt. Das ist es wert.
Modellieren Sie den ROI frühzeitig. Die Optimierung in Phase 1 finanziert oft Phase 2. Zeigen Sie der Geschäftsführung: aktuelle jährliche Lizenzkosten, prognostizierte Einsparungen, Amortisationszeit und sekundäre Vorteile (schnellere Bereitstellung von Funktionen, geringerer Betriebsaufwand). Sednas Kostensenkung um 80 % machte den Business Case offensichtlich – Amortisation in drei Monaten, danach jahrelanger Gewinn.
Wenn Sie den ROI nicht nachweisen können, ist die Modernisierung nicht dringend genug. Setzen Sie sie auf die Roadmap, optimieren Sie dort, wo es kostengünstig möglich ist, und prüfen Sie das Vorhaben im nächsten Quartal erneut.
Das hängt von der Expertise Ihres Teams ab. Wenn Ihr Team über fundierte Serverless- und AWS-Kenntnisse verfügt, ist eine interne Lösung schneller und kostengünstiger. Falls nicht, minimiert externe Unterstützung das Zeitrisiko und beschleunigt den Lernprozess.
Das Managed-Teams- Modell, das Sedna genutzt hat (Spezialisten, die für einen definierten Zeitraum in das Kernteam integriert werden), ist ein guter Mittelweg. Sie profitieren von hoher Umsetzungsgeschwindigkeit, Wissenstransfer und nachhaltigem Kompetenzaufbau in Ihrem Team. Was die Personalkosten angeht, ist dies oft günstiger, als für ein sechsmonatiges Projekt Vollzeit-Ingenieure einzustellen.
Ein hybrider Ansatz ist völlig in Ordnung. Migrieren Sie die kostenintensivsten und problematischsten Workloads auf Serverless; behalten Sie stabile Workloads mit hohem Volumen auf einer Infrastruktur, die bereits für diese Last optimiert ist. Vermeiden Sie ein Alles-oder-Nichts-Denken.
Ein bewährtes Muster: Migrieren Sie Integrationen und Hintergrundprozesse auf Lambda (dafür ist Serverless hervorragend geeignet), während Sie Datenbanken und Kerndienste auf verwalteter Infrastruktur belassen. So erzielen Sie Kosteneinsparungen und Leistungssteigerungen, ohne das Risiko einer kompletten Architektur-Neuentwicklung einzugehen.
Containerisieren Sie Ihre Funktionen (Docker-Container sind portabel). Nutzen Sie verwaltete Datenbanken mit Standard-APIs (statt Aurora-spezifischer Funktionen). Vermeiden Sie AWS-spezifische Frameworks in Ihrer Kern-Businesslogik.
Die Lambda-Funktionen von Sedna basieren auf reinem JavaScript unter Verwendung von Standard-Node.js-Bibliotheken. Die AWS-SDK-Aufrufe sind im Infrastruktur-Code isoliert. Sollte sich das Unternehmen jemals für einen Wechsel zu Google Cloud entscheiden, laufen die Funktionen mit minimalen Anpassungen auf Cloud Run. Der Infrastruktur-Code müsste zwar neu geschrieben werden, aber die eigentliche Logik bleibt portabel.
Legacy-Modernisierung ist keine binäre Entscheidung zwischen „alles neu schreiben“ oder „hohe Kosten akzeptieren“. Es ist eine strategische Nachrüstung.
Die Kostensenkung von 80 % bei Sedna basierte auf drei Faktoren: Beseitigung der Abhängigkeit von Drittanbietern (Wegfall der Tray.io-Lizenzgebühren), Umstellung auf Serverless-Ökonomie (Bezahlung nach Ausführung statt fester Kapazitäten) und die Befreiung des Teams für die Bereitstellung neuer Funktionen (Workflows sind jetzt als Code abgebildet, testbar und schnell bereitstellbar).
Die Lektion für CTOs: Beginnen Sie dort, wo es am meisten schmerzt: Kosten, Geschwindigkeit, Zuverlässigkeit. Optimieren Sie zuerst, um Risiken zu minimieren und Schwung zu holen. Migrieren Sie dann. Und optimieren Sie anschließend erneut. Jede Phase rechtfertigt die nächste.
Die meisten von Ihnen zahlen zu viel für Legacy-Systeme, die zu langsam für Veränderungen sind. Wenn das auf Sie zutrifft, ist dies Ihr Startschuss für die Modernisierung. Führen Sie ein Audit durch. Wählen Sie ein Pilotprojekt. Beweisen Sie, dass es funktioniert. Und dann: skalieren Sie.
Die 80-prozentige Senkung, die Sedna erreicht hat, ist keine Magie. Es ist Disziplin: ein phasenweiser Ansatz, ein klarer ROI, Unterstützung für das Team und der Mut zu handeln, wenn der Business Case solide ist.
Sie sind dran.
Bereit, Ihre Altsysteme zu modernisieren? Kontaktieren Sie Imaginary Cloud, um Ihren Modernisierungsfahrplan zu besprechen. Wir helfen Ihnen dabei, nachhaltige Kostensenkungen und technische Autonomie zu erreichen.
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.
Inês Silva ist Projektmanagerin mit über vier Jahren Erfahrung im Schreiben über Softwarebereitstellung, agile Methoden und Tech-Leadership. Da sie ihre Karriere als Entwicklerin begann, bringt Inês ein fundiertes, tiefgreifendes technisches Verständnis in das Management ein. Sie liebt es, die Lücke zwischen der übergeordneten Geschäftsstrategie und der täglichen technischen Umsetzung zu schließen, und gibt leidenschaftlich gerne praktische Tipps weiter, die Teams dabei helfen, besser zusammenzuarbeiten und erstklassige Produkte zu entwickeln.
People who read this post, also found these interesting:
-%2520Survey%2520Insights.webp)
