Development
Replacing Oracle Forms
Replacement is not a technology swap. Rebuilding the business logic accumulated over decades — and the workflows people built around it — is the actual job, and that is what gets underestimated.
Premier Support for Forms 12c ends in December 2026, and paid Extended Support in December 2027. Forms itself is not going away: Oracle supports 14c with Premier Support until 2030 and Extended Support until 2033. For systems on 12c or an older release, the question is therefore timely: upgrade to 14c, or replace. The date rarely settles it. More often it is changing operational expectations, a shrinking pool of developers, modern integration needs and compliance requirements. The point is not to question the Oracle foundations, but to work out how systems built on Oracle Database can be sustained long term.
Why it gets underestimated
Behind the screens of a Forms application, a complete development platform is at work. When a project is specified as a purely technical migration, the estimate usually leaves out the five things below.
End-user requirements
How users really work with the system is rarely written down. Someone who has been entering data from the keyboard, without a mouse, for years will look for the same on the new interface, and acceptance depends on it. Where a familiar behaviour cannot be reproduced on the new platform, an alternative has to be found together with the users.
Embedded business logic
The business rules live scattered across triggers, client-side code and the database, and for some of them nobody remembers why they are there. Collecting them is a separate piece of work that has to be estimated separately.
Build and delivery chain
Automated build, test and delivery usually does not exist in the Forms world: modules are compiled and copied out by hand. The new system needs this chain built from the ground up.
Authentication and session handling
In Forms, login and session are typically tied to the database user. A modern system replaces this with token-based or federated identity, and the architecture has to be redesigned for it.
System integrations
The links built up with surrounding systems have to be rethought. They often bring dependencies that reach beyond the system being replaced.
Neither target platform is a one-click migration. Not even APEX, despite the Oracle proximity: the operating models of Forms and APEX differ substantially, and the rewrite calls for genuine redesign.
We start with a pilot project
The pilot prepares the decision; rewriting the portfolio can only come after it. Together with the client, we pick a representative system and rebuild the same functionality with two technologies at once. At the end, the two paths can be compared on the same task.
The pilot shows in miniature, under controlled conditions, what the full project will have to carry out.
Three outcomes
A methodology fitted to the organisation
A written, repeatable process from discovery to go-live that fits how the organisation and its operations work.
Realistic technical directions
For both target platforms it becomes clear what they are good for in the given environment, where their limits are, and what skills it takes to maintain them. Rebuilding a real system is what shows this.
A complete cost and effort picture
Alongside development, we also estimate what running the new system and acquiring the necessary skills will cost. A full replacement can be planned on that figure.
The pilot, step by step
- 01Discovery. We map how the system works, what business logic and integrations it contains, and what people actually use. This stage is not yet tied to any technology.
- 02Parallel implementation. We rebuild the same functionality in Oracle APEX and on Spring Boot with React/Angular.
- 03Comparison. We measure both versions against the same criteria: how much work it took, what the result is, what running it requires, and what skills it needs.
- 04Lessons. We write down the methodology and the risk map, so the full project does not start from zero.
Oracle APEX
A data-centric approach that sits close to the Oracle ecosystem. Much of the PL/SQL logic stays, which makes it the faster path. In return, the tie to Oracle is stronger.
Spring Boot + React/Angular
Separated front end and back end. It comes into play when the system needs to break out of the database, or when external integration, mobile or multiple channels are the goal. Slower and more expensive, but freer.
Not every Forms system is worth replacing, and not all of them belong on the same target. The outcome of the pilot may also be that the system stays on Forms. In that case we carry out the upgrade to 14c as well, as we have for several clients.
Why us for this
We know the source side and both target platforms, and we can take on the operations side of the cutover as well.
The source side: Oracle Database, PL/SQL, the data model
Over twenty years in Oracle environments, and we teach courses in PL/SQL, Advanced PL/SQL and data modelling
The target platform: Oracle APEX
We build it, run it and teach it
The target platform: Spring Boot with React/Angular
We build with all three and teach all three
The risky part: cutover, parallel running, data integrity
That is operations work. We run production systems with 7×24 on-call cover, 96 690+ on-call hours so far
Let us start with a conversation
About what is inside a Forms system and what people actually use of it. That already shows which way to go.