Most migration conversations assume you want to stay with Oracle and simply leave Forms behind. For some organisations that assumption is wrong. They want out of Oracle altogether — out of the licence fees, out of the dependency, out of a relationship they have decided no longer serves them. And very often Forms is the one thing keeping them in: the anchor application that justifies the database licence beneath it. For these organisations the relevant path is not modernisation within Oracle but a full exit from it.
A full exit means migrating both layers, not one. Where the other paths keep the Oracle database and change only what sits on top of it, this path moves the database as well — typically to PostgreSQL — along with the front end. It is the difference between redecorating a house and moving out of it. Nothing of the Oracle stack remains: not the database, not the middleware, not the licence. That is the point of choosing it.
PostgreSQL is the usual destination for good reasons. It is a mature, production-grade, open-source database used by large enterprises for demanding workloads, with no licence cost and a deep, current talent pool. It fits cloud-native architectures cleanly and has a rich ecosystem of tools and extensions around it. Choosing it is not settling for a cheaper, weaker option; it is a deliberate move to an open platform that many organisations now prefer on its own merits, licence savings aside.
The instinctive worry — that an open-source database cannot be trusted with serious workloads — is a decade or more out of date. PostgreSQL runs core systems in banks, governments and large enterprises, with mature support for transactions, replication, high availability and the kind of data integrity that regulated work demands. Commercial support is available from multiple vendors for organisations that want a contract behind it, so moving to it does not mean going without a safety net. The decision is about strategy and cost, not about whether the platform is ready; it has been ready for a long time.
It would be dishonest to present this as the easy path. It is the largest of the three changes, precisely because the database and the PL/SQL logic it holds must move, and that logic is often the most valuable and least documented part of the system. Migrating it is real work and carries the most complexity of any option. Any partner who describes a full Oracle exit as simple is either inexperienced or selling. The case for this path rests on its destination being worth that effort, not on pretending the effort is small.
That said, it is more achievable than its reputation suggests, because it is not done by hand. Schema and logic are migrated with substantial automation, and an evidence-based analysis of the system defines exactly what exists — every table, every procedure, every rule — so nothing is missed and nothing dead is carried across. The migration is phased, with the new system validated against the behaviour the analysis recorded, and the same parallel-running approach used on other paths applies here too. The complexity is managed deliberately, which is what separates a controlled exit from a risky one.
Validation is what keeps the database move honest. Migrated logic is checked against the behaviour the analysis recorded from the live system, so the new implementation is measured against what the old one actually did rather than against a specification that may be incomplete. Run in parallel on representative data, the PostgreSQL version and the Oracle version can be compared directly, and discrepancies surfaced before anything depends on them. The point is that fidelity is demonstrated, not assumed — which is exactly the reassurance a team needs before trusting decades of rules to a new database.
The reward is a clean break. No database licence, no middleware licence, predictable infrastructure costs, and the freedom to run where and how you choose, including cloud-native deployments that Oracle licensing made awkward. Over a five-year horizon this path tends to have the highest one-time cost and the lowest running cost of any option, because the recurring licence burden disappears entirely. For an organisation whose strategy is to own its stack rather than rent it, that trade is the whole point.
A full exit is the right path when leaving Oracle licensing is a genuine strategic goal, when the direction of travel is open-source or cloud-native, or when removing vendor lock-in matters enough to justify the larger change. It is the wrong path when the organisation has a deep, deliberate investment in Oracle it wants to keep, or no appetite for the risk of moving the database — in which case staying on the database and modernising above it fits better. As with every migration decision, the answer should come from your strategy and your system, not from a partner’s preference.
Because it is the largest of the changes, a full exit is also the one that most rewards starting early. The phased, module-by-module approach means the work can begin well before the support deadline and proceed at a controlled pace, with the database migration sequenced alongside the front end rather than crammed in at the end. An organisation that decides on a full exit eighteen months out has room to do it calmly; one that decides six months out is choosing the hardest path under the tightest constraint. The destination can be the right one and still demand a realistic runway.
Next step. A diagnosis tells you the true scope and cost of moving the database, so a full exit is a decision you make with the numbers in front of you.
