Die Anwendung tut, was sie soll — sie sieht nur aus wie 2004, läuft in einer Umgebung, die immer schwerer zu betreiben ist, und die Zahl der Leute, die darin entwickeln können, sinkt jedes Jahr. Irgendwann wird aus einem technischen Thema ein personelles: Wer macht das eigentlich noch?
Der Umstieg auf Oracle APEX ist dann naheliegend, weil die Datenbank bleiben kann. Genau darin liegt der Unterschied zu einem Plattformwechsel: Der wertvollste Teil Ihrer Anwendung — die Fachlogik in der Datenbank — muss nicht neu erfunden werden.
Warum wir nicht in einem Wurf migrieren
Der Umstieg in einem einzigen Schritt klingt effizient und ist der Grund, warum Migrationsprojekte scheitern: Er verlangt, dass alles gleichzeitig fertig, getestet und abgenommen ist — bei einer Anwendung, die niemand mehr vollständig kennt.
Wir arbeiten deshalb in Abschnitten. Weil beide Anwendungen auf derselben Datenbank arbeiten, ist ein Parallelbetrieb in den meisten Fällen möglich:
- Bestandsaufnahme. Welche Masken gibt es, welche werden tatsächlich benutzt, wo steckt Fachlogik in der Oberfläche und wo in der Datenbank?
- Schnitt festlegen. Welcher fachlich abgeschlossene Bereich wechselt zuerst? Am besten einer, der wichtig genug ist, um ernst genommen zu werden, und klein genug, um beherrschbar zu bleiben.
- Diesen Bereich in APEX bauen — nicht als Kopie der alten Maske, sondern so, dass er sich wie eine heutige Anwendung bedienen lässt.
- Parallel betreiben. Die Anwender arbeiten im neuen Teil, der Rest bleibt vorerst, wo er ist. Zeigt sich ein Problem, ist der Rückweg vorhanden.
- Nächster Abschnitt. Bis nichts mehr übrig ist, das noch umziehen muss.
Der Nebeneffekt dieses Vorgehens ist wichtiger als die Risikoreduktion: Nach dem ersten Abschnitt wissen alle Beteiligten, wie viel Aufwand ein Abschnitt kostet. Ab dann ist das Projekt planbar.
Was mitkommt und was nicht
Was in der Regel bleibt: Datenmodell und die Logik, die in Packages, Prozeduren und Views in der Datenbank liegt. APEX arbeitet auf derselben Datenbank — dieser Teil wird weiterverwendet, nicht neu geschrieben.
Was umziehen muss: Fachlogik, die in Forms-Triggern steckt und damit an die Oberfläche gebunden ist. Wie viel das ist, entscheidet über den Aufwand der ganzen Migration — deshalb steht diese Frage in der Bestandsaufnahme ganz vorn.
Was neu entsteht: die Bedienung. Forms-Anwendungen sind über Tastatur, Blocknavigation und feste Trigger-Reihenfolgen gebaut. Eine 1:1-Übertragung ergibt eine APEX-Anwendung, die sich wie schlechtes Forms anfühlt — technisch migriert, praktisch schlechter als vorher. An dieser Stelle lohnt es sich, mit den Anwendern zu sprechen, statt Masken abzuzeichnen.
Was wegfällt: In fast jeder gewachsenen Anwendung gibt es Masken und Funktionen, die seit Jahren niemand mehr aufruft. Die Bestandsaufnahme macht das sichtbar. Nicht zu migrieren ist die günstigste Form der Migration.
Werkzeuge helfen, aber sie entscheiden nicht
Für Masken und einfache Strukturen gibt es Konvertierungswerkzeuge, und wir nutzen sie, wo sie Arbeit sparen. Sie erzeugen Rohmaterial, keine fertige Anwendung. Der Teil, der Urteilsvermögen braucht — welcher Ablauf heute anders gehört, welche Sonderlösung von damals gestrichen werden kann, welche Regel unverändert bleiben muss —, ist Handarbeit und der Grund, warum eine Migration mehr ist als eine Konvertierung.
Aus Projekten mit gewachsenen, geschäftskritischen Oracle-Anwendungen bringen wir erprobte Bausteine mit — Muster für Berechtigungen, Protokollierung, Deployment. Das sind Bausteine, keine Produkte: Sie werden an Ihre Umgebung angepasst, nicht darüber gelegt.
Wenn Sie selbst weiterentwickeln wollen
Eine Migration ist ein guter Zeitpunkt, eigenes Wissen aufzubauen — Ihr Team lernt die neue Plattform an der eigenen Anwendung statt an einem Beispiel. Wenn Sie das wollen, arbeiten wir von Anfang an gemeinsam: Ihre Entwickler bauen mit, wir übernehmen Reviews und die Stellen, die Erfahrung mit der Plattform brauchen. Das Ziel ist, dass Ihr Team am Ende eigenständig arbeiten kann. Passende Grundlagen dazu vermitteln unsere APEX-Schulungen.
Wenn Oracle nicht bleiben soll
Es gibt Fälle, in denen APEX die falsche Antwort ist: wenn ohnehin entschieden ist, dass die Daten die Oracle-Datenbank verlassen sollen. Dann ist die Migration nach APEX ein Zwischenschritt, der Geld kostet und nichts löst. Diese Frage klären wir vor dem Projekt, nicht darin — auch wenn die Antwort für uns manchmal bedeutet, dass es keinen Auftrag gibt.
Ihr nächster Schritt
Erzählen Sie uns, wie groß die Altanwendung ist, wer sie heute betreut und was den Umstieg auslöst — Betriebsrisiko, fehlendes Personal oder fachliche Anforderungen, die sich nicht mehr umsetzen lassen. Danach lässt sich sagen, ob eine Bestandsaufnahme der richtige erste Schritt ist.
Direkt Termin vereinbaren oder
Häufige Fragen zur Migration
Lässt sich Oracle Forms automatisch nach APEX konvertieren? Teilweise. Für Masken, Blöcke und einfache Trigger gibt es Werkzeuge, die Rohmaterial erzeugen, und die Datenbanklogik in Packages und Prozeduren bleibt in vielen Fällen unverändert nutzbar — das ist der eigentliche Hebel. Was kein Werkzeug übernehmen kann, sind Bedienlogik und Absicht: Forms-Anwendungen sind über Tastatur, Blocknavigation und Trigger-Reihenfolgen gebaut. Eine reine Konvertierung erzeugt eine APEX-Anwendung, die sich wie schlechtes Forms anfühlt.
Müssen wir alles auf einmal migrieren? Nein, und wir empfehlen es nicht. In den meisten Fällen ist ein Parallelbetrieb möglich: Beide Anwendungen arbeiten auf derselben Datenbank, und einzelne Bereiche wechseln nacheinander. So bleibt der Betrieb erhalten, jeder Abschnitt ist einzeln nachweisbar, und ein Rückweg existiert. Ein Umstieg in einem Wurf ist nur bei kleinen Anwendungen sinnvoll.
Was passiert mit unserer bestehenden PL/SQL-Logik? Die ist das Wertvollste am Bestand. Logik, die in Packages und Prozeduren in der Datenbank liegt, wird in aller Regel weiterverwendet — APEX greift auf dieselbe Datenbank zu. Aufwand entsteht dort, wo Fachlogik in Forms-Triggern steckt und damit an die Oberfläche gebunden ist; dieser Teil muss umziehen.
Niemand kennt die Altanwendung noch vollständig. Geht das trotzdem? Ja, das ist der Regelfall bei Anwendungen, die zwanzig Jahre laufen. Ausgangspunkt ist dann nicht die Dokumentation, sondern die Anwendung selbst plus die Anwender, die täglich mit ihr arbeiten. Wichtig ist die ehrliche Trennung zwischen dem, was fachlich gebraucht wird, und dem, was nur noch vorhanden ist: In fast jeder Altanwendung gibt es Masken, die seit Jahren niemand mehr öffnet.
Ist APEX ein sicherer Zielplattform-Entscheid? Für Anwendungen, deren Daten in einer Oracle-Datenbank liegen, ist es der Weg mit der geringsten Reibung: dieselbe Datenbank, dieselbe Sprache, vorhandenes Wissen bleibt nutzbar, keine zusätzliche Laufzeitumgebung. Wenn Ihre Daten dagegen ohnehin aus Oracle heraus sollen, ist APEX die falsche Antwort — dann ist die Plattformfrage die erste Frage, nicht die Migration.
Wie lange dauert eine Migration? Das hängt an der Zahl der Masken, an der Menge an Logik in der Oberfläche und daran, wie viel vom Bestand wirklich noch gebraucht wird. Eine belastbare Aussage entsteht nach der Bestandsaufnahme, nicht davor. Wir nennen bewusst keine Pauschalen: Bei Migrationen ist die Streuung zwischen vergleichbar großen Anwendungen größer als bei jeder anderen Projektart.
Weiter: Support und Übernahme · Performance · Neuentwicklung · zurück zur Übersicht Oracle APEX.