Disaster Recovery & Business Continuity

Agility CMS is built on Microsoft Azure's resilient infrastructure, with automated backups and multi-region recovery capability for the content platform. In a regional outage, the management platform and content APIs can be recovered to a secondary Azure region, while the static/edge delivery layer continues serving already-published content to end users (see SLA & Uptime). Backups are taken automatically and retained so that an instance can be restored to a recent point in time. The platform's recovery objectives (RTO/RPO) are defined commitments; the implementation partner remains responsible for the disaster-recovery posture of the customer's own front-end application and hosting.

Resilience model

Two distinct layers determine continuity, and they fail independently:

1. Management & content-authoring layer (Content Manager, Management/Fetch APIs, database). This is the system of record on Azure and is the focus of DR planning below.
2. Delivery layer (edge/CDN and the customer's statically generated or cached front end). Because published content is distributed to the edge and customer front ends are typically statically generated, end users can continue to be served already-published content even during an origin/management-layer event. This decoupling is central to Agility's business-continuity story.

Multi-region disaster recovery

Agility leverages Azure's regional architecture for recovery. Each instance has a primary region (the selected data region — see Data Residency & Data Regions). For disaster recovery, data and services can be recovered in a secondary Azure region.

Agility maintains defined Recovery Time Objective (RTO) and Recovery Point Objective (RPO) targets as part of its documented business-continuity and disaster-recovery program, along with a defined secondary-region recovery model. The specific recovery objectives, secondary-region pairings, and replication details are available on request — including under NDA as part of an RFP or security review. Contact Agility for the current figures.

Backup model

Agility's content is backed up automatically and can be restored to a recent point in time. Because Agility runs as a managed cloud service on Microsoft Azure, disaster recovery is concerned with data, applications, and deployments rather than physical hardware restoration.

At the content level, Agility's version history is a complementary first line of recovery: editors can restore a prior version of any content item or page themselves, which addresses everyday editorial mistakes without a platform-level restore.

Backup replication stays within the same broader regional (country) boundary — for example, an instance in Canada Central is replicated within Canada (to Canada East). This means disaster-recovery replication does not move data out of the residency boundary: Canadian data stays in Canada. (See Data Residency & Data Regions.) Specific backup retention and restore-time details are available on request (including under NDA) — contact Agility.

Failover and restore process

Agility's services run on Microsoft Azure with automated failover across multiple regions — the platform is pre-configured to redirect to a secondary region if the primary becomes unavailable, and content/API and asset delivery continue serving (cached) content throughout. In the rare case of a simultaneous multi-region outage, Agility's recovery process redeploys the service into an available region. Agility maintains a documented Business Continuity & Disaster Recovery Plan with defined activation triggers, roles, and communications, and tests disaster recovery (including backup restoration) at least annually.

Failover is transparent to customer applications: API URLs and endpoints do not change when a failover occurs, so no client-side reconfiguration is required. During an incident, Agility notifies affected customers (with regular updates) through its support channels per the BC/DR plan.

The detailed runbook, activation criteria, most recent DR test results, and recovery-time figures are available on request — including under NDA — by contacting Agility.

Business continuity during an event

Because the delivery layer is decoupled from the management layer, this is built into Agility's documented continuity procedures. Per the BC/DR plan, if the Content Manager is unavailable, customer websites, API services, and asset delivery remain unaffected — editors may be temporarily unable to log in or publish, but end users keep receiving already-published content. Likewise, during a single-region Azure event, API and asset delivery continue serving cached content while failover completes.

• Published content keeps serving. Statically generated/edge-cached front ends continue delivering the last-published content to end users even if the management layer is degraded.
• Authoring may pause. During a management-layer event, content editing/publishing may be temporarily unavailable until recovery completes; this does not affect live end-user delivery of already-published content.

This separation is why public-facing availability can remain high even during a content-platform incident — see SLA & Uptime for how this produces effective five-nines end-user availability.

Shared responsibilities

Area	Agility	Implementation partner / customer
Platform backups & multi-region recovery	✅ Automated backups; recovery of management/API layer to secondary region	—
Platform RTO/RPO	✅ Defines and meets stated objectives	Aligns its own continuity plan to these objectives
Front-end app & hosting DR	—	✅ Designs the website/app for resilience (static generation, multi-region hosting, its own CDN failover)
Content-level recovery	✅ Provides version history + platform restore	✅ Uses version history to recover from editorial mistakes; defines internal restore-request process
Incident response coordination	✅ Detects, declares, communicates platform incidents	✅ Monitors its own app; defines internal comms and runbook