High Availability
High availability (HA) is the ability of an IT system to keep running almost without interruption even when individual components fail. It is achieved through redundancy and automatic failover, so that an ERP system reaches very high availability over an agreed period – often 99.9% or more.
High availability (HA) describes the ability of an IT system to keep delivering its service even when individual building blocks – a server, a disk, a power supply or a network connection – fail. Instead of grinding to a halt, a standby replacement component takes over the work, ideally without users noticing the fault at all. The goal is to reduce unplanned downtime so far that, over a measurement period, the system reaches very high availability – usually expressed as a percentage, for example 99.9% or 99.99%.
For an ERP system, high availability matters especially because it is the central data hub of a company: orders, stock, invoices, shipping and accounting all depend on it. If the ERP goes down, nothing can be ordered, picked or invoiced any more – every minute of standstill costs revenue and trust. High availability is the technical approach to minimising this downtime through redundancy during live operation. It must therefore be clearly distinguished from backup and from the emergency plan (disaster recovery), even though only all three together make up a robust operating concept.
At a glance
- High availability (HA) = near-uninterrupted operation despite the failure of individual components
- Core principle: redundancy plus automatic failover without manual intervention
- Measured as a percentage of availability – 99.9% allows around 8.8 hours of downtime per year
- No substitute for a backup: deleted or corrupted data is mirrored along with everything else
- In an ERP usually contractually guaranteed through an availability SLA
How high availability works: redundancy and failover
The core principle of high availability is redundancy: critical components are held multiple times, so that no single point can bring down the whole operation. These "single points of failure" are deliberately eliminated – from the dual power supply in a server through mirrored disks and multiple network paths to complete server clusters whose nodes protect one another. This is complemented by redundant data storage, in which the database is replicated synchronously to a second node so that an up-to-date state is available in an emergency.
The second building block is failover: the automatic switch to an intact component as soon as a fault is detected. A monitoring mechanism continuously checks, via so-called heartbeats, whether the active instance still responds. If the signal stops, the standby node takes over the role of the active system, usually within seconds. To distribute the load sensibly during normal operation and prevent individual nodes from being overloaded, load balancing is often used, spreading requests evenly across several servers.
Active-passive and active-active
Two basic patterns shape HA architectures. In active-passive, one node runs actively while a second stands in standby mode and only takes over on failure – simple to implement, but the reserve capacity sits idle during normal operation. In active-active, several nodes work simultaneously and share the load; if one fails, the others carry the requests further. This uses the hardware better and additionally provides scalability, but places higher demands on data synchronisation.
Measuring availability: the "nines" and what they mean
High availability is expressed as a percentage of the time a system is usable, relative to a period – usually a year. In practice people speak of "nines": 99% (two nines), 99.9% (three nines), 99.99% (four nines). Each additional nine drastically reduces the permitted downtime while at the same time increasing the technical effort and cost. The figure sounds abstract, but it is easily translated into concrete minutes of downtime.
At 99% availability, around 3.65 days of downtime per year are permitted; at 99.9% about 8.8 hours; at 99.99% only around 52 minutes; and at 99.999% ("five nines") a good 5 minutes across the whole year. The key question is what goes into the calculation: are planned maintenance windows counted, or only unplanned faults? Is availability measured at the server level or at the level of the actual application? Precisely these definitions should be recorded in an availability SLA, so that the guaranteed number is meaningful and not just marketing.
High availability in the ERP system
An ERP system is a demanding HA candidate because it consists of several layers: a database, application logic, often connected web shops and marketplaces, and numerous interfaces. High availability has to cover all these layers – a mirrored database is of little use if the only application server fails. Data consistency is particularly sensitive: during the switchover, no postings may be processed twice or not at all, which is why concepts such as idempotency play an important role in the connected processes.
How high availability is implemented and guaranteed depends heavily on the operating model. With a cloud ERP in the SaaS model, the provider runs the infrastructure redundantly in a professional data centre; the guaranteed availability is stated in the SLA, while the technical implementation usually remains invisible to the customer. With on-premise or self-hosting, the company has to plan, run and finance the HA architecture itself – from the cluster software through redundant network connectivity to an uninterruptible power supply.
Distinction: high availability vs. backup vs. disaster recovery
These three terms are often confused but cover different risks. High availability protects against the failure of individual components during live operation and keeps the service running seamlessly. A backup protects against data loss and makes it possible to restore an earlier state – something HA specifically does not do, because a record deleted by mistake or encrypted by ransomware is immediately mirrored to all redundant nodes. Disaster recovery, in turn, is the comprehensive emergency plan for large-scale outages, such as the loss of an entire data centre, with metrics like RPO and RTO. Only together do the three make up a viable operating concept.
Why high availability matters economically
The cost of an ERP outage is rarely obvious but quickly substantial. An online retailer cannot accept orders or ship goods during the standstill; in B2B trade, orders are delayed, delivery commitments fall through, and in manufacturing the entire production may come to a halt. On top of this come indirect consequences: annoyed customers, contractual penalties for guaranteed delivery dates and reputational damage. Against these potential costs stands the effort for redundant infrastructure – investing in high availability is ultimately a trade-off between the risk of failure and the cost of protection.
That is why high availability is not a purely technical question but a business decision. Not every system needs five nines: for internal reporting, an outage of several hours may be tolerable, whereas a customer-facing ordering process must run almost without interruption. The sensible approach is to determine the maximum tolerable outage per process and to align the architecture – and the associated SLA – with it, rather than demanding the highest availability level across the board.
DACH specifics and legal framework
In German-speaking countries, regulatory and location-related aspects also come into play with high availability. Many companies value data residency in data centres within the EU or specifically in Germany, Austria or Switzerland – partly for compliance reasons, partly out of trust in the local jurisdiction. For assessing data centres and HA concepts, reference points such as the Tier classification of the Uptime Institute and the recommendations of the BSI in its IT-Grundschutz have become established.
In addition: the GDPR gives rise to the requirement to process personal data in an available and resilient manner – availability is thus explicitly part of the technical protection measures. In more heavily regulated industries, further requirements may apply. For most mid-sized companies, however, the decisive lever is more pragmatic: a cleanly worded availability SLA with the ERP or hosting provider that unambiguously governs the measurement method, maintenance windows and response times.
Example
Example: failover at an online retailer during peak season
A mid-sized online retailer runs its ERP as a cloud solution with a guaranteed 99.9% availability. The architecture is set up as an active-active cluster with two application nodes and a synchronously replicated database, fronted by a load balancer. On a high-revenue promotional day, one of the two servers fails due to a hardware defect.
Via the missing heartbeats, the load balancer detects within seconds that the node no longer responds and redirects all requests to the second node. For the customers in the shop, the ordering process remains usable throughout – the fault appears only in the operating logs. The provider swaps the hardware in the background and returns the node to the cluster. Without high availability, the same defect in the middle of peak season would have meant a sales stop of several hours – with immediate loss of revenue.
Frequently asked questions
Matching ERP systems
Related services
Sources
Questions about High Availability in your ERP project?
We advise vendor-neutrally – and implement it ourselves on request.