Legacy-Software-Modernisierung
Legacy-Modernisierung als Engineering-Service
Vollständige Modernisierung, kein Code-Review-Bericht
Wir übernehmen ein Altsystem, das niemand mehr anfassen will, und bringen es in einen Zustand, in dem Ihre Entwickler wieder gerne arbeiten. Das umfasst Datenbank, Backend, Integrationen und Deployment-Pfad. Ergebnis: ein typisierter, getesteter, beobachtbarer Stack — kein dicker Empfehlungsbericht, der im Ordner verschwindet.
Datenbankneubau vor jedem Rewrite
Die meisten Legacy-Schmerzen sind datenförmig: Tabellen, die jahrelang seitwärts gewachsen sind, fehlende Indizes, Queries, die alles scannen. Wir analysieren zuerst die Zugriffsmuster, entwerfen das Zielschema und migrieren mit Dual-Write, sodass das alte System live bleibt, bis das neue schneller und korrekt ist.
Backend-Rewrite in Scheiben
Ein vollständiger Backend-Rewrite läuft modulweise, nicht als grosser Umstellungstag. Wir schneiden den Monolithen entlang der Domänennähte, ziehen den neuen Service in TypeScript oder Node mit strikten Typen und Contract-Tests hoch und leiten Traffic über Feature-Flags um. Kill-Switch auf jedem Pfad, in Sekunden zurück.
API- und Integrationsschicht neu aufgesetzt
Altsysteme verstecken Schnittstellen in Stored Procedures, CSV-Exporten und Batch-Jobs. Wir ersetzen sie durch eine dokumentierte REST- oder GraphQL-Oberfläche, typisierte Client-SDKs und Event-Hooks für die nachgelagerten Systeme. Partnerintegrationen sind kein Quartalsprojekt mehr.
Infrastructure-as-Code und sauberes CI/CD
Wir kodifizieren die Zielumgebung in Terraform, vereinen Deployments hinter einer CI/CD-Pipeline und ergänzen Observability, die wirklich auslöst: Logs, Traces, Error-Budgets, Uptime-Dashboards. Das System läuft auf AWS, Hetzner oder On-Premises — keine Snowflake-Server mehr.
Chirurgisches Refactoring statt Komplettneubau
Nicht jedes Altsystem braucht einen Neubau. Wenn die Architektur trägt, sich aber technische Schulden gestapelt haben, fahren wir ein gezieltes Refactoring: schlimmste Module raus, Tests ergänzen, Frameworks zwei Majors hoch. Sechs bis zwölf fokussierte Wochen statt eines Jahresprogramms.
Wissenstransfer und Run-Mode
Das modernisierte System wird mit Architekturdokumenten, Runbooks, On-Call-Playbooks und einer funktionierenden Testsuite übergeben. Ihr Team übernimmt; wir bleiben das erste Quartal auf einem leichten Support-Engagement, halten Regressionen draussen und beantworten die Fragen, die während der Lieferung niemand gestellt hat.
Unser Vorgehen bei Legacy-Modernisierung
System-Audit und Risikokarte
Wir lesen den Code, profilieren die Datenbank, beobachten echten Traffic und sprechen mit den Engineers, die den Pager tragen. Ergebnis: eine Risikokarte — was ist fragil, was trägt Last, was kann weg, welche Scheibe wird zuerst gebaut.
Zielarchitektur und Datenmodell
Vor jedem Rewrite legen wir die Zielform fest: Datenmodell, Service-Nähte, Verträge zwischen Modulen und Deployment-Topologie. Strikte Typen und klare Verantwortung ersetzen, was das Altsystem aus Versehen durchgesetzt hat.
Datenbankmigration mit Dual-Write
Die Datenbank wird parallel aufgebaut und über ein Dual-Write-Fenster synchron gehalten. Das alte System bedient weiter die Produktion, das neue Schema bewährt sich unter realer Last. Cutover erst, wenn der Abgleich mehrere Tage stimmt.
Strangler-Fig-Rewrite des Backends
Neue Module gehen hinter einer Routing-Schicht live, die pro Request zwischen alt und neu wählt. Traffic wandert scheibenweise hinüber, hinter Feature-Flags mit Kill-Switch. Altcode wird in einem Commit entfernt, wenn der letzte Aufrufer weg ist.
Test-Harness und Observability
Bevor ein Modul stillgelegt wird, bekommt es Contract-Tests, Integrationstests und strukturierte Logs. Fehler erhalten Budgets, Latenzen SLOs, Dashboards zeigen Regressionen am selben Tag. Beobachtbar by design, nicht nach dem ersten Ausfall.
Übergabe und Post-Launch-Support
Wir übergeben Architekturdokumente, Runbooks und einen Leitfaden für die On-Call-Rotation. Im ersten Quartal fahren wir auf leichtem Support mit, fangen Regressionen ab und schliessen die Lücke zwischen Launch und Regelbetrieb.
Wir lesen den Code, profilieren die Datenbank, beobachten echten Traffic und sprechen mit den Engineers, die den Pager tragen. Ergebnis: eine Risikokarte — was ist fragil, was trägt Last, was kann weg, welche Scheibe wird zuerst gebaut.
Vor jedem Rewrite legen wir die Zielform fest: Datenmodell, Service-Nähte, Verträge zwischen Modulen und Deployment-Topologie. Strikte Typen und klare Verantwortung ersetzen, was das Altsystem aus Versehen durchgesetzt hat.
Die Datenbank wird parallel aufgebaut und über ein Dual-Write-Fenster synchron gehalten. Das alte System bedient weiter die Produktion, das neue Schema bewährt sich unter realer Last. Cutover erst, wenn der Abgleich mehrere Tage stimmt.
Neue Module gehen hinter einer Routing-Schicht live, die pro Request zwischen alt und neu wählt. Traffic wandert scheibenweise hinüber, hinter Feature-Flags mit Kill-Switch. Altcode wird in einem Commit entfernt, wenn der letzte Aufrufer weg ist.
Bevor ein Modul stillgelegt wird, bekommt es Contract-Tests, Integrationstests und strukturierte Logs. Fehler erhalten Budgets, Latenzen SLOs, Dashboards zeigen Regressionen am selben Tag. Beobachtbar by design, nicht nach dem ersten Ausfall.
Wir übergeben Architekturdokumente, Runbooks und einen Leitfaden für die On-Call-Rotation. Im ersten Quartal fahren wir auf leichtem Support mit, fangen Regressionen ab und schliessen die Lücke zwischen Launch und Regelbetrieb.
Diese Modernisierungs-Engine, kein generischer Rewrite
Wir bauen scheibenweise, nicht im Big-Bang
Modernisierung scheitert, wenn Teams einen Big-Bang-Rewrite versuchen, während das alte System noch Umsatz bringt. Wir zerlegen die Plattform in Module, bauen Scheibe für Scheibe hinter Strangler-Fig-Routing neu und stilllegen Altcode erst, wenn der neue Pfad Wochen lang echten Traffic getragen hat.
Datenarchitektur zuerst, Framework danach
Die meisten Altsysteme sind langsam, weil das Datenmodell verrottet ist, nicht das Framework. Wir starten bei der Datenbank — Zugriffsmuster, Indizes, denormalisierte Blobs — und entwerfen ein Zielschema, das die Queries beantwortet, die das Geschäft wirklich fährt. Die Framework-Wahl wird einfach, sobald die Datenform stimmt.
Strikte Typen und Contract-Tests statt Hoffnung
Strikte Typen im neuen Backend, Contract-Tests an jeder Service-Grenze, Integrationstests auf Pfaden, die Geld oder Daten bewegen. Das Altsystem lebte von Stammeswissen; das modernisierte lebt von Tests. Ein neuer Engineer kann ab Tag drei Code ändern, ohne nachgelagerte Systeme zu zerlegen.
Observability vor Stilllegung
Bevor ein Legacy-Modul stillgelegt wird, ist die Ablösung mit strukturierten Logs, Traces, Error-Budgets und Uptime-SLOs verdrahtet. Regressionen tauchen in Stunden auf, nicht Wochen später durch eine Kundenbeschwerde. Modernisierung, die dunkel live geht, ist neue Schuld mit anderem Namen.
Ehrlicher Scope, ehrlicher Zeitplan
Manche Plattformen brauchen einen vollständigen Rewrite. Viele brauchen ein fokussiertes Refactoring: die zwei schlimmsten Module raus, fehlende Tests ergänzen, Frameworks zwei Majors hoch, Schluss. Wir sagen das vorab und schätzen in Wochen und Scheiben, nicht in vagen Phasen. Billigste Modernisierung ist die, die man nicht zweimal macht.
Häufig gestellte Fragen
Modernisierung baut ein System neu, das noch Umsatz bringt, aber neue Arbeit blockiert: langsame Seiten, fragile Deploys, keine Tests. Sie brauchen sie, wenn ein Feature Wochen dauert. Rechnen Sie mit 8–26 Wochen für einen Rewrite, 4–12 Wochen für chirurgisches Refactoring.
Trägt das Datenmodell und sind nur einzelne Module verrottet: Refactoring. Ist die Datenbank denormalisiert, laufen Integrationen über Batch-CSVs und fehlen Tests: Rewrite. Wir liefern in 2–3 Wochen ein schriftliches Audit mit klarer Empfehlung, bevor gebaut wird.
Strangler-Fig: Eine Routing-Schicht vor der Altplattform schickt eine Verkehrsscheibe ans neue Modul, der Rest läuft weiter auf Legacy. Jede Scheibe geht hinter Feature-Flag mit Kill-Switch live — unter einer Minute zurück, falls etwas stolpert.
Beides, und die Datenbank zuerst. Zielschema entwerfen, mit Dual-Write migrieren, sodass alt und neu synchron bleiben, und erst umschalten, wenn der Abgleich mehrere Tage stimmt. Query-Latenz fällt typischerweise von 10+ Sekunden auf unter eine Sekunde.
Standardziel: TypeScript auf Node mit Nest, PostgreSQL oder die bestehende relationale Engine, GraphQL oder REST, Redis für Queues und Caches, Terraform-verwaltetes AWS oder On-Premises. Der Zielstack passt zu Ihrem Hiring-Markt, nicht zu einer Buzzword-Liste.
Vollständiger Backend-Rewrite mittelgrosser Plattformen: 8–26 Wochen, je nach Scheibenzahl und Integrationsfläche. Chirurgisches Refactoring der zwei oder drei schlimmsten Module: 4–12 Wochen. Reines Audit mit Empfehlung: 2–3 Wochen.
Es läuft weiter. Strangler-Fig-Routing verteilt Traffic zwischen alt und modernisiert. Sobald jeder Aufrufer auf neuem Code liegt, wird das alte Modul in einem Commit entfernt. Die Legacy-DB bleibt ein Quartal als kalte Read-Replica für Audit und Rollback.
Nein. Geliefert werden Architekturdokumente, Runbooks, On-Call-Playbooks und eine Testsuite. Ihr Team besitzt den Stack; wir bleiben 12 Wochen auf leichtem Support und ziehen uns zurück. Etwa die Hälfte unserer Kunden bleibt für Feature-Arbeit, die andere übernimmt komplett.
Über SAPIENTROQ
Sind Sie an einer Lösung interessiert?
Wir freuen uns, Ihnen die Möglichkeiten unverbindlich aufzuzeigen.
Roland Kurmann
CEO, SAPIENTROQ
