Legacy-Modernisierung

Legacy-Modernisierung, bei der dein Geschäft weiterläuft.

Dein System trägt das Geschäft noch, aber jede Änderung wird langsamer und riskanter. Wir prüfen, was da ist, wählen die Teile aus, die sich zu ersetzen lohnen, und stellen sie Stück für Stück um. Datenmigration und Rollback stehen fest, bevor irgendetwas umgeschaltet wird.

Modernisierung abgrenzen →

KURZ ERKLÄRT

Legacy-Modernisierung verändert Architektur, Laufzeit oder Plattform eines Systems, das du bereits besitzt und betreibst, schrittweise und im laufenden Betrieb. Der Auftrag umfasst ein Assessment, eine vereinbarte Reihenfolge von Ersetzungen oder Upgrades, Datenmigration und geprüfte Umstellungen.

Passt für

Ein funktionierendes System, dessen Framework, Laufzeit oder Architektur Änderungen inzwischen ausbremst
Teams, die einen schrittweisen Plan statt eines Komplett-Neubaus brauchen

Eine andere Leistung passt besser

Ein Anbieterwechsel, bei dem zuerst Zugänge und Wissen übernommen werden müssen
COBOL, Mainframe, SAP-Anpassungen oder spezielle Embedded-Firmware

Dein eigenes System modernisieren, nicht die Übergabe eines anderen

Diese Seite gilt für ein System, das du bereits besitzt und betreibst, gebaut von deinem Team oder einem Anbieter, mit dem du weiter arbeitest. Ist der bisherige Anbieter weg und hat niemand mehr Zugänge oder Wissen, starte mit der Software-Übernahme. Deren Legacy-Bewertung und das begrenzte Dependency-Upgrade bleiben dort, mit ihren bestehenden Bedingungen. Server oder Cloud-Accounts umziehen, ohne die Anwendung zu ändern, ist Cloud-Migration. Laufende Updates und Fehlerbehebung an einem stabilen System sind Software-Wartung.

Die Änderung aus dem Befund ableiten

Alter allein rechtfertigt keinen Neubau. Das Assessment vergleicht Optionen je Komponente: Kosten, Risiko und was das Geschäft während der Umstellung weiter leisten muss.

Schrittweise Ablösung

Eine Fähigkeit nach der anderen hinter einer stabilen Schnittstelle neu umsetzen (Strangler-Pattern). Der alte Weg bleibt verfügbar, bis sich der neue bewährt hat.

Framework- und Laufzeit-Upgrades

Auf unterstützte Versionen von Sprache, Framework und Bibliotheken wechseln. Große Versionssprünge werden zu einer Folge kleinerer, getesteter Schritte.

Re-Platforming

Die Anwendung mit möglichst wenig Codeänderung auf eine andere Laufzeit oder Hosting-Form bringen, zum Beispiel in Container. Ein reiner Infrastruktur-Umzug wird als Cloud-Migration abgegrenzt.

Datenmigration

Altes und neues Schema abbilden, Datensätze umwandeln und abgleichen, und die Migration an einer Kopie proben, bevor sie wirklich läuft.

Das Geschäft läuft weiter, während Teile wechseln

Beginne mit dem Teil, der am meisten blockiert und am wenigsten verflochten ist. Jede Etappe braucht das Verhalten, das gleich bleiben muss, Tests oder aufgezeichnete Referenzergebnisse, die es prüfen, einen Schalter (Feature-Flag, Routing-Regel oder Release), einen Rollback-Weg und eine benannte Person, die die Umstellung freigibt. Eine frühere Anwendungsversion macht Änderungen in Datenbank oder Fremdsystemen nicht unbedingt rückgängig. Datenschritte planen wir deshalb getrennt von Codeschritten. Ob eine Plattform passt, klärt das Assessment.

Illustrative Abnahme: alter und neuer Weg liefern dasselbe Ergebnis

Für eine vereinbarte Fähigkeit läuft ein aufgezeichneter Satz realistischer, nicht vertraulicher Anfragen gegen die alte und die neue Umsetzung. Jede Abweichung wird gelistet und dann erklärt oder behoben. Eine Probemigration an einer Kopie hält Zeilenzahlen, Prüfsummen ausgewählter Felder, abgelehnte Datensätze und Dauer fest. Danach läuft die Umstellung mit geprobtem Rollback. Das illustriert einen Abnahmetest, kein Kundenresultat und keine Garantie, dass jeder Sonderfall abgedeckt ist.

Prüfen, in Etappen liefern, übergeben

Umfang und Angebot vereinbaren wir je Phase vor Beginn. Du kannst mit dem Assessment selbst weiterarbeiten oder die vereinbarten Etappen beauftragen.

Assessment
Du erhältst eine Komponentenübersicht, ein Versions- und Abhängigkeitsinventar, bestätigte Risiken und einen Etappenplan mit Optionen je Komponente.
Umsetzung in Etappen
Jede Etappe wird vor Beginn angeboten, als unterschriebener Festumfang oder im Rahmen eines monatlichen Retainers, und mit Prüfungen und Rollback ausgeliefert.
Übergabe
Du erhältst aktualisierte Dokumentation, Runbooks, entfernte Altpfade und eine klare Liste dessen, was dein Team jetzt betreibt.

Zugänge, kritische Abläufe und die Leute mitbringen, die die Regeln kennen

Wir brauchen Repository- und Infrastrukturzugang, die geschäftskritischen Abläufe, bekannte Vorfälle, die aktuelle Versionsliste, Datenmengen und die Personen, die wissen, warum sich das System so verhält. Lesezugriff und Produktionsänderungen sind getrennte Berechtigungen. Zum Hintergrund: wie wir Architektur sanieren, ohne neu zu schreiben, und ein durchgespieltes Beispiel für die Entscheidung Upgrade oder Migration bei altem PHP.

// beweise

Modernisierung in bestehender Engineering-Arbeit

Hyperstate AI dokumentiert die Aufteilung eines GPU-lastigen Monolithen in getrennte Services und den Wechsel von manuellen Deployments zu containerisierter, orchestrierter Infrastruktur bei gleicher Produktoberfläche. Polity dokumentiert die Migration von Frontend- und Tooling-Stack und die Zusammenführung von Legacy-CI über mehrere Services, während weiter Features ausgeliefert wurden. MyMerch zeigt die Gegenentscheidung: ein funktionierendes System, gezielt verbessert, ohne Neubau. Keiner dieser Fälle ist eine Mainframe- oder ERP-Ablösung, und keiner verspricht dasselbe Ergebnis für ein anderes System.

GPU-Monolith → Microservices

GPU-lastigen Monolithen in orchestrierte Services zerlegt und selbst gehostete ML-Bibliotheken durch skalierbare Alternativen …

Python Django OpenAI API

7 Services Vereinheitlichtes Testen

1,5 Jahre QA-Eigentümerschaft über sieben Services und mehrere Vendoren. Qualität blieb durch jeden Refactor lieferbar.

React Java/Kotlin Go

~50% Effizienzgewinn für das MyMerch-Team

Das MyMerch-Team beziffert den Effizienzgewinn auf ~50%. Weniger Auslieferungsfehler, höhere Shopify-Conversion, ohne Rewrite.

Shopify Shopify Liquid JavaScript

Das sind ausgewählte Projekte, nicht unser gesamtes Portfolio. Seit 2018 haben wir 100+ Produkte ausgeliefert.

Fragen vor dem Start

Müssen wir das ganze System neu schreiben?

Meistens nicht. Die meisten Systeme haben Teile, die es wert sind, erhalten zu bleiben. Das Assessment zeigt, welche Komponenten ein Upgrade bekommen, welche ersetzt werden und welche bleiben. Einen Komplett-Neubau empfehlen wir nur, wenn die Zahlen ihn tragen.

Was ist der Unterschied zur Software-Übernahme?

Eine Übernahme verlagert die Verantwortung von einem Anbieter zum nächsten: Zugänge, Dokumentation und sichere Releases kommen zuerst. Modernisierung verändert die Form eines Systems, das du bereits kontrollierst. Brauchst du beides, kommt die Übernahme zuerst, denn was niemand bauen und ausliefern kann, lässt sich nicht sicher umbauen.

Läuft das System während der Modernisierung weiter?

Das ist der Standardplan. Jede Etappe wird mit Rollback-Weg umgeschaltet. Braucht ein Datenschritt ein Wartungsfenster, vereinbaren wir es vorab mit den Betroffenen.

Welche Stacks modernisiert ihr?

Web-, Mobile- und Cloud-native Systeme, typischerweise PHP-, Python-, Node.js- und .NET-Backends mit Web- oder Mobile-Frontends. Ob eine konkrete Plattform passt, klärt das Assessment. COBOL, Mainframe, SAP-Anpassungen und spezielle Embedded-Firmware sind nicht unser Handwerk.

Was kostet eine Modernisierung?

Das Assessment hat einen festen Umfang, bepreist nach einem kurzen Kennenlerngespräch. Jede Etappe wird aus dem Befund angeboten. Eine Zahl, bevor jemand den Code gelesen hat, ist geraten.

Modernisierung abgrenzen

Beschreibe das System, den Stack und was Änderungen heute blockiert. Für das erste Gespräch reicht ein kurzer Überblick ohne vertrauliche Details.