No board approves a migration on the strength of a single quote. “Migration costs this much” is not a decision; “this option costs less than the alternatives over time” is. The comparison that earns approval is a five-year cost-of-ownership view across every realistic option — including the option of doing nothing, which is never actually free. Without that comparison, a migration budget is just a large number with nothing to be measured against, and large numbers without context get deferred.
There are four options worth comparing, and a credible business case prices all of them. The first is to stay on Forms and absorb its rising costs. The second is to move to APEX, keeping the Oracle database. The third is to rebuild the front end on a modern stack while keeping the database. The fourth is a full exit, migrating the database to PostgreSQL as well. Each carries a different mix of one-time and recurring cost, and the cheapest option in year one is rarely the cheapest across five.
A five-year view has to include more than the build cost, which is the part everyone fixates on. It should account for licensing — the Oracle database licence, WebLogic, and the fact that APEX is included at no extra cost. It should include middleware and infrastructure, support fees and surcharges, and the ongoing cost of development and maintenance, which depends heavily on how scarce the required skills are. And it should put a figure, however rough, on the cost of risk: the compliance and security exposure that grows once support ends. One-time costs and recurring costs both matter, and they fall differently across the options.
The distinction between one-time and recurring cost is where most comparisons go wrong. A migration is largely a one-time cost followed by lower running costs; staying is a recurring cost with no end. Comparing a single year flatters the status quo, because it sets a full migration against twelve months of staying and ignores everything after. Only a multi-year view captures the crossover — the point at which the cumulative cost of staying overtakes the cost of having acted. Choosing the window matters: one year almost always favours doing nothing, and five years almost never does.
| Cost factor | Stay on Forms | APEX | Modern front end | PostgreSQL exit |
|---|---|---|---|---|
| Oracle DB licence | Continues | Continues | Continues | Eliminated |
| WebLogic middleware | Continues | Removed | Depends on stack | Removed |
| Support & surcharges | Rising; ends 2026/27 | Standard | Standard (DB) | None |
| Front-end rebuild | None | One-time | One-time | One-time |
| Database migration | None | None | None | One-time |
| Ongoing dev & talent | Scarce, costly | Available | Available | Abundant |
| Risk after 2026 | High and growing | Resolved | Resolved | Resolved |
The table tells a consistent story. Staying on Forms looks cheapest in the first year and worst across five, because its costs rise and its risk compounds. APEX flattens the licensing line, since it is already included, and removes the middleware. The modern-front-end path keeps the database licence but adds the cost of a new technology stack. The full exit to PostgreSQL carries the highest one-time cost and the lowest running cost, with no licensing at all. The pattern worth internalising: the option that is cheapest to start is almost never the option that is cheapest to own.
A generic comparison like this is directional only — useful for understanding the shape, useless as a budget. The real figures depend on your specific licences, the number of modules actually in use, the complexity of those modules, and what your team can maintain. This is where a diagnosis of the system matters: by producing a defensible scope and cost estimate, accurate to within roughly ten percent, it turns a generic comparison into your comparison, with numbers a CFO can rely on rather than ranges a CFO will discount.
What makes this practical is that a single diagnosis can price more than one destination. Because the analysis establishes the real scope, dependencies and complexity of the system, that same evidence can be projected onto each path — what APEX would take, what a modern front end would take, what a full exit would take — rather than estimating each from scratch. The result is a like-for-like comparison built on one consistent reading of the system, which is far more defensible to a finance function than three separate vendor guesses produced on different assumptions.
Cost narrows the field, but it rarely picks the winner outright, because the strongest options are often close. When they are, the decision falls back to strategy: whether you want to stay Oracle-centric or move toward open source, how much you value removing vendor lock-in, and what the business needs the system to do over the next five years. Cost tells you which options are affordable and sensible; strategy tells you which of those is right. A good comparison makes both conversations possible at once.
Next step. A diagnosis produces the real five-year numbers for each path — the inputs a board needs to choose rather than defer.
