Ein europäischer Versicherer bat uns, zwei Migrationspfade für 480 Oracle Forms-Masken zu schätzen. Ein Hand-Rewrite wurde mit 38 Monaten und 14 Entwicklern veranschlagt. Ein automatischer Code-Übersetzer mit 9 Monaten, produzierte aber TypeScript, das die originalen WHEN-VALIDATE-ITEM-Trigger Zeile für Zeile widerspiegelte. Keines war akzeptabel.
Das ist die falsche Wahl, die jeder CIO erbt, der Forms modernisiert. Langsam und sicher, oder schnell und architektonisch identisch mit dem System, dem Sie entkommen wollen.
Die falsche Wahl
Manuelle Rewrites verbrennen Budget und lassen das Geschäft jahrelang auf dem Legacy-System laufen. Unsere Migrationsdaten zeigen, dass die durchschnittliche Forms-Unternehmensanwendung zwischen 200 und 600 Masken, 1.500 bis 4.000 PL/SQL-Trigger und ein Jahrzehnt undokumentierter Geschäftsregeln umfasst. Das von Hand umzuschreiben ist ein mehrjähriges Archäologieprojekt.
Automatische Übersetzer kehren den Kompromiss um. Sie sind schnell, behandeln aber die .fmb-Datei als Wahrheitsquelle und erzeugen moderne Syntax, die jede Legacy-Annahme beibehält. Das Ergebnis kompiliert. Es trägt aber auch dieselbe Kopplung, dieselben prozeduralen Muster und dieselben Wartungsschulden weiter.
Es gibt einen dritten Weg.
Was strukturierte Migration tatsächlich tut
Statt Code Zeile für Zeile zu übersetzen, arbeiten wir auf einer höheren Abstraktionsebene. Die DEX Elements-Pipeline läuft in drei Stufen.
- Analyse jedes Blocks, Triggers, LOV, Canvas und jeder PL/SQL-Prozedur in der Quellanwendung.
- Extraktion der Geschäftslogik in eine normalisierte Zwischenrepräsentation, die wir JSON-Deskriptor nennen.
- Generierung einer modernen TypeScript-Anwendung aus diesen Deskriptoren unter Verwendung eines gesteuerten Komponenten-Frameworks.
Die Zwischenrepräsentation ist kein Code. Sie ist eine strukturierte Beschreibung dessen, was die Anwendung tut. Diese Unterscheidung ist der gesamte Punkt. Die Ausgabe ist deterministisch und prüfbar. Geschäftslogik überlebt, ohne die Legacy-Architektur zu erben. Dieselben Deskriptoren können jedes Framework ansprechen, das wir unterstützen. Und wenn sich ein Deskriptor ändert, aktualisiert sich die laufende Anwendung.
Warum das für Unternehmen wichtig ist
Für den CTO ist das Ergebnis Standard-TypeScript, das dem Unternehmen vollständig gehört. Keine Vendor-Laufzeit, keine Oracle-Lizenzierung auf dem neuen Stack.
Für das Entwicklungsteam ist das generierte Projekt ein normaler npm-Workspace. Vertrautes Tooling, vertrautes Deployment, keine speziellen Migrationskenntnisse erforderlich, um es nach unserem Abgang zu warten.
Für das Geschäft wird die Migration in Monaten statt Jahren geliefert. Das Legacy-System läuft parallel, und der Cutover erfolgt Maske für Maske statt als ein Wochenende voller Risiko.
Für die Compliance trägt jede Maske einen strukturierten Deskriptor, der gleichzeitig als lebendige Dokumentation dient. SOX-Audit-Trails, rollenbasierter Zugriff und Sicherheitsprüfung leben auf Framework-Ebene statt in individuellen Entwicklerentscheidungen.
Die KI-Ebene, die dies erschließt
Sobald eine Anwendung als JSON-Deskriptoren existiert, kann ein KI-Assistent sicher damit arbeiten. Das Modell generiert keinen Freiform-Code. Es bearbeitet ein eingeschränktes Schema, das das Framework bereits rendern kann. Die Ausgabe ist vorhersagbar, prüfbar und reversibel.
Das ermöglicht Arbeit, die auf Rohcode leichtsinnig wäre. Nicht-technische Analysten modifizieren Masken, indem sie Änderungen in natürlicher Sprache beschreiben. Das System beantwortet Fragen über sein eigenes Verhalten. Neue Module werden aus einem Absatz Absicht entworfen statt aus einem Jira-Epic.
Strukturierte Migration ist nicht nur schneller als ein Rewrite oder sauberer als ein Übersetzer. Sie verwandelt ein einmaliges Projekt in eine permanente Fähigkeit.