Case Study · Aviation / Enterprise Platform Resilience
From one server to two data centres: re-platforming the ERP behind Africa’s busiest airport
Cairo Airport Company ran its Oracle E-Business Suite on a single node, across a mix of Solaris and Linux, with no second site to fail over to. Khwarizm, working under the prime integrator, moved it to a supported release on a clustered, consolidated Oracle Linux platform and built the disaster recovery site it had never had.
An airport is a place that cannot pause. Aircraft are turned around, crews are rostered, fuel and catering and spares are ordered and paid for, and the paperwork behind all of it has to keep moving at the same hour of the night as the aircraft do. Cairo International Airport — the busiest in Africa, and the airport through which most of Egypt’s visitors arrive — is run by Cairo Airport Company on behalf of the Egyptian Holding Company for Airports and Air Navigation. Its back office ran on Oracle E-Business Suite. That system ran on a single node, in a single room, on a release the vendor no longer supported. Khwarizm was brought in by the prime integrator to change all three of those things.
One machine, and no second one
The environment was Oracle E-Business Suite 12.1 — carrying Financials and HRMS, without Supply Chain — on Oracle Database 11g Release 1, running single-node across a mix of Solaris and Linux on x86. Every part of that sentence had become a liability, and they were separate liabilities that happened to be stacked on top of each other.
The release had left its support window, so security fixes no longer arrived — the kind of finding that reappears in every audit cycle until the release changes. The operating systems underneath were an unplanned mix — some Solaris, some Linux — each carrying its own patching and support to track. And the architecture was single-node from top to bottom: one database instance, one application tier. There was no second server to move to, and no second site to move to either. The recovery plan for losing the data centre was a conversation nobody wanted to have.
Changing the release and the platform at the same time
The programme was more than a version upgrade. It was a re-platform: Oracle E-Business Suite 12.2.13 on Oracle Database 19c, consolidated onto Oracle Linux on x86, with Payroll brought live alongside Financials and HRMS. The mixed Solaris-and-Linux estate was standardised onto a single supported operating system, so every node patches and behaves the same way.
The hard part was not any single step but the number of them moving together. The database jumped several major releases, from 11g Release 1 to 19c; the application moved from 12.1 to the re-architected 12.2; and the whole estate consolidated onto one operating system — each with its own migration, and all of them landing in a single cutover. That combination, rather than any one upgrade, set the shape of the cutover plan.
Designing out the single points of failure
A newer platform alone would have replaced an old single point of failure with a new one. So the target environment was built to survive losing pieces of itself. Oracle Real Application Clusters put the database on more than one node, so the loss of a server takes capacity out of the system rather than taking the system out of service. The application tier was spread across multiple nodes behind a load balancer, with shared clustered storage underneath, so user sessions are not tied to the health of any one machine.
The everyday benefit matters more than the failure case, because failures are rare and maintenance is constant. A clustered environment can be patched a node at a time. Work that previously required scheduling an outage for the entire company — and therefore required a weekend, an approval, and a queue — became work that can be done while the system stays up. Maintenance that is easy to schedule actually gets done, which is how a platform stays supported instead of drifting back out of support.
A second site, for the day nobody plans for
The last piece was the one the old environment had never had at all: somewhere else to run. A disaster recovery site was built as a full standby environment, kept continuously current by Oracle Data Guard, so the recovery position is measured in the transactions in flight rather than in the age of the last backup tape.
The distinction worth naming for anyone planning similar work: backups tell you what you can restore, and a standby site tells you what you can resume. Restoring a database of this size from backup is measured in hours during which the business is stopped; bringing up a standby that has been kept in step is measured in minutes.
Khwarizm delivered this as a subcontractor. The prime integrator held the client relationship and the commercial scope; Khwarizm owned the database and platform work — the OS consolidation and migration, the upgrade path, the clustered build, and the standby site and its replication.
The results
None of this changes what anyone at the airport sees on their screen, which is the point. The finance team raises the same purchase orders, the payroll runs on the same day, and the crews are paid whether or not a server failed overnight. What changed is the size of the accident the organisation can absorb without noticing — from none at all, to a lost server, to a lost building.