For most of its life, an Oracle Forms system is an IT matter. After Oracle’s support ends — Premier in December 2026, Extended in December 2027 — it becomes something else for a regulated organisation: an audit matter. Running business-critical software that is unpatched and unsupported is, under financial regulation, a compliance exposure, and exposures of that kind are not settled in the IT department. They are raised by auditors and answered to the board. The system has not changed; the people who have to account for it have.
Several frameworks make this concrete rather than theoretical. DORA sets expectations for operational resilience, including the management of the technology that underpins critical services. MiFID II carries its own obligations, and national regulators such as KNF supervise how firms manage operational and technology risk. Under all of them, an unsupported platform running a critical process is not a free choice an organisation can make quietly; it is a risk that has to be understood, controlled and, when asked, defended.
It helps to anticipate the questions an auditor will actually ask, because they are predictable. Is the platform still supported by its vendor? If not, how are newly discovered security vulnerabilities being identified and managed without patches? What is the plan to remediate the situation, and what is its timeline? Can you demonstrate change management and control over a system you may not fully document? And given how few people can maintain it, what is your continuity plan if they leave? These questions are the spine of the conversation, and an organisation that cannot answer them is in difficulty regardless of whether the system is running smoothly.
Several of those questions turn on documentation, which is precisely what legacy Forms estates tend to lack. An auditor asking how you control changes to a critical system expects to see that you know what the system does, who can change it, and how those changes are reviewed. “The knowledge lives with one long-serving developer” answers none of that. The absence of a clear, current description of the system is not a minor gap in an audit context; it undermines the claim that the system is under control at all, however reliably it happens to run from day to day.
The instinctive defence — but it still works — misses what an auditor is assessing. Auditors do not evaluate whether a system runs; they evaluate whether its risks are understood and controlled. “It works” speaks to neither. An unsupported platform with no remediation plan fails on both counts at once: the risk is real and growing, and there is no evidence of control. Operational smoothness is not the test, and treating it as the answer is how organisations walk into findings they could have avoided.
A defensible position does not require the migration to be finished. What it requires is evidence of control. That means you understand the system — you have documentation and a map of its dependencies. It means you have assessed the risk honestly, including the security and continuity exposure. And it means you have a credible, resourced, time-bound plan that is actually in motion. An auditor faced with an unsupported platform and a clear migration underway sees an organisation in control of a known problem. The same auditor faced with inaction sees the opposite.
This is ultimately a conversation the board owns, not the IT function alone. Once an unsupported critical platform becomes a regulatory exposure, accountability sits with the executives who answer for operational resilience, and “IT has it on a list” is not a position any of them will want to defend. Reframing the migration in those terms — as the closure of a board-level risk rather than a technical upgrade — is often what moves it from a deferred IT project to a funded priority. The deadline does not just create a technical task; it creates a governance obligation with names attached to it.
An evidence-based diagnosis happens to produce exactly what an auditor wants to see. It documents a system that previously had no documentation. It generates a risk register naming the gaps and exposures. And it yields a scoped plan with a timeline — all produced under appropriate information-security controls, with certification such as ISO 27001 behind the process. In other words, it converts “we know the system is old” into “here is our understanding of it, here are the risks, and here is our plan,” which is the difference between an audit finding and a managed item.
Timing is what separates the two outcomes, and it usually comes down to how early the work began. An organisation that is scoped and moving before the deadline arrives can present control: a known risk with a plan in progress. An organisation that waits until the deadline has passed presents a problem: an unsupported critical system with nothing underway. The technical distance between those two positions can be small — a few months of head start — but in front of an auditor the difference is decisive.
Next step. A diagnosis gives you the documentation, the risk register and the scoped plan that turn an audit exposure into a position you can defend — with months to spare.
