SAP Integration Suite Failover at Global Scale: How a Consumer Goods Leader Made Disaster Recovery Repeatable

SAP Integration Suite failover automation

Tarento implemented OneFailover to govern synchronization, backup, failover and readiness across Cloud Integration and Edge Integration Cell. The client reports 100% availability of its integration platform across all regions, alongside less manual switchover and routine operational work. The time saved has not been quantified.

In brief

The client: A global consumer goods company with business-critical SAP integrations across many domains, tenants and runtimes
The problem: Failover depended on manual scripts and on the few people who knew them. Audit evidence from DR drills was hard to produce.
The solution: OneFailover for governed sync, backup, failover and readiness across Cloud Integration and Edge Integration Cell
The result: 100% availability of the integration platform globally, and fewer manual switchover and routine tasks
Next: Extending the same governed approach to SAP API Management and B2B integration

Why does SAP Integration Suite need its own failover process?

SAP's built-in high availability protects against failures inside one region, but cross-region failover between tenants is the customer's responsibility. Within a region, SAP runs Integration Suite across availability zones. It doesn't automatically copy integration content to a standby tenant in another region, and it doesn't switch traffic there for you.

For a company whose orders, shipments and invoices run through integration flows, that leaves three jobs with the customer:

Customer responsibility	What happens without a governed process
Keeping the standby tenant in sync	Artifacts, configuration and security material drift apart between tenants
Switching traffic during an outage	Switchover depends on scripts and the people who wrote them
Proving that DR works	Drills happen, but the evidence is scattered or missing

At global scale, each gap multiplies. More tenants means more drift. More runtimes means more switchover steps. Stricter audits mean more evidence to produce.

What problems was the client trying to solve?

The client needed failover that worked the same way across every tenant and runtime, without depending on scripts or specific people, and that produced evidence for auditors. Four drivers stood out.

Governance across many domains and tenants

Failover can't depend on whoever is on call when integration ownership is spread across many teams. The client's business-critical integrations span multiple domains and tenants. Each team owned its own flows, but an outage affects all of them at once. The company needed one governed process that runs identically whoever starts it.

Readiness across multiple tenants and Edge Integration Cell

Readiness has to hold for every tenant and every runtime, not just the main cloud tenant. The landscape includes both Cloud Integration and Edge Integration Cell, and both need predictable failover and fallback between primary and standby. A standby that's ready for cloud flows but not for edge flows still leaves part of the business down.

Repeatable evidence for DR drills

A DR drill that can't be evidenced is hard to defend in an audit, however well it went. The client works under strong audit and compliance expectations. Each drill needed a record of what was switched, when, by whom and with what result.

Less reliance on scripts and tribal knowledge

Scripts drift and knowledge leaves with people, so a failover process built on both gets weaker every year. Moving that knowledge into a governed platform makes it visible, repeatable and the same for the whole team.

How does the company run governed failover with OneFailover?

OneFailover manages failover across the company's entire global SAP Integration Suite estate, using every feature of the application, not a single module or a pilot. It keeps primary and standby environments synchronized, governed and ready, so failover is repeatable, auditable and predictable.

Capability	What it does	Which driver it addresses
Tenant and runtime management	Manages tenants across Cloud Integration and Edge Integration Cell	Multi-tenant and multi-runtime readiness
Sync and clone	Copies design-time artifacts and supported security material to the standby	Drift between tenants
Git backup and selective restore	Keeps revision history and restores individual artifacts	Recovery from bad changes, not just outages
Group-based failover and fallback	Switches defined groups of integrations together, in "Single" or "Both" deployment mode	Predictable failover without scripts
Readiness scorecards and dashboards	Shows whether each environment is ready to take over	Readiness you can check before you need it
Role-based access control and audit trail	Controls who can fail over and records every action	DR drill evidence and governance

How the two manual-versus-governed approaches compare:

Step	Script-based failover	Governed failover
Check standby readiness	Manual comparison, often skipped	Readiness scorecard, checked continuously
Sync before failover	Run scripts and hope nothing changed	Artifacts and supported security material kept in sync
Switch traffic	Operator runs a sequence of manual steps	Group-based failover in a defined mode
Fall back	Reverse the scripts, often untested	Governed fallback through the same process
Prove it to auditors	Collect logs and screenshots afterward	Audit trail recorded automatically

What should a failover readiness check cover?

A readiness check should confirm that the standby can take over now, not that it could after an hour of preparation. Before any planned failover or DR drill, a governed process should be able to answer:

Artifact parity: Are the same integration flows, versions and configurations deployed on both tenants?
Security material: Are supported credentials, certificates and keystores in place on the standby?
Backups: When was the last successful backup, and can a single artifact be restored?
Edge runtimes: Is each Edge Integration Cell runtime on the standby side healthy?
Routing: Will traffic actually reach the standby once failover starts?
Last drill: When was failover last tested, and what did the audit trail record?

If any answer is "we'd have to check," the standby isn't ready yet.

What results has governed failover delivered?

The client reports 100% availability of its integration platform globally, along with less manual switchover and routine operations work.

Availability: The integration platform stayed available across all regions.
Effort: Manual switchover and routine business-as-usual (BAU) tasks dropped. The time saved hasn't been quantified, so this case study doesn't put a number on it.
Governance: Failover now runs through one governed, audited process instead of scripts and individual expertise.

What's next: extending failover to SAP API Management and B2B

The next step is to apply the same governed approach beyond Cloud Integration, to SAP API Management and B2B integration. Both features are confirmed for use and are on the client's active rollout backlog.

That follows a pattern seen during the engagement. Once failover works reliably for integration flows, teams want the same readiness for API proxies and partner connections. An API layer or B2B channel that can't fail over becomes the next single point of failure.

Does your SAP landscape look like this?

This approach fits best where SAP Integration Suite runs business-critical operations across a large, multi-team estate. Check how many of these apply:

Multiple tenants or runtimes, including Edge Integration Cell
A cross-region or active-passive resiliency requirement
A regulated or audit-driven operating model
Frequent planned maintenance windows or DR-test obligations
Failover knowledge that lives in scripts and a few people's heads
Plans to extend failover to SAP API Management

If several apply, test your own landscape with three questions:

Can you fail over predictably across every tenant and runtime?
Can you show auditors repeatable evidence from your last DR drill?
Would your switchover still work if the person who wrote the scripts were unavailable?

How OneFailover addresses these failover challenges

OneFailover is Tarento's governed sync, backup, failover and readiness platform for SAP Integration Suite. It keeps primary and standby tenants in sync across Cloud Integration and Edge Integration Cell, switches groups of integrations through a governed process, and records every action in an audit trail. Failover then stops depending on scripts and individual expertise, and becomes a repeatable process you can show to auditors.

A standby tenant you can't prove is ready isn't a recovery plan. It's a hope.

Talk to Tarento's SAP BTP team about governed failover for SAP Integration Suite

SAP Integration Suite disaster recovery