Ihr Kernsystem trägt das Tagesgeschäft und ist gleichzeitig der Grund, warum Neues nicht vorankommt. Wir lösen es Modul für Modul ab, im Parallelbetrieb und mit einem Rückfallpfad in jeder Phase. Das Tagesgeschäft läuft weiter.
Selten an einem Ausfall. Meistens daran, dass Vorhaben nicht mehr starten, weil niemand die Auswirkung abschätzen kann.
Beide sind nah an der Pensionierung, und das Wissen steht nirgends. Jede Änderung braucht ihre Zeit und ihr Wohlwollen.
Was fachlich eine kleine Änderung ist, wird technisch zu einem Eingriff mit unklaren Nebenwirkungen. Die Fachabteilung hat aufgehört zu fragen.
Betriebssystem, Datenbank oder Framework erhalten keine Sicherheitsaktualisierungen mehr. Der Prüfbericht weist es aus, und die Frist läuft.
Kein Kundenportal, keine mobile App, keine Datenauswertung: das System hat keine brauchbare Schnittstelle, und jede Integration wird zum Einzelprojekt.
Lizenzen, Spezialisten und Notfalleinsätze summieren sich still. Die Kosten des Nichtstuns tauchen in keinem Projektantrag auf, aber im Budget.
Das System läuft das Tagesgeschäft. Ein Neubau auf der grünen Wiese mit einem Umschalttag ist genau das Risiko, das niemand verantworten will.
Welcher Weg passt, entscheidet die Analyse und nicht der Verkauf. Häufig ist es eine Kombination aus zweien.
Ablösung gewachsener Anwendungen ohne Umschalttag. Wir bringen das Altsystem zunächst unter Testabdeckung, ersetzen dann Modul für Modul und lassen Alt und Neu so lange parallel laufen, bis der letzte Baustein umgezogen ist.
COBOL · .NET · Java EE · Delphi · VB6 · Oracle · SQL Server
Zerlegung nur dort, wo sie sich rechnet. Neue Dienste wachsen um den Monolithen herum und übernehmen schrittweise den Verkehr. Es gibt keinen Stichtag, an dem alles gleichzeitig neu ist.
Kafka · RabbitMQ · Kubernetes · API Gateway · OpenTelemetry
Wenn die Struktur das Problem ist und nicht die Technologie. Wir arbeiten die tragende Architektur heraus, benennen die technischen Schulden mit Aufwand und Risiko und entwerfen ein Zielbild, das schrittweise erreichbar ist.
React · Angular · REST · GraphQL · Domain-Driven Design · CQRS
Der Teil, ohne den Modernisierung Glückssache bleibt. Bevor wir etwas ersetzen, sichern wir das bestehende Verhalten mit Tests ab. Danach ist jede Ablösung überprüfbar statt vermutet.
Playwright · Cypress · JUnit · k6 · SonarQube · OWASP ZAP
Ein Big-Bang-Rewrite verlangt, dass jede fachliche Regel des Altsystems bekannt ist. Bei gewachsenen Systemen ist sie das nie. Deshalb lösen wir modulweise ab. Das Altsystem bleibt so lange die Referenz, bis das neue Modul sie erfüllt.
Wir lesen den Code, sprechen mit den Personen, die das System kennen, und halten die Fachlogik schriftlich fest. Ergebnis ist eine Landkarte mit Risiko und Aufwand je Modul.
Bevor etwas ersetzt wird, halten Charakterisierungstests das heutige Verhalten fest. Erst diese Tests machen jede spätere Ablösung überprüfbar statt vermutet.
Neue Module übernehmen schrittweise Verkehr, während das Altsystem weiterläuft. Jeder Schritt einzeln freigegeben, jeder Schritt einzeln umkehrbar.
Erst wenn der letzte Baustein umgezogen und im Parallelbetrieb bestätigt ist, wird das Altsystem abgeschaltet, mit Dokumentation, Betriebshandbuch und eingearbeitetem Team.
Die Kosten des Nichtstuns stehen in keinem Projektantrag, aber im Budget. Vier Dinge, die sich danach messbar ändern.
Kein Umschalttag, kein Wochenende mit angehaltenem Atem. Der Parallelbetrieb bedeutet: Wenn ein Schritt nicht trägt, gehen Sie einen Schritt zurück und nicht zwölf Monate.
Dokumentierte Architektur und verbreitete Technologien bedeuten, dass Sie am Arbeitsmarkt wieder Entwickler finden und nicht mehr von zwei Personen abhängen.
Klare Modulgrenzen und automatisierte Tests machen Anpassungen wieder kalkulierbar. Die Fachabteilung fängt an, wieder zu fragen.
Auslaufende Lizenzen, Spezialistenzuschläge und Notfalleinsätze fallen weg. Die Ersparnis wird sichtbar, weil die Kosten des Altsystems zuerst erfasst werden.
Die Analysephase steht für sich: Sie erhalten Risiko, Aufwand und Reihenfolge je Modul und können danach entscheiden, ob und mit wem Sie weitermachen.
Analyse besprechenPalisis aus der Schweiz: Frontend-Ablösung modulweise, im Parallelbetrieb, ohne erzwungenen Umstieg für die Nutzer.
Bei Modernisierung ist die Angst nicht das Budget, sondern der Stillstand des Systems, das die Firma betreibt. Deshalb ist jeder Schritt umkehrbar.
Es gibt keinen Stichtag, an dem alles gleichzeitig neu ist. Alt und Neu laufen parallel, der Verkehr wird schrittweise umgeleitet, und jeder Schritt hat einen Rückfallpfad.
Bevor Fachlogik neu gebaut wird, dokumentieren wir sie. Sie erhalten die Dokumentation Ihres Altsystems auch dann, wenn Sie das Projekt nach der Analyse nicht fortführen.
Vollständige Rechteübertragung, Repository bei Ihnen, keine zurückbehaltenen Lizenzen. Für Bestandssysteme gilt dasselbe wie für Neuentwicklung.
Weil modulweise abgelöst wird, ist jede Phase ein abgeschlossener Zustand. Sie sind nie an einem Punkt, an dem nur noch Weitermachen oder Zurückbauen bleibt.
Die Bestandstechnologien, aus denen wir ablösen, und die Zieltechnologien, in die wir überführen. Zielseitig bewusst verbreitet, denn Sie sollen dafür später Entwickler am Markt finden.
Die Punkte, die im Lenkungsausschuss ohnehin kommen, hier vorab beantwortet.
In der Kalkulation ja, in der Praxis selten. Ein Neubau erfordert, dass jede fachliche Regel des Altsystems bekannt ist, und genau das ist bei gewachsenen Systemen nie der Fall. Die modulweise Ablösung deckt unbekannte Regeln auf, während das Altsystem noch als Referenz läuft. Wenn ein Neubau nach der Analyse trotzdem die bessere Wahl ist, sagen wir das.
Ja, das ist die Grundbedingung unseres Vorgehens. Alt und Neu laufen parallel, der Verkehr wird schrittweise umgeleitet und jede Welle hat einen Rückfallplan. Ein Umschalttag, an dem alles gleichzeitig wechselt, ist ausdrücklich nicht Teil des Modells.
Das hängt vom Umfang der Fachlogik ab, nicht von den Codezeilen. Die Analysephase dauert typischerweise 4–6 Wochen und endet mit einer Aufwandsschätzung je Modul. Erst danach nennen wir eine Gesamtdauer, und zwar als Bandbreite. Eine Zahl vor der Analyse wäre geraten, und ein verfehlter Termin schadet mehr als eine vorsichtige Schätzung.
Die Datenmigration wird separat geplant, mit Validierung gegen das Altsystem und dokumentiertem Rückfallpfad. Testdaten werden nach revDSG und DSGVO anonymisiert, bevor sie in Entwicklungsumgebungen gelangen, auch dann, wenn das im Projektauftrag nicht ausdrücklich gefordert ist.
Als Fachexperten, nicht als Zuschauer. Ihre Leute kennen die Regeln, die nirgends stehen. Das ist der wertvollste Beitrag im Projekt. In der Regel arbeiten sie in gemeinsamen Reviews mit und übernehmen anschliessend die Wartung des neuen Systems.
