Wenn wir einem CTO sagen, dass wir PL/SQL in TypeScript konvertieren, ist die erste Reaktion meist Angst. „Sie schreiben unsere Geschäftslogik um?” Nein. Wir übersetzen sie. Diese Unterscheidung ist der entscheidende Punkt.
Ein Neuschreiben bedeutet, dass ein Entwickler den PL/SQL-Code liest, ein mentales Modell dessen bildet, was er tun sollte, und neuen Code von Grund auf schreibt. Genau dort entstehen Fehler. Genau dort verschwindet stillschweigend die australische GST-Ausnahme, die 2014 hinzugefügt wurde. Eine Übersetzung bedeutet, dass das System den PL/SQL-Code liest, strukturelle Muster erkennt und äquivalentes TypeScript erzeugt, das identisches Verhalten implementiert. Die Logik überlebt. Die Sprache ändert sich. Die Architektur verbessert sich.
Was sich ändert
Die Laufzeitumgebung. PL/SQL wird innerhalb der Oracle-Datenbank ausgeführt. TypeScript läuft in Node.js oder im Browser. Dieser einzelne Wechsel ermöglicht API-Bereitstellung, horizontale Skalierung und containerisiertes Deployment — drei Fähigkeiten, für die die Datenbank-Engine nie konzipiert war.
Das Typsystem. PL/SQL-Typen lassen sich sauber zuordnen. NUMBER wird zu number. VARCHAR2 wird zu string. DATE wird zu Date. Record-Typen werden zu Interfaces. Die Zuordnung ist mechanisch, nicht interpretativ.
Die Fehlerbehandlung. PL/SQL-Exceptions werden zu strukturierten Try/Catch-Blöcken. RAISE_APPLICATION_ERROR wird zu typisierten Fehlerantworten mit HTTP-Statuscodes, die nachgelagerte Systeme tatsächlich verarbeiten können.
Der Datenzugriff. Eingebettetes SQL wird zu API-Aufrufen. SELECT FROM contractors WHERE... wird zu this.api.getContractors(filters). Die Abfrage greift weiterhin auf dieselben Oracle-Tabellen zu, aber über eine kontrollierte REST-Schicht statt über direkte Datenbankkopplung.
Was gleich bleibt
Jede Validierungsregel. Wenn der PL/SQL-Code einen positiven Betrag verlangt, tut es das TypeScript ebenso.
Jede Berechnung. Wenn der PL/SQL-Code die Steuer als amount * rate / 100 berechnet, führt das TypeScript identische Arithmetik mit identischer Präzision durch.
Jede bedingte Verzweigung. Wenn der PL/SQL-Code CASE WHEN status = 'APPROVED' THEN... enthält, trägt das TypeScript dieselbe Bedingungsstruktur.
Jeder Workflow-Schritt. Wenn Bestellungen über 50.000 USD eine VP-Genehmigung erfordern, bevor sich der Status ändern kann, erzwingt der neue Code dasselbe Gate. Das Verhalten ist identisch, weil die Regeln identisch sind.
Was die Migration ermöglicht
Die neue Architektur ist nicht nur ein Sprachwechsel. Sie ermöglicht Fähigkeiten, die Oracle Forms nie bieten konnte:
- Unit-Tests. Jede Validierung wird zu einer unabhängig testbaren Funktion. Forms machte sinnvolle Testabdeckung nahezu unmöglich.
- Versionskontrolle. Das TypeScript liegt in Git. Jede Änderung hat einen Commit, einen Autor und einen Diff. PL/SQL in .fmb-Dateien hatte nichts davon.
- API-Bereitstellung. Logik, die in der Datenbank eingeschlossen war, wird von mobilen Apps, Partnersystemen oder KI-Agenten aufrufbar.
- Parallele Entwicklung. Mehrere Ingenieure arbeiten gleichzeitig an verschiedenen Modulen, ohne sich gegenseitig in die Quere zu kommen.
Die ehrlichen Einschränkungen
Lässt sich jede Zeile sauber übersetzen? Nein. Oracle Forms hat Eigenheiten — implizite Commits, Navigator-gesteuerter Bildschirmfluss, Canvas-Koordinaten-Positionierung — die keine direkten modernen Entsprechungen haben. Diese erfordern Architekturentscheidungen während der Migration, und wir treffen sie bewusst.
Aber die Kern-Geschäftslogik — die Regeln, Berechnungen, Validierungen und Workflows, auf die das Unternehmen tatsächlich angewiesen ist — lässt sich zuverlässig übersetzen. Mathematik ist Mathematik. Eine Beschränkung auf ein Kreditlimit ist eine Beschränkung auf ein Kreditlimit, unabhängig davon, welche Sprache sie durchsetzt.