Die Anwendung läuft. Sie wird täglich benutzt, sie hält einen Teil Ihres Geschäfts am Laufen — und zuständig ist eigentlich niemand mehr. Der Entwickler hat das Unternehmen verlassen, der Dienstleister von damals macht etwas anderes, oder das Thema ist über die Jahre so komplex geworden, dass im Haus niemand mehr hineingreifen will.
Diese Situation ist der Grund, warum die meisten Anfragen bei uns eintreffen. Wir übernehmen bestehende Oracle-APEX-Anwendungen — auch wenn sie jemand anderes gebaut hat, auch wenn niemand mehr genau weiß, wie sie funktionieren.
Woran Sie merken, dass es Zeit ist
- „Der Kollege, der das gebaut hat, ist seit einem Jahr weg. Seitdem traut sich keiner mehr an die Anwendung."
- „Wenn etwas nicht funktioniert, fragen die Anwender bei mir — und ich weiß es auch nicht."
- „Wir müssten die Datenbank aktualisieren, aber niemand kann sagen, ob die Anwendung danach noch läuft."
- „Es gibt eine Liste offener Wünsche. Die liegt da seit zwei Jahren."
- „Wir wissen nicht, wie viel technische Schuld in der Anwendung steckt."
Wenn Ihnen einer dieser Sätze bekannt vorkommt, ist der Zustand nicht ungewöhnlich. Er ist der Normalfall bei Anwendungen, die ihren Zweck erfüllt haben und deshalb nie wieder Priorität bekamen.
Wie eine Übernahme abläuft
Wir ändern nichts, bevor wir die Anwendung verstanden haben. Der Ablauf ist deshalb in jedem Fall derselbe:
Schritt 1
Zugänge klären
Wer hat Zugriff auf Datenbank, APEX-Workspace, Quellcode und die Wege, über die Änderungen produktiv gehen? Diese Frage klingt banal und ist in der Praxis der häufigste Grund für Verzögerungen. Sie steht deshalb am Anfang, nicht in der Mitte.
Schritt 2
Analyse des Ist-Zustands
Wir lesen die Anwendung: Seitenstruktur, Prozesse, Datenmodell, Schnittstellen, Berechtigungen, verwendete APEX- und Datenbankversion. Daraus entsteht eine Bestandsaufnahme — auch dann, wenn es keine Dokumentation gibt. Genau das ist der Regelfall.
Schritt 3
Risiken benennen
Was ist dringend, was ist unangenehm, was ist nur unschön? Veraltete Versionen, fehlende Backups, Rechte, die zu weit reichen, Stellen, an denen die Anwendung bei mehr Daten kippt. Sie erhalten eine Liste mit Reihenfolge — nicht eine Sammlung von Befunden.
Schritt 4
Übernahme des Betriebs
Ab hier sind wir die Adresse für Störungen und Fragen. Wir begleiten Updates von APEX und Datenbank, halten die Anwendung lauffähig und dokumentieren, was wir ändern. Was aus der Risikoliste abgearbeitet wird, entscheiden Sie.
Schritt 5
Weiterentwicklung, wenn Sie sie wollen
Neue Anforderungen kommen als eigene, geschätzte Pakete — nicht nebenbei aus dem Supportbudget. So bleibt sichtbar, was Betrieb kostet und was Weiterentwicklung kostet.
Die Bestandsaufnahme aus Schritt 2 gehört Ihnen, unabhängig davon, wie es weitergeht. Wenn Sie danach zu dem Ergebnis kommen, dass Sie die Anwendung selbst weiterbetreuen wollen oder ein anderer Dienstleister das übernimmt, haben Sie mit ihr die Grundlage dafür.
Was laufender Support umfasst — und was nicht
Diese Grenze halten wir bewusst deutlich, weil sonst niemand mehr weiß, wofür das Budget verbraucht wird.
| Im laufenden Support enthalten | Separat beauftragt |
|---|---|
| Störungen aufnehmen, eingrenzen, beheben | neue Seiten, Module oder Prozesse |
| Fragen der Anwender beantworten | Umbau bestehender Abläufe |
| Updates von APEX und Datenbank begleiten | neue Schnittstellen zu anderen Systemen |
| kleine Korrekturen an bestehenden Funktionen | Migrationen und Plattformwechsel |
| Überwachung der bekannten Schwachstellen | größere Performance-Projekte |
| Dokumentation dessen, was sich ändert | Oberflächen-Überarbeitung |
Kleinere Änderungen im laufenden Betrieb sind kein Problem und werden nicht bürokratisch behandelt. Sobald aus einem Wunsch aber ein Vorhaben wird, bekommt es eine eigene Schätzung und eine eigene Freigabe.
Erreichbarkeit und Reaktionszeiten vereinbaren wir schriftlich, bevor die Zusammenarbeit beginnt — abgestuft nach der Bedeutung der Anwendung für Ihr Geschäft. Eine Anwendung, ohne die die Auftragsannahme stillsteht, braucht andere Zusagen als ein internes Auswertungswerkzeug. Was wir zusagen, sagen wir vorher zu und nicht im Störungsfall.
Wenn es keine Dokumentation gibt
Der häufigste Satz in Erstgesprächen lautet: „Wir haben da leider nichts Schriftliches." Das ist kein Hindernis, sondern die Ausgangslage in fast jedem Übernahmeprojekt.
Eine APEX-Anwendung dokumentiert sich zu einem großen Teil selbst — Seiten, Prozesse, Validierungen und Berechtigungen liegen in Metadaten, das Datenmodell in der Datenbank, die Fachlogik im PL/SQL-Code. Was daraus nicht hervorgeht, sind Absichten: warum eine Regel so ist, welcher Sonderfall welchem Kundenwunsch entstammt. Diesen Teil rekonstruieren wir im Gespräch mit den Anwendern, die mit der Anwendung arbeiten. Erfahrungsgemäß wissen sie mehr über die Fachlichkeit als jede Datei, die man noch finden könnte.
Was wir dabei aufschreiben, bleibt bei Ihnen.
Wer das macht
Die Anwendungen, die wir betreuen, sind meistens geschäftskritisch — in der Entsorgungswirtschaft, bei Sozialversicherungen, in Finanzdienstleistungen, Logistik, Energieversorgung, Handel und der Verpackungsindustrie. Aus über 25 Jahren Arbeit mit Oracle-Datenbanken und APEX kennen wir die Muster, die in gewachsenen Anwendungen entstehen, und die Stellen, an denen ein unbedachter Eingriff teuer wird.
Was wir dabei lernen, tragen wir auf Fachkonferenzen vor: APEX Connect, DOAG, KI-Navigator und die IT-Tage. Wer uns dort gehört hat, weiß vorher, mit wem er spricht — unsere Vorträge und Konferenzbeiträge.
Wenn Sie Ihr Team aufbauen wollen
Nicht jeder möchte die Betreuung dauerhaft abgeben. Wenn Sie eigene Entwickler haben oder aufbauen wollen, arbeiten wir mit ihnen: gemeinsame Umsetzung, Code Reviews, Übergabe von Wissen im laufenden Betrieb. Das Ziel ist, dass Ihr Team am Ende eigenständig arbeiten kann — mehr dazu auf der Übersicht Oracle APEX und in unseren APEX-Schulungen.
Ihr nächster Schritt
Schildern Sie uns in einem kurzen Gespräch, welche Anwendung es ist, wer sie gebaut hat und was aktuell weh tut. Danach wissen Sie, ob eine Analyse der sinnvolle erste Schritt ist — und was sie bei Ihnen umfassen würde.
Direkt Termin vereinbaren oder
Häufige Fragen zur Übernahme bestehender Anwendungen
Übernehmen Sie auch Anwendungen, die jemand anderes entwickelt hat? Das ist der Regelfall. Die meisten Anwendungen, die wir betreuen, hat jemand anderes gebaut — ein früherer Mitarbeiter, ein Dienstleister oder ein internes Projekt, das über Jahre gewachsen ist. Wir beginnen deshalb immer mit einer Analyse des Ist-Zustands, bevor irgendetwas verändert wird.
Unsere Anwendung ist kaum dokumentiert. Ist das ein Problem? Nein, das ist der Normalfall. Fehlende Dokumentation ist der Grund, warum wir mit einer Analyse anfangen und nicht mit einer Änderung: Wir lesen die Anwendung selbst — Seiten, Prozesse, Datenmodell, Schnittstellen, Berechtigungen — und schreiben auf, was wir finden. Diese Dokumentation gehört Ihnen und bleibt bei Ihnen, auch wenn die Zusammenarbeit endet.
Was ist im laufenden Support enthalten und was wird separat beauftragt? Enthalten sind Betrieb und Pflege: Störungen beheben, Fragen der Anwender klären, Updates von APEX und Datenbank begleiten, kleine Korrekturen. Alles, was neue Funktionen schafft oder bestehende umbaut, ist Weiterentwicklung und wird separat beauftragt — mit eigener Schätzung und eigener Freigabe. Diese Trennung halten wir bewusst strikt, weil sonst niemand mehr weiß, wofür das Budget verbraucht wird.
Was passiert, wenn der ursprüngliche Entwickler nicht mehr erreichbar ist? Dann arbeiten wir ohne ihn. Was er wusste, steht in der Anwendung — im Datenmodell, in den Prozessen, im PL/SQL-Code. Das ist mühsamer als eine Übergabe, aber es ist Routine. Kritisch wird es nur bei Zugängen: Ohne Zugriff auf Datenbank, Workspace und Deployment-Wege kommt niemand weiter. Diese Zugänge zu klären ist deshalb der erste Schritt.
Bleiben wir dauerhaft von Ihnen abhängig? Das ist nicht das Ziel. Wenn Sie eigene Leute haben oder aufbauen wollen, arbeiten wir mit ihnen zusammen statt an ihnen vorbei: Code Reviews, gemeinsame Umsetzung, Übergabe von Wissen im laufenden Betrieb. Wir dokumentieren so, dass ein anderer weiterarbeiten kann — auch jemand, der nicht wir ist.
Können Sie auch nur einzelne Fragen beantworten, ohne Vertrag? Ja. Manche Kunden brauchen keinen laufenden Support, sondern jemanden, den sie bei einer konkreten Frage anrufen können. Das ist möglich, hat aber eine Grenze: Ohne Kenntnis der Anwendung ist jede Antwort eine Vermutung. Für Anwendungen, die geschäftskritisch sind, ist die Analyse deshalb auch dann der bessere Einstieg.
Weiter zu den anderen APEX-Themen: Performance-Probleme · Migration von Oracle Forms · Neuentwicklung · zurück zur Übersicht Oracle APEX.