Case Study · Energy / ERP Modernisation

From unpatchable to auditable: an Oracle E‑Business Suite upgrade in three passes

An energy-sector operator was running a release of Oracle E-Business Suite that no longer received security patches, and the upgrade that would fix it was estimated to take the business offline for two weeks. Khwarizm, working under the prime integrator, rehearsed the cutover until it fitted inside a weekend.

Nothing in a producing plant waits for an IT project. Crews rotate, materials arrive at the gate, and payroll runs on the day it runs — whether or not the finance system is halfway through a migration. So when a security audit found that the operator’s core business system had fallen out of the vendor’s support window, the question was never whether to upgrade. It was how to upgrade something that the business cannot stop using. Khwarizm was brought in by the prime integrator to answer that question.

The release that could no longer be patched

The operator ran Oracle E-Business Suite 12.1 on Oracle Database 11g Release 2 — financials, HR and payroll, and supply chain, all of it in daily use across the business. The release had been stable for years, which is exactly how systems reach this position: nothing was wrong with it until the support window closed behind it.

Once a release stops receiving security fixes, the consequence is not a single audit finding. It is a standing one. Every subsequent audit cycle reopens it, and no compensating control fully answers it, because the honest answer to how will you patch this is that you cannot. The operator’s auditors were not asking for a mitigation plan. They were asking for a supported release.

Two weeks the business did not have

The obvious path was a single-pass upgrade: take production down, convert the data, bring it back up on the new release. Planned properly, that path was estimated at roughly two weeks of downtime.

For an operator whose people are paid on a shift cycle and whose materials move continuously, that is not a scheduling inconvenience. It is a fortnight of paper workarounds, followed by weeks of back-entry and reconciliation, with every error introduced during the gap surfacing later in a period nobody can close. A single-pass upgrade also has a harder problem: there is no rehearsal. The first time the team sees the conversion run against real production volumes is the day there is no way back.

Three passes, not one

So the upgrade was executed three times. Two full dry runs were performed against production-scale copies of the live system, and only the third pass touched production. Each rehearsal was treated as the real event: same sequence, same data volumes, same people, with every step timed.

That timing is what made the difference. A conversion of this kind is not uniformly slow — a small number of steps dominate the clock, and until the run is measured at production scale, nobody knows which ones. The rehearsals identified them; the gaps between passes were spent attacking them and moving everything that did not strictly require an outage out of the downtime window and into preparation. Each pass also produced a runbook that had actually been executed rather than one that had been written, which is the difference between a plan and a procedure.

The downtime that survived this process was small enough to be absorbed entirely by weekends and public holidays, and no working day was lost to the cutover. The programme ran roughly eighteen months from kickoff to final go-live: longer, deliberately, than a single-pass upgrade, in exchange for a cutover that had been proved twice before it mattered.

Rebuilding the floor under the application

The target was Oracle E-Business Suite 12.2.11 on Oracle Database 19c — a supported application release standing on a database release that still receives security updates, which was the point of the exercise. Financials, HRMS and Payroll, and Supply Chain moved together in a single cutover rather than in stages, so the business was never asked to run two systems at once or to reconcile across a split.

Khwarizm delivered this as a subcontractor: the prime integrator held the client relationship and the commercial scope, and Khwarizm owned the upgrade and database work — the conversion path, the rehearsal cycle, the performance work between passes, and the cutover runbook. Carrying the accumulated customisations and interfaces across the upgrade was the part of the work with the least room for improvisation, and the main reason the rehearsals were worth their cost.

The payroll run that used to take a shift

The clearest evidence that the platform underneath had changed came from payroll. The payroll run itself — the main payroll-generation process, not a report over it — had taken about three hours on the old stack. On the new one it completed in about ten minutes.

The value is not the time saved by one run. It is that a three-hour payroll run can only be executed once, near the end of the cycle, when there is no longer time to act on what it produces; a ten-minute run can be executed repeatedly, early, while discrepancies are still cheap to fix. Payroll processing stopped being a scheduled event the team waited on and became something they could simply do.

The results

An upgrade like this is invisible when it works. The crews were paid on the days they expected to be paid, the month closed on the calendar it always closes on, and the audit finding that had been reappearing every cycle was answered rather than mitigated. What the operator gained was not a new system — it was the same business running on ground that can be maintained, and a rehearsed procedure for the next time the support window moves.