Entwicklung
Ablösung von Oracle Forms
Die Ablösung ist kein Technologietausch. Die eigentliche Aufgabe ist der Wiederaufbau der über Jahrzehnte gewachsenen Geschäftslogik und der Arbeitsabläufe der Anwender — und genau das wird unterschätzt.
Der Premier Support für Forms 12c endet im Dezember 2026, der kostenpflichtige Extended Support im Dezember 2027. Forms selbst verschwindet damit nicht: Oracle unterstützt 14c mit Premier Support bis 2030 und mit Extended Support bis 2033. Für Systeme auf 12c oder einer älteren Version stellt sich daher jetzt die Frage, ob ein Upgrade auf 14c oder eine Ablösung folgt. Selten entscheidet das ein Datum. Meist sind es veränderte Betriebsanforderungen, knapper werdender Entwicklernachwuchs, moderne Integrationsbedarfe und Compliance-Aspekte. Es geht nicht darum, die Oracle-Basis infrage zu stellen, sondern zu klären, wie auf Oracle Database aufbauende Systeme langfristig tragfähig bleiben.
Warum sie unterschätzt wird
Hinter den Masken einer Forms-Anwendung arbeitet eine komplette Entwicklungsplattform. Wird das Projekt als rein technische Migration ausgeschrieben, fehlen in der Schätzung meist die folgenden fünf Punkte.
Anforderungen der Endanwender
Wie die Anwender tatsächlich mit dem System arbeiten, ist selten aufgeschrieben. Wer seit Jahren ohne Maus per Tastatur erfasst, wird das auch auf der neuen Oberfläche suchen, und die Akzeptanz hängt daran. Lässt sich ein gewohntes Verhalten auf der neuen Plattform nicht umsetzen, muss gemeinsam mit den Anwendern eine Alternative gefunden werden.
Eingebettete Geschäftslogik
Die Geschäftsregeln liegen verstreut in Triggern, clientseitigem Code und der Datenbank, und bei manchen weiß niemand mehr, warum sie dort sind. Sie zusammenzutragen ist eine eigene Arbeit, die eigens geschätzt werden muss.
Build- und Auslieferungskette
Automatisierte Builds, Tests und Auslieferung gibt es in der Forms-Welt meist nicht: Module werden von Hand kompiliert und verteilt. Für das neue System muss diese Kette von Grund auf aufgebaut werden.
Authentifizierung und Session-Verwaltung
In Forms hängen Anmeldung und Sitzung meist am Datenbankbenutzer. Ein modernes System ersetzt das durch token- oder föderationsbasierte Authentifizierung, und dafür muss auch die Architektur neu entworfen werden.
Systemintegrationen
Die Verbindungen zu den umliegenden Systemen müssen neu gedacht werden. Oft bringen sie Abhängigkeiten mit, die über das abzulösende System hinausreichen.
Keine der Zielplattformen ist eine „On-Click"-Migration. Auch APEX nicht, trotz der Oracle-Nähe: Die Funktionsmodelle von Forms und APEX unterscheiden sich erheblich, die Neuschreibung erfordert echtes Neudesign.
Wir beginnen mit einem Pilotprojekt
Der Pilot bereitet die Entscheidung vor, die Umschreibung des Portfolios kann erst danach kommen. Gemeinsam mit dem Kunden wählen wir ein typisches System und bauen dieselbe Funktionalität gleichzeitig mit zwei Technologien neu. Am Ende lassen sich beide Wege an derselben Aufgabe gemessen vergleichen.
Der Pilot zeigt im Kleinen und unter kontrollierten Bedingungen, was das große Projekt später leisten muss.
Drei Ergebnisse
Eine auf die Organisation zugeschnittene Methodik
Ein dokumentierter, wiederholbarer Prozess von der Analyse bis zur Inbetriebnahme, der sich an die jeweilige Organisation und ihren Betrieb anpasst.
Realistische technische Richtungen
Für beide Zielplattformen zeigt sich, wofür sie in der jeweiligen Umgebung taugen, wo ihre Grenzen liegen und welches Wissen ihre Pflege erfordert. Das zeigt der Neubau eines realen Systems.
Ein vollständiges Kosten- und Aufwandsbild
Neben der Entwicklung schätzen wir auch, was der Betrieb des neuen Systems und der Aufbau des nötigen Wissens kosten werden. Auf diese Zahl lässt sich die vollständige Ablösung planbar aufbauen.
Der Pilot Schritt für Schritt
- 01Analyse. Wir erfassen, wie das System funktioniert, welche Geschäftslogik und Integrationen es enthält und was davon tatsächlich genutzt wird. Diese Phase ist noch an keine Technologie gebunden.
- 02Parallele Umsetzung. Wir bauen dieselbe Funktionalität in Oracle APEX und auf Basis von Spring Boot und React/Angular neu.
- 03Vergleich. Wir messen beide Varianten an denselben Kriterien: wie viel Arbeit sie gekostet hat, was dabei herauskam, was der Betrieb erfordert und welches Wissen nötig ist.
- 04Erkenntnisse. Wir dokumentieren Methodik und Risikokarte, damit das große Projekt nicht bei null beginnt.
Oracle APEX
Ein datenzentrierter Ansatz nah am Oracle-Ökosystem. Ein Großteil der PL/SQL-Logik bleibt erhalten, was den Weg beschleunigt. Dafür ist die Oracle-Bindung stärker.
Spring Boot + React/Angular
Getrenntes Frontend und Backend. Sinnvoll, wenn das System aus der Datenbank heraus muss oder externe Integration, Mobil oder mehrere Kanäle das Ziel sind. Langsamer und teurer, dafür freier.
Nicht jedes Forms-System lohnt eine Ablösung, und nicht jedes gehört auf dieselbe Zielplattform. Das Ergebnis des Piloten kann auch sein, dass das System bei Forms bleibt. Dann übernehmen wir auch das Upgrade auf 14c, wie schon bei mehreren Kunden.
Warum wir dafür
Wir kennen die Quellseite und beide Zielplattformen, und die betriebliche Seite der Umstellung können wir ebenfalls übernehmen.
Die Quellseite: Oracle Database, PL/SQL, Datenmodell
Über zwanzig Jahre in Oracle-Umgebungen, und wir unterrichten PL/SQL, Advanced PL/SQL und Datenmodellierung
Die Zielplattform: Oracle APEX
Wir bauen, betreiben und unterrichten es
Die Zielplattform: Spring Boot mit React/Angular
Wir bauen mit allen dreien und unterrichten alle drei
Der riskante Teil: Umstellung, Parallelbetrieb, Datenintegrität
Das ist Betriebsarbeit. Wir betreiben Produktivsysteme mit 7×24-Bereitschaft, bisher 96 690+ Bereitschaftsstunden
Beginnen wir mit einem Gespräch
Darüber, was in einem Forms-System steckt und was davon tatsächlich genutzt wird. Daraus lässt sich schon ablesen, in welche Richtung es gehen sollte.