SAP technical managed services, database and operating system management, upgrade delivery
The environment that cannot fall back on paper
Inkosi Albert Luthuli Central Hospital in Durban is an 846-bed central referral hospital and the only public hospital in South Africa operating a fully integrated electronic patient record with financials included. It has run paperless since it opened in 2002. The SAP landscape sits at the core of that: if it stops, there is no manual process waiting underneath it. The first patient’s digital record from 2002 is still accessible today, which says everything about the continuity expected of the systems and the people who run them.
Since May 2019, ETZ Global has provided the SAP technical managed service for this landscape. The engagement was contracted by AME Africa Healthcare, the private company responsible for all information management and technology at the hospital under its public-private partnership. The scope covers the full technical stack: SAP Basis administration and monitoring, the database layer with standby replication, the operating system layer, and the virtualised infrastructure interfaces, across the full set of production and non-production systems.
What ETZ inherited
The service did not begin from a comfortable baseline. Monitoring consisted of home-grown scripts. An earlier attempt to upgrade the environment, made before ETZ’s tenure, had not succeeded, and appetite for change was understandably low. In a hospital, a failed upgrade is not an inconvenience; it is a reason to stop upgrading altogether, which over time creates exactly the risk it was trying to avoid: an ageing, unpatched landscape drifting out of vendor support.
The first order of business was therefore not an upgrade at all. It was establishing proper centralised monitoring and alerting, documented operational procedures, monthly reporting with technical indicators, and a working rhythm of EarlyWatch analysis and remediation. Change came after trust.
Modernising through structured upgrade pathways
Over the following years the landscape was brought fully current, one carefully rehearsed step at a time. The database platform was upgraded to a current long-term release ahead of its vendor support deadline. The SAP application layer moved through successive support package upgrades. Kernels were upgraded twice a year across the entire landscape. The central monitoring platform was upgraded in step. The operating systems and the virtualisation platform beneath them were patched and upgraded in coordinated cycles. Every one of these lifecycle events landed inside its agreed window: no incident, no late delivery, no unplanned outage.
The pattern for every one of these was the same and was non-negotiable. Each upgrade was first run end to end on a sandbox copy, where issues could be found and fixed with no clock running. It then moved to development and quality assurance under a change freeze, with a full functional testing window before production was touched. One representative major application upgrade shows the tempo: from development, to quality assurance two weeks later, through a further two-week functional testing window, to production go-live exactly four weeks after the first system was touched, on schedule, with functional testing signed off without issues. ETZ coordinated the functional testing effort alongside the technical work, so that sign-off meant business processes had actually been exercised, not just that systems started.
The environment that had once had a failed upgrade in its history completed every upgrade under the new service successfully, first time.
The operational record
Across more than seven years of continuous service, not one Severity 1 incident was raised against the service, against a service level that demands a fifteen-minute response and two-hour resolution for exactly that scenario. No unplanned SAP downtime originated from the managed service. Monthly reporting recorded 100 percent SAP application availability month after month, with planned maintenance confined to agreed downtime windows. The one brief interruption in the period was caused by a hardware component failure in the underlying infrastructure, outside the service scope, and systems were restored and verified within hours.
The service also carried the hospital through its annual external audit cycle, remediating operating system, database and SAP-layer findings each year and hardening the environment progressively, within the practical constraint that a running SAP system imposes on how far certain settings can be tightened.
Why it worked
Nothing in this story is exotic, which is the point. The service worked because unglamorous things were done consistently for seven years: real monitoring instead of hope, sandbox rehearsal instead of optimism, change freezes and testing windows instead of shortcuts, monthly reporting that showed the numbers whether they were flattering or not, and a stable team that knew the environment deeply enough to fix small things before they became large ones.
For any organisation running SAP in a setting where the system simply may not stop, the lesson is transferable. Reliability is not a property of the software. It is a property of the operating discipline wrapped around it.
Worth carrying forward
- Rebuild confidence before rebuilding systems. An environment with a failed upgrade in its past needs monitoring, reporting and small wins before it needs a big change.
- Rehearse every upgrade on a sandbox end to end, and treat that as non-negotiable rather than contingency to be cut.
- Coordinate functional testing as part of the technical upgrade, so sign-off reflects business processes, not just system starts.
- Keep the maintenance cadence even when nothing is wrong. Twice-yearly kernels and annual support packages are cheaper than one heroic catch-up.
- Report monthly with real indicators. Seven years of visible numbers is what makes a zero Severity 1 claim credible rather than anecdotal.