Etablierte deutsche Unternehmen brauchen keinen Silicon-Valley-Komplettneubau — sie brauchen eine phasenweise Modernisierung, die das Geschäft am Laufen hält. Wir ersetzen tragende Teile alter Stacks, während der Betrieb live bleibt.
Modernisierungsarbeit beginnt typischerweise mit einem dieser vier Engagements:
Wir passen, wenn:
Nicht passend, wenn Sie auf der grünen Wiese starten, oder die Führung sich bereits auf einen kompletten Rip-and-Replace mit fixem Termin festgelegt hat.
Wir haben genug Migrationen begleitet, um zu wissen, an welchen Stellen Budget verbrennt und der Vorstand das Vertrauen verliert. Diese fünf Muster sehen wir am häufigsten.
Vier Phasen, planbarer Takt, nichts läuft hinter verschlossenen Türen. Sie sehen jede Woche, was sich bewegt — und können jede Phase abbrechen, ohne dass die Produktion betroffen ist.
Wir dokumentieren das Bestehende, identifizieren Domain-Grenzen und benennen die Risiken — bevor wir Code schreiben oder die Geschäftsführung Budget freigibt.
Neue Module wachsen neben dem Altsystem. In der Produktion ändert sich noch nichts — Sie können den Stand jederzeit beurteilen, ohne Risiko für den laufenden Betrieb.
Modul für Modul, Feature-Flag für Feature-Flag, übernimmt das neue System Last. Der Rollback-Pfad bleibt bei jedem Schritt offen — Cut-over ist kein Risiko, sondern ein Schalter.
Sobald die neuen Module 100 % tragen, werden Legacy-Pfade entfernt und Runbooks an Ihr Team übergeben. Wartungsverträge mit uns sind explizit optional.
Das sind keine Logos. Jede Zeile ist eine Modernisierung: was kaputt war, was wir geändert haben, und was am Ende lief.
Digitale Erlebnisse & Marken-SystemeFörderworkflow auf einer brüchigen Legacy-Anwendung — die Arbeit wurde langsamer mit jedem neuen Antragsfeld.
Phasenweiser Ersatz der Bedienoberfläche, während die Datenschicht zunächst unangetastet blieb. Keine Datenmigration vor der UI-Stabilisierung.
Team entlastet, ohne Production-Freeze. Antragsbearbeitung läuft auf der neuen Oberfläche, Backend-Migration ist ein separater, planbarer Schritt.
Digitale Erlebnisse & Marken-SystemePräzisionsmesstechnik mit alterndem Stack — die Messengine darf nicht angefasst werden, das kundenseitige Frontend hingegen blockiert Releases.
Modernisierung der Kundenoberfläche, während die Messengine vollständig erhalten blieb. Klar gezogene Schnittstelle zwischen Mess- und Anwendungsebene.
Schnellerer Release-Takt im Kundenbereich, keine Regression auf der Präzisionsseite. Die Geschäftsbereiche entkoppelt — beide können unabhängig planen.
Enterprise-LösungenEvent-Management-Plattform mit wachsender Mandantenzahl — die alte Architektur konnte neue Kunden nicht ohne Performance-Verlust für Bestandskunden aufnehmen.
Re-Architektur der Mandanten-Boundary, Hot-Paths in einen neuen Service ausgelagert, alter Code blieb für Cold-Paths erhalten — schrittweise Ablösung.
Skalierung auf neue Kunden ohne Re-Plattform-Projekt. Bestandskunden sahen keine Beeinträchtigung, weil der Cut-over feature-flag-gesteuert lief.
Enterprise-LösungenFacility-Management-Software in einem Legacy-Desktop-Flow gefangen — Operatoren konnten nur am Standort arbeiten, mobile Bedienung war nicht möglich.
Web-Bedienoberfläche neben dem Legacy-Kern aufgebaut, Traffic Modul für Modul auf das neue System verlagert, Datenintegrität an jedem Schritt verifiziert.
Operatoren arbeiten auf dem neuen System — kein Production-Freeze während des Cut-over. Legacy-Desktop-Flow ist außer Betrieb, ohne dass ein Tag gefehlt hätte.
Die Entscheidungen, die wir mit Ihrem Team und Ihrer Geschäftsführung diskutieren werden — und die Fragen, die der Vorstand zum Sign-off stellt.
Das neue System wächst neben dem alten. Das alte schrumpft. Beide laufen parallel, bis die Funktionsparität erreicht ist — kein Cut-over auf einen Schlag.
Wann das Aufteilen hilft — und wann es einem 30-Personen-Team nur operative Kosten beschert. Für die meisten Mittelständler ist der modulare Monolith die richtige Antwort.
Dual-Write, ETL oder Change-Data-Capture — jeder Ansatz tauscht Komplexität gegen Sicherheit. Welcher passt, hängt vom Cut-over-Fenster und der Toleranz für Inkonsistenzen ab.
Lift-and-Shift versteckt Kosten- und Latenz-Überraschungen, die erst nach dem Go-Live sichtbar werden. Was vorher refactored werden muss, entscheidet über die TCO der nächsten fünf Jahre.
Wenn Produktionsanlagen und IT-Systeme miteinander reden müssen — ohne dass Release-Zyklen zusammenwachsen. Kein OT-System darf vom IT-Release-Takt abhängen.
Feature-Flags, Traffic-Verlagerung, Rollback-Pfade, Paritäts-Tests — was 'kein Production-Freeze' tatsächlich erfordert. Diese vier sind nicht verhandelbar.
Wenn Ihre Frage hier nicht steht, ist sie fast sicher das Erste, was wir in einem 30-Minuten-Gespräch klären.
Andere Lage? Wir antworten konkret auf Ihre Situation, nicht im Marketing-Sprech.
Direkt anfragen→Ja — das ist die explizite Anforderung, um die wir planen. Strangler-Fig bedeutet, dass das alte System weiterläuft, während das neue daneben wächst. Cut-over erfolgt Modul für Modul über Feature-Flags. Es gibt keinen Big-Bang und keinen Production-Freeze. Wenn ein Schritt schiefgeht, schaltet der Routing-Layer zurück — Sekunden, nicht Stunden.
Vom Architektur-Audit bis zur Außerbetriebnahme der Altsysteme: typischerweise 9–18 Monate, abhängig vom Umfang und davon, wie viele Module parallel migriert werden können. Das Architektur-Audit allein dauert 2–4 Wochen und ist die Grundlage für jede belastbare Zeitschätzung. Vorher zu quoten ist unseriös.
Nein — und das ist der Punkt. Strangler-Fig ersetzt nur die Module, deren Ersatz wirtschaftlich Sinn ergibt. Stabile, funktionierende Kerne (z. B. Messengines, Buchungs-Engines, regulatorisch geprüfte Komponenten) bleiben oft erhalten. Wir empfehlen Komplett-Rewrites praktisch nie — die Risiken sind selten gerechtfertigt.
Die Datenmigration ist ein eigener Workstream, nicht ein Nebenprodukt der Modul-Migration. Wir arbeiten mit Dual-Write oder Change-Data-Capture, je nach Toleranz für Down-Time. Vor jedem Cut-over laufen Paritäts-Tests, die alt und neu auf denselben Eingaben vergleichen. Erst wenn die Parität bestätigt ist, übernimmt das neue System Last.
Im Architektur-Audit identifizieren wir aktiv: statische Code-Analyse, Trace-Logs in Produktion, Interviews mit den Engineers, die das System gebaut haben. Was sich nicht statisch finden lässt, fangen wir mit einem Routing-Layer ab, der zunächst beide Systeme parallel anspricht — versteckte Abhängigkeiten zeigen sich, bevor das alte System abgeschaltet wird.
Wir arbeiten mit ihnen. Unser Job ist, Ihr Team stärker zu machen — nicht abhängig. Wir übergeben Verantwortung schrittweise, dokumentieren explizit für interne Übernahme und schreiben Runbooks, die Ihre Engineers ausführen, nicht wir. Am Ende der Modernisierung läuft das System auf Ihrer On-Call-Rotation, nicht auf einem Wartungsvertrag mit uns.
