The risk in an ageing Oracle Forms system is usually discussed as a technology problem. Underneath it is a workforce problem that is harder to fix. Forms is technology from the 1990s, and the developers who know it well are reaching the end of their careers. Few people are learning it, because there is little reason to start. The pool of people who can keep these systems running is shrinking and ageing at the same time — and that trend does not reverse.
In day-to-day terms this shows up as friction that worsens each year. Hiring someone who knows Forms takes longer and costs more. Fixing an issue depends on a small number of people, internal or contracted, whose time is increasingly scarce. Day rates for the skill rise as supply falls. The uncomfortable result is that the system becomes more expensive to maintain at exactly the same time as it becomes riskier to rely on — the two curves moving the wrong way together.
The shape of it is easy to recognise. A mid-sized organisation might rely on one internal developer who has maintained the Forms system for twenty years, supported by an external contractor booked months in advance at a rate that climbs every renewal. A routine change that would take days on a modern platform takes weeks, because it has to wait for the one person who understands the code. Nobody has decided to accept this risk; it has simply accumulated, one retirement and one rate rise at a time, until the organisation is quietly dependent on a market that is disappearing.
This is distinct from the problem of missing documentation; it is about people, not paper. When the ability to maintain a business-critical system rests with one or two individuals, their departure is not a routine resignation to be backfilled. It is a continuity event. The organisation can find itself unable to make even small changes to a system it depends on, because the people who understood how have gone. A single retirement should not be able to put a core system at risk, yet for many Forms estates it can.
This workforce risk multiplies with the support deadline rather than sitting beside it. Once Oracle support ends, there is no vendor to fall back on, so the burden of keeping the system safe falls entirely on people who know it — precisely the people who are becoming scarcest. The moment you most need that expertise is the moment it is hardest to find. Two risks that look separate on a register are, in practice, the same risk compounding.
For regulated organisations the workforce risk has a governance edge as well. Operational-resilience expectations increasingly ask firms to demonstrate that critical systems can be maintained and recovered — which is hard to evidence when the ability to do either rests with one or two people who could retire at any time. “We depend on a single contractor who knows Forms” is not a continuity plan an auditor will accept. The scarcity of the skill turns a staffing inconvenience into a resilience question that has to be answered, not just managed quietly.
The common response — keep paying contractors — works in the short term and fails in the long term. Contractors retire too, the rate only rises as the pool thins, and paying for scarce maintenance does nothing about the fact that the platform itself is unsupported. It is a way of buying time, not of solving the problem, and the price of the time keeps going up. At some point the money spent keeping an unsupported system on life support would have been better spent leaving it.
The durable answer is to move to a technology the market actually supplies. APEX has a large and active practitioner community; modern stacks like Java and React have enormous talent pools; PostgreSQL has one of the deepest ecosystems in software. Whichever path fits, the effect is the same: you trade a scarce, ageing skill for an abundant, current one. Maintenance stops depending on a handful of irreplaceable people and becomes something a normal hiring market can support.
There is a second benefit beyond availability. A platform the market understands is one your own people can realistically own, rather than depending on a shrinking pool of outside specialists. Hiring becomes a normal exercise, onboarding is faster because the skills are taught and documented widely, and the organisation regains control over its own roadmap instead of waiting on whoever still knows the old technology. Trading a scarce skill for an abundant one is not only cheaper; it moves the system back inside the organisation’s own capability.
Changing platform solves the future; you also have to protect the present, because the knowledge those experts hold can walk out before the migration is done. Two things guard against that. An evidence-based analysis documents the system from the system itself, so the knowledge is captured independently of any individual. And a co-creation approach to the migration transfers that knowledge to your own team as the work proceeds, so capability is not simply re-concentrated in a new set of few heads. The expertise is preserved and spread, not lost and replaced.
Next step. A diagnosis records what your experts know now, while they are still here to verify it — turning irreplaceable knowledge into documentation the organisation keeps.
