Was ist die XITASO Software-Modernisierungssuite?

Eine Reihe KI-gestützter Komponenten, die XITASO-Software-Engineers einsetzen, um geschäftskritische Legacy-Software zu modernisieren. Sie verbindet menschengeführtes Requirements- und Geschäftsprozess-Engineering mit KI-Beschleunigung innerhalb eines technischen Harness, das Korrektheit, Architekturkonformität und Verifizierbarkeit sicherstellt.

Für welche Unternehmen ist die Suite gedacht?

Für Unternehmen mit geschäftskritischen Systemen in veralteten oder eingestellten Technologien (z.B. .NET Framework, AngularJS, WinForms, Legacy-SPS-Systeme), insbesondere dort, wo Dokumentation dünn ist und Schlüsselexperten kurz vor der Rente stehen.

Wie verhindert die Suite technische Schulden 2.0?

Durch zwei Mechanismen: ein Harness aus Architekturregeln, Fitness Functions/CI-Gates, statischer Analyse und KI-generierten Charakterisierungs- und Differenztests, innerhalb dessen die KI arbeitet; sowie KI-gebaute, deterministische Tools für datenbasierte Entscheidungen. So bleibt KI-Geschwindigkeit korrekt und architekturkonform.

Wie viel schneller macht KI die Modernisierung?

Auf realen Kundenprojekten wurden für mechanische, gut abgegrenzte Aufgaben (Reverse Engineering, Migration, Testerstellung, Security-Triage) Beschleunigungen von 5–15× gemessen. Urteilslastige Arbeit wie Architekturentscheidungen wird nicht gleichermaßen beschleunigt; das Assessment misst, wie viel Ihres Codes in die beschleunigbare Kategorie fällt.

Funktioniert die Requirements-Analyse auch ohne Zugang zum Quellcode?

Ja. Wo der Zugang zum Quellcode eingeschränkt ist, kann die Requirements- und Prozessrekonstruktion dennoch durchgeführt werden – ein Ansatz, den XITASO in einem peer-reviewten Paper dokumentiert hat.

Wie startet ein Projekt mit der Software-Modernisierungssuite?

Mit einem kostenlosen 45-minütigen Scoping-Call und anschließend einem Assessment zum Festpreis, das Zielarchitektur, Renovate/Renew/Replace-Entscheidungen, Roadmap, Aufwandsschätzung und einen in Ihrer Codebasis verankerten Business Case liefert.

Software-Modernisierungssuite

Software Evolution — Modernisierung + Innovation: KI-beschleunigt, expertengeführt.

Legacy-Software ist kein IT-Problem, sondern ein Innovations- und Geschäftsrisiko. Die Software-Modernisierungssuite von XITASO beschleunigt die langsamen, teuren Teile der Modernisierung mit KI – unsere Software-Engineers sorgen dafür, dass schneller auch korrekt bedeutet.

Auf einen Blick:

Das Problem: ~70 % des IT-Budgets fließen in den Erhalt von Legacy-Systemen. Das Schwierigste ist selten der Code, sondern die Rekonstruktion dessen, was das System fürs Geschäft leistet und wie es tatsächlich genutzt wird – wenn Dokumentation und die ursprünglichen Entwickler fehlen.
Unser Mechanismus: bewährtes, menschengeführtes Requirements- und Geschäftsprozess-Engineering, ergänzt durch KI, die das Verstehen und Migrieren komprimiert (5–15×) – ausgeführt in einem technischen Harness mit deterministischem Tooling.
Das Resultat: eine modernisierte, gut verstandene Basis für neue Funktionen und Geschäftsmodelle – erst modernisieren, dann darauf innovieren.
Für wen: geschäftskritische Systeme in veralteten/eingestellten Technologien (z.B. .NET Framework, AngularJS, WinForms, Legacy-SPS) – besonders bei dünner Dokumentation und bald pensionierten Schlüsselexperten.

100 % kostenlos

Unser Angebot: vom Assessment mit festem Umfang zur Innovation

Schritt 1 · Empfohlener Einstieg

Modernisierungs-Assessment

„Sollten Sie modernisieren, und wie?“ Festpreis · fester Umfang · risikoarm

Ein Engagement mit festem Umfang, zeitlich begrenzt, das Ihr System inventarisiert, die relevanten Discovery-Fähigkeiten anwendet und eine klare, evidenzbasierte Empfehlung liefert, bevor Sie sich auf ein Modernisierungsbudget festlegen.

Dauer

typischerweise 2–4 Wochen, abhängig von Systemgröße und Anzahl der Repositories (bestätigt im Scoping-Call).

Deliverables

rekonstruierter Architektur-Snapshot
Anforderungsübersicht, dokumentierte Geschäftsprozesse (BPMN) und Domain Stories
Qualitäts- und Sicherheitsbefunde
Risikoregister
eine erweiterbare Zielarchitektur mit den treibenden Qualitätszielen
Pro-Komponente-Renovate/Renew/Replace-Entscheidungsmatrix
Meilenstein-Roadmap
Aufwandsschätzung und ein Business Case, verankert in Ihrer Codebasis.

Voraussetzungen

Zugang zu Quell-Repositories und verfügbarer Dokumentation; etwa 2–4 Fachexperten für jeweils wenige Stunden über Interviews und Validierungssitzungen (geringe operative Störung); eine benannte technische und geschäftliche Kontaktperson. (Wo der Zugang zum Quellcode eingeschränkt ist, können wir die Requirements- und Prozessrekonstruktion trotzdem durchführen, wie wir es bereits getan haben [3].)

Kommerzielle Bedingungen

Festpreis, fester Umfang. Weil das Assessment zeitlich auf ein kleines Expertenteam über 2–4 Wochen begrenzt ist, folgen die Kosten einer vorhersehbaren Bandbreite, vor allem getrieben durch Systemgröße und -Komplexität, statt einer offenen Discovery-Rechnung. Der genaue Preis und der Umfang werden in einem kostenlosen Scoping-Call festgelegt.

Entscheidungskriterien, die Sie mitnehmen

eine belastbare Go/No-Go-Entscheidung zur Modernisierung (einschließlich „nicht modernisieren — stilllegen oder Standardsoftware kaufen“, falls das die ehrliche Antwort ist), das empfohlene Muster (iterativ vs. Big Bang), das erste anzugehende Slice und der erwartete Business Case.

Schritt 2

Iterativ modernisieren, um Risiko zu reduzieren

Das Assessment endet mit einer kalkulierten, meilensteinbasierten Roadmap, sodass das gesamte Engagement von Anfang an transparent ist:

Liefermodell

meilensteinbasierte Lieferung pro Komponente/Slice (standardmäßig Strangler Fig). Jedes Slice wird abgegrenzt, geschätzt und als validiertes, lauffähiges Inkrement ausgeliefert. Jedes Inkrement ist individuell validiert um Risiko zu begrenzen und sauber Pausierungsmöglichkeiten zu schaffen.

Kommerzielle Bedingungen

gedeckeltes Time-and-Materials.

Team

ein von XITASO-Experten geführtes Squad, das mit Ihren Fachexperten arbeitet.

Governance

ein regelmäßiger Steering-Rhythmus mit Ihren technischen und geschäftlichen Verantwortlichen, Architekturboard-Touchpoints bei jeder Renovate/Renew/Replace-Entscheidung und ein expliziter Risikoakzeptanz-Schritt vor jedem Produktions-Cutover.

Schritt 3 · Optional

Innovation auf der modernisierten Basis

Modernisierung ist das Fundament für das, was als Nächstes kommt. Sobald eine stabile, sichere Basis steht (aufgebaut auf der im Assessment definierten Zielarchitektur), können dieselben expertengeführten, KI-beschleunigten Teams die neuen Features, Kanäle und Geschäftsmodelle hinzufügen, die das Legacy-System blockiert hat, jetzt auf einer Architektur, die dafür ausgelegt ist. Häufige Beispiele:

Ein neues Frontend oder Interface

ein mobiles oder Web-Frontend, oder eine öffentliche API, auf Basis dessen, was früher eine reine Desktop- oder Terminal-Anwendung war.

Analytics und Reporting

Dashboards und Reporting auf Daten, die zuvor in Formularen und Tabellenblättern eingeschlossen waren, und darauf aufbauend die KI-/ML-Anwendungsfälle, die der alte Stack nicht hosten konnte.

Neue Umsatz- und Liefermodelle

Cloud- oder SaaS-Bereitstellung (z.B. von Predictive Maintenance Funktionalitäten), Self-Service-Portale für Kunden oder Lieferanten und Integrationen mit Partnersystemen.

Effizienzgewinne

Automatisierung der manuellen Workarounds, die die Requirements-Arbeit aufgedeckt hat.

Zugang freischalten

Kostenlosen Vollzugang zur Software-Modernisierungssuite erhalten

Alle sieben Suite-Komponenten, die 4-Phasen-Methodik und die drei kritischsten Mechanismen im Detail – kostenlos, nach kurzer Registrierung freigeschaltet.

Name *

Firma *

Geschäftliche E-Mail *

Telefon

Ich willige ein, dass die von mir angegebenen Daten für die Bereitstellung des Inhalts verarbeitet werden. Mir ist bewusst, dass XITASO mich über die angegebenen Daten kontaktieren darf. Diese Einwilligung kann ich jederzeit widerrufen, z.B. per E-Mail an info@xitaso.com. Weitere Informationen in unserer Datenschutzerklärung.

Vorschau-Modus: Ohne verbundenes Contact-Form-7-Formular wird der Inhalt zu Testzwecken direkt angezeigt. Sobald oben der CF7-Shortcode eingefügt ist, erfolgt die Freischaltung erst nach erfolgreichem Absenden.

Freigeschalteter Inhalt

Warum Software-Modernisierung aktuell ein Thema ist

Für viele Unternehmen wird Software-Modernisierung ein Thema aus purer Notwendigkeit:

62 % der Unternehmen sagen, dass Teile ihrer geschäftskritischen Anwendungen bereits zu veraltet sind, um heutige Anforderungen zu erfüllen; 76 % erwarten, dass mindestens ein Fünftel ihrer Kernanwendungen innerhalb von fünf Jahren modernisiert werden muss. [1]

Nur ~30 % des IT-Budgets erreichen Innovation; ~70 % werden für den reinen Betrieb verbraucht. [2]

[1] Lünendonk & Hossenfelder, „IT-Modernisierung zwischen Legacy, Cloud und KI,“ Lünendonk-Studie 2026. [2] VDMA, IT-Kosten-Benchmark 2025.

Hinter diesen Zahlen steht ein Muster, das unsere Kunden immer wieder beschreiben:

Dokumentation fehlt oder ist veraltet, und die zugrunde liegenden Geschäftsprozesse sind unklar; in einem realen Fall wusste eine Organisation nicht einmal, ob ein System noch geschäftskritisch war.
Die Menschen, die das System verstehen, nähern sich dem Ruhestand. Jahrzehnte an Wissen verlassen bald das Unternehmen, und mit Ihnen die Basis von der der Menschen oder KI dieses Wissen erben könnten.
Niemand hat ein aktuelles Bild davon, wie die Software wirklich genutzt wird: welche Rollen was tun, welche Arbeitsabläufe davon abhängen und welche manuellen Workarounds sich um Lücken herum gebildet haben.
Veraltete Technologie (z. B. .NET Framework, AngularJS, WinForms auf altem Windows) blockiert neue Anwendungsfälle, erhöht die Kosten jedes neuen Features und erzeugt Vendor-Lock-in.
Große Codebasen verbergen unbekannte Randfälle, und Regressionstests fehlen, sodass sich niemand traut, etwas anzufassen.

Das Ergebnis: Das Geschäft kann nicht rechtzeitig auf Marktveränderungen und neue Anforderungen reagieren, die Entwicklung neuer Geschäftsmodelle wird ausgebremst, und neue Technologie wie KI lässt sich nicht in die bestehenden Systeme integrieren. Die IT hört auf, Innovationstreiber zu sein, und wird zur Bremse.

Der Business Case: freigesetztes Budget, günstigere Features, kontrolliertes Risiko

Die Suite adressiert das teuerste Problem der Legacy-Arbeit (ein System sicher gut genug zu verstehen, um es zu verändern) und komprimiert es mit KI unter technischer Kontrolle. Daraus werden Ergebnisse auf Vorstandsebene:

Freigesetztes Betriebsbudget. Jede Aufgabe, die KI komprimiert (Reverse Engineering, Migration, Testerstellung, Security-Triage), ist Aufwand, der nicht mehr aus dem ~70-%-„Keep-the-lights-on“-Budget bezahlt werden muss.
Günstigere Features, über Jahre. Rekonstruierte Anforderungen, dokumentierte Geschäftsprozesse, ein Domänen-Glossar und ein Regressionstest-Sicherheitsnetz sind dauerhafte Vermögenswerte. Jedes zukünftige Feature ist schneller und risikoärmer, weil sie existieren.
Schnellere Time-to-Market. Die Kompression mehrwöchiger Analyse- und Migrationsaufgaben ist der Unterschied zwischen einer Modernisierung, die in Quartalen gemessen wird, und einer, die in Jahren gemessen wird.
Risiko wird laufend reduziert. Wir liefern kontinuierlich in validierten Inkrementen, sodass Wert entlang des Weges realisiert wird, statt auf einen mehrjährigen Rewrite zu setzen, der häufig Modernisierungsbudgets verschlingt.
Eine Grundlage für Innovation. Eine stabile, gut verstandene Basis ist die Voraussetzung für die neuen Features und Geschäftsmodelle, die das Legacy-System blockiert hat. Modernisierung ist damit die Basis, auf der diese späteren Schritte aufbauen, nicht das Ziel an sich.

Wir quantifizieren diese Zahlen für Ihr System im Assessment, sodass der Business Case auf Ihrer Codebasis beruht, nicht auf unseren Durchschnittswerten.

Für ein mittelgroßes System, bei dem ein vollständiger Rewrite auf 24 Monate geschätzt wurde, erlaubt ein Assessment-first, in Slices unterteilter Ansatz einem Kunden typischerweise:

das erste produktionssichere modernisierte Slice bereits im ersten Quartal auszuliefern, statt erst am Ende des Projekts;
jedes weitere Slice erst anzugehen, sobald das vorherige funktional und live ist, wodurch Risiko und Exposition begrenzt bleiben;
an einer stabilen, sicheren Basis zu stoppen, falls der Business Case für darauf aufbauende Innovation nicht gegeben ist.

Wie sich der Aufwand verschiebt: Nehmen Sie ein Programm mit einem Analyse-/Migrationsaufwand von beispielsweise 2.000 Personentagen. KI beschleunigt nicht alles gleichmäßig: Die mechanischen, gut getesteten Anteile (ein erheblicher Teil) komprimieren mit den 5–15×, die wir bei realen Aufgaben beobachten, während urteilslastige Arbeit (z.B. Architekturentscheidungen, Anforderungsvalidierung) das nicht tut. Selbst wenn nur ~40 % des Aufwands mechanische, klar abgegrenzte Arbeit ist, die KI gut beschleunigt, und diese ~8× komprimiert, sinkt dieser Teil von ~800 auf ~100 Tage: Der Analyse-/Migrationsaufwand des Programms sinkt um etwa ein Drittel. Aufgabe des Assessments ist es, zu messen, wie viel von Ihrem Code in diese Kategorie fällt, damit daraus eine reale Zahl statt eines Durchschnittswerts wird.

Das Grundprinzip: KI für Geschwindigkeit — Engineering für Korrektheit

KI ohne technisches Fundament erzeugt technische Schulden, nur schneller. Ein Modell, das Code ohne Leitplanken generiert, liefert „technische Schulden 2.0“ in Maschinengeschwindigkeit. Unsere Methode ist darauf ausgelegt, das zu verhindern, indem die unkontrollierte Ausgabe der KI nicht das ist, worauf wir uns verlassen. Zwei Mechanismen leisten die Arbeit:

Das Harness — das technische Qualitäts-Framework, innerhalb dessen die KI Code generieren und ändern darf. Konkret besteht das Harness unter anderem aus: Architekturregeln und Abhängigkeitsbeschränkungen, durchgesetzt als Fitness Functions / CI-Gates; statischer Analyse und Qualitätsschwellenwerten, die den Build bei Verstoß fehlschlagen lassen; KI-generierten Charakterisierungs- und Differenztests (siehe unten) als Regressionsnetz; sowie definierten Abnahmekriterien plus menschlichem Review für jedes generierte Slice. Die KI arbeitet schnell; das Harness hält die Ausgabe korrekt und architekturkonform.
KI-gebaute, deterministische Tools — wo wir Daten brauchen, um zu entscheiden (Abhängigkeitsgraphen, Migrationspläne, Risikoanalysen), fragen wir nicht die KI nach der Antwort. Wir bauen mit KI-Unterstützung ein kleines, deterministisches Tool, welches die Daten liefert.

Beide Mechanismen drücken ein Prinzip aus: KI für Geschwindigkeit nutzen, aber das, worauf Sie sich verlassen, validieren. Was uns von anderen KI-Suiten unterscheidet, ist das technische Fundament und die Requirements-Disziplin, die die KI-Ausgabe vertrauenswürdig machen.

Die XITASO Software-Modernisierungssuite

Die Suite ist eine Reihe KI-gestützter Komponenten, die unsere Software-Engineers im Rahmen eines Engagements einsetzen. Abhängig vom Projekt und den Assessmentergebnissen werden die Komponenten ausgewählt die Ihr System tatsächlich braucht. Wie wir sie anwenden (die Requirements-Engineering-Methode, das Liefermodell) wird in den folgenden Abschnitten beschrieben.

Klicken zum Zoomen · ziehen zum Verschieben

Wie die zentralen Komponenten im Detail funktionieren

Wählen Sie einen Mechanismus, um zu sehen, wie er funktioniert:

durchsucht jede verfügbare Quelle (z.B. vorhandene Dokumente, System-Screencasts, den Code selbst, Datenbankinhalte, Logdateien und Nutzungsstatistiken), um Anforderungen, Geschäftsprozesse und ein Domänen-Glossar zu rekonstruieren. Diese Komponente liefert das Rohmaterial; die menschengeführte Methode, die daraus validierte Anforderungen macht, wird unter „Requirements & Prozess-Engineering“ weiter unten beschrieben und folgt XITASOs veröffentlichter RE-Praxis [3]. Wo eine Benutzeroberfläche existiert, kann sie zudem deren Interaktionen innerhalb eines definierten Umfangs erkunden, um Eingaben auf Wirkungen abzubilden.

Im Detail · So funktioniert sie

Requirements & Prozess-Engineering: rekonstruieren, was das System für das Geschäft leistet

Der häufigste und teuerste Fehler in der Modernisierung ist es, ein Legacy-System als nur Code zu behandeln, der neu geschrieben werden muss. Ein Legacy-System ist gleichzeitig drei Dinge: der Code, die Anforderungen und Qualitätsziele, die es stillschweigend erfüllt, und die Geschäftsprozesse und menschlichen Arbeitsabläufe, die darauf aufbauen. Die letzten beiden sind meist undokumentiert und existieren nur in den Köpfen der Nutzer und Betreuer. Das Lesen des Quellcodes zeigt, wie die Software funktioniert; es sagt Ihnen nicht, warum sie existiert, welches Verhalten wesentlich versus zufällig ist, oder welche Workarounds Nutzer erfunden haben, um Lücken zu überbrücken.

Deshalb verlassen wir uns nicht allein auf Code-Analyse. Wir befragen und beobachten die Menschen, die das System nutzen, schauen zu, wie sie tatsächlich arbeiten, und rekonstruieren daraus die Anforderungen und Prozesse. In einem Projekt wollte der Kunde den Quellcode aus Sicherheitsgründen gar nicht freigeben; die gesamte, erfolgreiche Analyse wurde durch Dokumentenstudium, Screencasts, Interviews und Vor-Ort-Beobachtung durchgeführt. Code ist eine Quelle unter mehreren, und oft nicht die entscheidende.

Die Rekonstruktion von Anforderungen und Geschäftsprozessen entscheidet darüber, ob Modernisierungen gelingen oder scheitern. Um die zu adressieren haben wir einen Ansatz zur Analyse eines jahrzehntealten, undokumentierten Legacy-Systems dokumentiert [3] und in einem peer-reviewten Paper publiziert. Die Suite operationalisiert diesen Ansatz und ergänzt ihn um KI-Beschleunigung.

Wir setzen vier komplementäre Methoden der Datenerhebung ein und speisen sie in drei Analyseartefakte ein:

Datenerhebung: Dokumentenanalyse (Triage der Masse vorhandener Dateien auf die wenigen, die zählen), Video-/Screencast-Analyse (eine aufgezeichnete Systemdemo ist oft die ergiebigste Einzelquelle), semi-strukturierte Interviews mit Entwicklern und Nutzern sowie Contextual Inquiry (Vor-Ort-Beobachtung von Nutzern bei ihrer realen Arbeit).
Datenanalyse: Domain Storytelling (visuelle, alltagssprachliche Erzählungen darüber, wer was mit dem System tut, verständlich für technische wie nicht-technische Stakeholder gleichermaßen), User Story / Journey Mapping sowie BPMN-Prozessmodelle der vom System unterstützten Geschäftsprozesse.

Zwei Lektionen aus dieser Arbeit prägen, wie wir jedes Engagement durchführen:

Beobachtung schlägt Interviews beim Aufdecken von Lücken. Nutzern bei der Arbeit zuzusehen, deckt zuverlässig Arbeitsschritte (und Softwaremängel) auf, die Interviews allein übersehen, einschließlich der Telefonate und Excel-Tabellen, mit denen Menschen das System umgehen.
Manche Redundanz ist ein Feature, keine Verschwendung. Denselben Prozess sowohl als Domain Story als auch als BPMN-Diagramm zu beschreiben, ist keine Doppelarbeit um ihrer selbst willen; die beiden Sichten validieren sich gegenseitig, und jede spricht einen anderen Stakeholder an; das baut das gemeinsame Verständnis auf, das eine Modernisierungsentscheidung braucht.

Wie ein Deliverable aussieht. Eine Domain Story ist zum Beispiel ein einseitiges Diagramm in klarer Fachsprache: nummerierte Pfeile zeigen, dass ein Testingenieur einen Fertigungsauftrag einer Maschine aus dem System zieht, gemessene Toleranzen erfasst und an die Qualitätssicherung zur Freigabe übergibt, verständlich sowohl für Experten auf dem Shopfloor als auch für Architekten. Das zugehörige BPMN-Diagramm drückt denselben Prozess in einer Notation aus, die Ihre IT-Organisation an eine Workflow-Engine übergeben kann. Zusätzlich erhalten Sie ein Domänen-Glossar, eine Anforderungsübersicht und, wo Quellcode verfügbar ist, einen Komponentenabhängigkeitsgraphen, erzeugt durch ein KI-gebautes, deterministisches Tool.

Wie KI diese Arbeit beschleunigt. KI verändert die Ökonomie der Anforderungs- und Prozessrekonstruktion, aber nicht ihre Natur. Sie triagiert Hunderte Dokumente auf die wenigen, die zählen, transkribiert und analysiert Stunden von Screencasts, entwirft die erste Version einer Domain Story oder eines BPMN-Prozessmodells in Minuten und gleicht rekonstruierte Anforderungen mit Code und Datenbank auf Widersprüche ab. Was sie nicht tut, ist zu entscheiden, was das Geschäft tatsächlich braucht; dieses Urteil bleibt bei Menschen. Der Effekt: Die aufwendige, wochenlange Analysephase komprimiert sich auf Tage, während die SME-Validierung, die sie ehrlich hält, erhalten bleibt.

Expertenwissen ist hier nicht optional. Ihre Fachexperten fungieren als semantischer Anker, der jede rekonstruierte Anforderung validiert und uns erlaubt, alte Fachbegriffe richtig zu interpretieren; dieselbe Rolle, die die KI-Ausgabe im Rest der Suite ehrlich hält.

rekonstruiert, wie ein System wirklich aufgebaut ist, insbesondere bei Multi-Repository-Software in unbekannten oder eingestellten Technologien. Legt die tatsächliche Architektur offen, die Komponenten und ihre Schnittstellen sowie die Lücke zwischen beabsichtigtem und tatsächlichem Design.

automatisierte Erkennung technischer Mängel (gemischte Muster, Verstöße gegen Best Practices, veraltete und End-of-Life-Technologie) und Sicherheitsschwächen, mit LLM-gestützter Triage, die Befunde einordnet und erklärt.

für eine Frage, die kein Standard-Tool beantwortet, baut die Suite in Stunden statt einer Woche ein kleines, deterministisches Analyse-Tool für genau diese Frage. Reales Beispiel: „Welche GUI-Komponenten können als Nächstes migriert werden, weil alle ihre Kindkomponenten bereits migriert sind?“ Die Suite generierte ein Tool, das den JavaScript-AST parst, einen Abhängigkeitsgraphen aufbaut und einen Migrationsplan sowie einen visuellen Graphen ausgibt. Die Ausgabe des Tools ist exakt und reproduzierbar, was sie zu einer vertrauenswürdigen Grundlage für Migrationsentscheidungen.

die Ausführungs-Engine: intelligente Codegenerierung (einschließlich automatisierter Sprach- und Framework-Versions-Upgrades), sprach- und frameworkübergreifende Migration sowie Codegenerierung aus den rekonstruierten Anforderungen (Spec-Driven Development).

Im Detail · So funktioniert sie

Spec-Driven Generation & Transformation: die Ausführungs-Engine

Wo Requirements-Engineering rekonstruiert, was das System leisten muss, ist diese Komponente das Wie der Umsetzung. Spec-Driven Generation & Transformation ist die Ausführungs-Engine der Suite: intelligente Codegenerierung (einschließlich automatisierter Sprach- und Framework-Versions-Upgrades), sprach- und frameworkübergreifende Migration sowie Codegenerierung direkt aus den rekonstruierten Anforderungen. Sie läuft immer innerhalb des Harness (Architektur- und Qualitäts-Gates begrenzen jede Änderung) und gegen die weiter unten beschriebene Legacy-as-Oracle-Validierung, sodass Geschwindigkeit nicht auf Kosten des Verhaltens geht.

Die schwierigen Teile der Ausführung sind aber selten die Migration selbst; es sind die begleitenden Risiken. Wir adressieren sie explizit, statt zu hoffen, dass sie nicht auftreten:

Daten- & Schema-Migration. Schema-Evolution, Datenqualitätsprobleme und die Koexistenz von alten und neuen Datenmodellen werden mit Anti-Corruption-Layern und, wo nötig, Dual-Write-/Backfill-Strategien gehandhabt, validiert durch dieselben Differenztests, die wir auf Code anwenden.
Nichtfunktionale Anforderungen. Latenz, Durchsatz, Verfügbarkeit, Sicherheit, Datenschutz und Wartbarkeit werden im Assessment als Qualitätsattribut-Szenarien erfasst und als Fitness Functions durchgesetzt, sodass ein Slice erst dann „fertig“ ist, wenn es diese erfüllt, nicht schon, wenn es lediglich funktionale Tests besteht.
Produktions-Cutover & Rollback. Weil Slices hinter der Strangler-Grenze koexistieren, führen wir den Cutover mit Feature-Flags / Parallelbetrieb durch und können ein Slice zurückrollen, ohne das gesamte System zurückzusetzen.
Observability. Jedes modernisierte Slice wird mit Logging, Metriken und Health-Checks ausgeliefert, sodass Regressionen in der Produktion erkannt werden, nicht von Nutzern.
Abhängigkeits- und End-of-Life-Risiko. Nicht mehr unterstützte Frameworks, Lizenzbeschränkungen und Vendor-EOL werden in der Discovery-Phase erfasst und in die Renovate/Renew/Replace-Entscheidung einbezogen.

beweist, dass generierter und migrierter Code das Verhalten des Systems bewahrt, indem das laufende Legacy-System als Charakterisierungstests erfasst und Differenztests dagegen ausgeführt werden, innerhalb einer architektur- und qualitätsgesteuerten CI. Diese Komponente verhindert, dass die Geschwindigkeit Regressionen einführt (siehe „Legacy-as-Oracle: Nachweis, dass sich der neue Code wie der alte verhält“ weiter unten für den Mechanismus).

Im Detail · So funktioniert sie

Legacy-as-Oracle: Nachweis, dass sich der neue Code wie der alte verhält

Das ist der Mechanismus, der uns erlaubt, schnell zu sein, ohne Verhalten zu brechen:

Bevor wir etwas ändern, erfassen wir das reale Verhalten des Legacy-Systems als Charakterisierungstests (Golden-Master-Tests), häufig auf hoher Ebene generiert (REST oder UI).
Während der Transformation führen wir Differenztests aus: identische Eingaben gehen sowohl an das Legacy-System als auch an die neue Komponente, und jede Abweichung in der Ausgabe lässt den Build fehlschlagen.
Das Legacy-System ist daher sowohl das, was wir ersetzen, als auch die Referenzimplementierung, die beweist, dass der Ersatz originalgetreu ist.

Ein Hinweis zur Vermeidung von Fehlern: Golden-Master-Tests erfassen das aktuelle Verhalten, einschließlich Defekten. Wir schützen uns davor, Fehler stillschweigend zu zementieren, indem wir die generierten Tests mit einer SME-Überprüfung der rekonstruierten Anforderungen kombinieren: wo Verhalten falsch ist, wird es auf Anforderungsebene korrigiert, nicht als Orakel eingefroren.

Technologie-Stacks, auf denen wir das umgesetzt haben: .NET Framework / C#, AngularJS und modernes Angular, TypeScript, Desktop (WinForms/WinUI) → Cloud-/Web-Migrationen sowie industrieller SPS-Code mit WinCC-HMIs.

das KI-für-Software-Engineering-Fundament, auf dem die anderen sechs Komponenten laufen, und das Kunden Kontrolle über Token-Kosten und Datenschutz gibt: selbst gehostete oder kundenspezifische Modell-Deployments, Quellcode und Prompts, die nicht in Trainingsdaten von Anbietern einfließen, und planbare Kosten pro Token.

Was die Suite auszeichnet: ein technisches Harness, rekonstruierte Anforderungen und souveräne KI

Kurz gesagt unterscheidet sich die Suite in drei Punkten:

Punkt 1

Anforderungen und Geschäftsprozesse werden rekonstruiert

nicht nur der Code neu geschrieben; dies basiert auf unserer veröffentlichten RE-Praxis [3].

Punkt 2

KI arbeitet innerhalb eines technischen Harness

statt einfach Code zu generieren, was „technische Schulden 2.0“ vermeidet.

Punkt 3

Die KI ist souverän und kann On-Premises betrieben werden

sodass Ihr Quellcode und Ihre Prompts innerhalb Ihrer Vertrauensgrenze bleiben.

Häufige Frage

Eine Frage, die uns häufig gestellt wird: Warum nicht einfach GitHub Copilot o.ä. mit dem eigenen Team nutzen?

Ein internes Team mit Standard-KI kann das Tippen beschleunigen, aber ohne Architektur-Leitplanken, ein verhaltensbewahrendes Harness, deterministische Tooling-Disziplin und Requirements-/Prozessrekonstruktion neigt es dazu, schneller Schulden auf einem System aufzubauen, das niemand vollständig versteht. Eine klassische Modernisierungsberatung bringt personalintensive Analyse zu personalintensiven Kosten und betreibt selten den KI-Stack, der diese Arbeit um das 5–15-Fache komprimiert. Und Nichtstun hat seine eigenen Kosten: Jedes Feature wird teurer, und der irgendwann erzwungene Rewrite ist der teuerste Weg von allen.

Was wir mitbringen, ist das technische und Requirements-Fundament um die KI herum. Unsere Differenzierung ruht auf drei Säulen:

1 · Architektur & Requirements

2 · Souveräne KI

3 · Code Quality Harness

Architektur- & Requirements-Exzellenz. Das Assessment liefert eine Zielarchitektur mit eingebauter Erweiterbarkeit und ein rekonstruiertes Bild dessen, was das System für das Geschäft leisten muss, ausgedrückt als konkrete Artefakte: ein Zielarchitektur-Diagramm, eine Pro-Komponente-Entscheidungsmatrix, Qualitätsattribut-Szenarien (nichtfunktionale Anforderungen), dokumentierte Geschäftsprozesse und Domain Stories. Es ist keine 1:1-Kopie der Legacy-Muster, nur schneller ausgeliefert.

Souveräne KI. On-Premises- / Kundenmandanten-Deployment: Ihr Quellcode bleibt, falls gewünscht, außerhalb des Zugriff von Hyperscalern, und Token-Kosten sind ein planbarer Posten, sodass Security, Datenschutz und Finanzen gleichermaßen zustimmen können. In der Praxis bedeutet das: individuelle Vertrauensgrenze mit entsprechendem Hosting, Audit-Logging von KI-Interaktionen und konfigurierbare Datenaufbewahrung, einsetzbar für regulierte und IP-sensible Anforderungen.

Code Quality Harness. KI generiert innerhalb bewährter Leitplanken, sodass Geschwindigkeit nicht zu technischen Schulden 2.0 wird.

Untermauert durch 14+ Jahre Softwareentwicklung, echte Kundenprojekte (keine Labordemos), veröffentlichte Requirements-Engineering-Praxis und ein expertengeführtes Modell, das das Wissen Ihrer, in den Ruhestand gehenden Experten, in einer Basis bewahrt, die sowohl Ihre Mitarbeitenden als auch Ihre KI erben können.

Unser Vorgehen vom Assessment zur Innovation

Wir starten nicht bei den Tools. Wir starten bei Ihren Zielen. Unser Vorgehen folgt vier klaren Schritten (Discovery & Assessment → Strategie → Iterative Umsetzung → Innovation), die sich direkt auf die kommerziellen Engagement-Schritte weiter unten abbilden: Die ersten beiden Schritte sind das, was das Assessment liefert, die weiteren sind 1-zu-1 Beziehungen. Das Diagramm visualisiert, wie sie zusammenpassen; die Schritte werden darunter im Detail beschrieben. Klicken Sie sich durch:

Klicken zum Zoomen · ziehen zum Verschieben

1 · Discovery & Assessment

2 · Strategie

3 · Iterative Umsetzung

4 · Innovation

Phase 1 — Discovery & Assessment · „Was muss sich ändern, und warum?“

Ziele, Randbedingungen, Stakeholder und Geschäftsprozesse erfassen; Anforderungen und Fachbegriffe mit unserer veröffentlichten Requirements-Engineering-Methode rekonstruieren (Interviews, Contextual Inquiry, Domain Storytelling, User Story Mapping und BPMN-Prozessmodellierung) und Dokumentation sowie Architektur aus Code und anderen Quelle reverse-engineeren. KI agiert als Sparringspartner; Ihre Experten bleiben der semantische Anker, der KI-Ergebnisse kontextualisiert; so bewahren wir das Wissen der in den Ruhestand gehenden Generation, statt es zu verlieren.

entspricht Engagement-Schritt 1: Modernisierungs-Assessment

Phase 2 — Strategie · Entscheiden, was sich ändert, und in welcher Reihenfolge.

Ausgehend von den rekonstruierten Anforderungen und den Qualitätszielen, die das Design leiten sollten (entnommen aus Architekturentscheidungsprotokollen, wo sie existieren, sonst mit Ihren Experten rekonstruiert), definieren wir eine erweiterbare Zielarchitektur: die Technologiewahl, Modulgrenzen und Schnittstellen, die das modernisierte System zu einer soliden Basis für neue Features machen, statt zu einer schnelleren Kopie der alten Einschränkungen. Hier fallen zentrale Entscheidungen:

Pro Komponente: Renovate, Renew oder Replace. Jede Komponente erhält eine explizite Entscheidung sowie eine Roadmap erreichbarer Meilensteine, die früh Wert schaffen.
Migrationsmuster, ehrlich gewählt. Strangler Fig / vertikale Slices ist unser Standard, bevorzugt, wenn mehrere Datenquellen oder interagierende Systeme beteiligt sind. Ein KI-gestützter Big-Bang-Release kann für weniger komplexe Systeme richtig sein, die sich schwer aufteilen lassen.
„Neuer ist nicht immer besser.“ Wir widerstehen der blinden 1:1-Neuimplementierung und verbessern stattdessen die User-Journey. Modernisierung dreht sich nicht immer um Innovation: einfachere Wartung, Robustheit, Performance und Sicherheit sind legitime Ziele für sich genommen.

entspricht Engagement-Schritt 1: Modernisierungs-Assessment

Phase 3 — Iterative Umsetzung · Liefern in validierten Inkrementen.

Schrittweise Umsetzung, jeweils ausgeliefert als validiertes, lauffähiges Inkrement, mit Spec-Driven Development, KI-generierten Regressionstests und fortlaufender Validierung gegen das Legacy-Orakel und Ihre Experten. Jedes Slice ist validiert, bevor das nächste beginnt, sodass das Risiko begrenzt bleibt und an jedem Meilenstein pausiert werden kann.

entspricht Engagement-Schritt 2: Iterativ modernisieren

Phase 4 — Innovation · Auf der modernisierten Basis aufbauen.

Entdeckung, Design und Umsetzung neuer Features auf der nun stabilen, erweiterbaren Architektur: die Frontends, Analytics, APIs und Geschäftsmodelle, die das Legacy-System blockiert hat. An einer modernisierten Basis zu pausieren, ist ebenso ein legitimes Ergebnis. Da diese Basis dokumentiert und erweiterbar ist, können Sie die Innovation später wieder aufnehmen, ohne die Grundlagenarbeit zu wiederholen. Die konkreten Optionen werden unter „Schritt 3 — Innovation auf der modernisierten Basis“ weiter unten beschrieben.

entspricht Engagement-Schritt 3: Auf der Basis innovieren

Evidenz: gemessene Ergebnisse aus realen Kundenprojekten

Reale Projekte, mit offen gelegter Messgrundlage, damit Sie sie selbst beurteilen können:

XITASO dokumentierte ein jahrzehntealtes Legacy-System, das von mehreren hundert Mitarbeitenden genutzt wurde, um Maschinen zu konstruieren und zu prüfen, ein System mit spärlicher Dokumentation und ohne Aufsicht durch eine IT-Abteilung. Der Kunde lehnte es aus Sicherheitsgründen ab, den Quellcode zu teilen, sodass das Team Architektur, Anforderungen und Geschäftsprozesse allein aus ~100 bereitgestellten Dokumenten (nur ~25 davon nützlich), einem 90-minütigen Entwickler-Screencast, Interviews und einer Vor-Ort-Contextual-Inquiry rekonstruierte, analysiert mit Domain Storytelling, User Story Mapping und BPMN-Prozessmodellierung. Ein wiederkehrender Befund: Lücken im Verständnis des Teams markierten zuverlässig reale Lücken in der Funktionalität der Software. [3]

Ergebnis: Das Projekt lieferte die Architektur-, Anforderungs- und Prozessdokumentation, die dem Kunden eine belastbare Grundlage gab, um über die Zukunft des Systems zu entscheiden; dieselbe „modernisieren oder nicht“-Entscheidung, die das Assessment liefert.

In einer historisch gewachsenen Kunden-Codebasis migrierten wir Datenmodelle und eine kundenspezifische Binär-Serialisierung von C# nach TypeScript. Etwa 20 Prompts erzeugten 2.363 Zeilen übersetzten Code und 79 automatisierte Tests in ~5 Stunden Agentenzeit, gegenüber einer manuellen Schätzung von ~10 Personentagen; eine ~15-fache Beschleunigung bei dieser Aufgabe.

Wie gemessen: Wall-Clock-Zeit des Agenten vs. die interne manuelle Schätzung des Teams für denselben Umfang. Der Agent erreichte nach jedem der ~10 Aufgabenblöcke einen validierten und laufenden Zustand.
Umfang & Vorbehalte: Dies ist eine klar abgegrenzte, mechanische Übersetzungsaufgabe mit starker Testabdeckung, die Art von Arbeit, bei der KI am stärksten ist. Es ist keine Aussage über die Geschwindigkeit einer gesamten Systemmigration. Review- und Integrationszeit durch Software-Engineers sind in enthalten, waren bei dieser Aufgabe aber minimal, weil Abweichungen den Test-Build sofort fehlschlagen ließen.

Für eine undokumentierte SPS-Produktionslinie rekonstruierte unser Agentic-Reverse-Engineering-Ansatz Struktur und Semantik des Codes als Grundlage für die Migration, eine ~5-fache Reduktion des manuellen Aufwands der Bestandsaufnahme.

Wie gemessen: Rekonstruktionsaufwand vs. die manuelle „Bestandsaufnahme“-Schätzung für dasselbe System.
Umfang & Vorbehalte: Misst die Analyse-/Inventarisierungsphase, nicht die vollständige Migration. Die Ausgabe ist ein Ausgangspunkt, den Experten validieren, keine fertige Migration.

Wir nutzen ein LLM, um Befunde statischer Security Analyse (SAST) zu triagieren, was Falsch-Positive reduziert und gleichzeitig echte Schwachstellen zur menschlichen Prüfung markiert. Das LLM ordnet ein und erklärt; es entscheidet nicht. Security-Teams behalten die Freigabe, und Befunde werden stichprobenartig geprüft, um übersehene positive Befunde zu vermeiden. [4]

Verdoppelte Entwicklerproduktivität über die gesamte Praxis hinweg. Über unsere gesamte KI-gestützte Engineering-Praxis hinweg zeigt die vollständige Methode (nicht eine einzelne Aufgabe) einen Effekt von grob 2× Entwicklerproduktivität, basierend auf internen Projektdaten.

[3] Friedline, Jessica, and Jan-Philipp Steghöfer. „Combining Requirements Engineering Techniques for the Analysis of a Legacy System.“ REFSQ Workshops. 2024.

[4] Wagner, J., Müller, S., Näther, C., Steghöfer, J. P., & Both, A. (2025, July). Towards effective complementary security analysis using large language models. In 2025 IEEE International Conference on Intelligence and Security Informatics (ISI) (pp. 21-28). IEEE.

▶ Nächster Schritt

Buchen Sie einen kostenlosen 45-minütigen Scoping-Call.

Bringen Sie ein System mit, das Ihnen Sorgen bereitet. Wir sagen Ihnen ehrlich, ob Sie es modernisieren sollten, wie KI den Zeitplan verändern würde und was ein Assessment zum Festpreis dafür kosten würde.

Kostenlosen Scoping-Call buchen

Software-EvolutionModernisierung + Innovation:KI-beschleunigt, expertengeführt.

Auf einen Blick:

Unser Angebot: vom Assessment mit festem Umfang zur Innovation

Modernisierungs-Assessment

Iterativ modernisieren, um Risiko zu reduzieren

Innovation auf der modernisierten Basis