When Temporal multi-cluster replication is worth planning for
Multi-cluster replication with global namespaces lets one Temporal namespace be replicated across two or more self-hosted clusters in different regions, so a standby region can take over when the primary region is lost. Plan for it when a self-hosted Temporal service must keep running through a regional outage and your team can operate, secure and test a second region's clusters, persistence and workers. Treat it as a deliberate cross-region disaster recovery design that you add on top of a working single-region service. A standard deployment does not turn it on, and each namespace that uses it needs its own explicit decision about replication.
The Temporal documentation describes this capability as experimental, and that status should shape the production decision more than any other single fact in this section. An experimental feature can change its configuration, operational procedures or supported combinations between releases. Confirm the current status, the server versions it applies to and the known limitations in the release notes for the exact version you plan to run. Then ask your platform owners whether that maturity level fits a production workload whose recovery time and data loss tolerances have already been agreed with the business.
Before committing, check the prerequisites that make replication possible at all. Each cluster needs its own persistence store in its region from the supported list, which includes Cassandra, PostgreSQL and MySQL, with SQLite reserved for development and testing. Advanced visibility should run on Elasticsearch or OpenSearch in each region, since the documentation recommends them for anything beyond a few workflow executions. Both clusters must reach each other over a network path your security team approves, and the services should run on hosts that are not reachable from the public internet. Record these items in a pre-build checklist so the second region does not fall behind the first.
Replication is worth its cost when the business can answer the operational questions in advance. Who decides to fail over, and on what evidence? How do workers and clients learn which cluster is active, and how quickly can they be redirected? What happens to workflows that were running in the primary region when it stopped? If your team cannot answer these questions yet, keep the design on paper until it can. If the actual requirement is only to restore workflow history after an incident, a backup and restore plan may cover it, and that choice should be made explicitly and recorded.
Security needs the same attention in both regions. If no Authorizer is configured, self-hosted Temporal uses the noopAuthorizer, which allows every API request with no authentication or access control. A second cluster doubles the endpoints that must be locked down. Mutual TLS for internode and frontend traffic, a ClaimMapper that maps identity claims to namespace roles and an Authorizer plugin must be designed and tested in the standby region before any failover drill. The remaining sections of this page cover handover, forced failover and conflict resolution, so use the questions above to decide whether to read them as a production plan or as preparation for a later decision.
Which failover approach fits each recovery goal
This table compares planned handover, forced failover and running without automated failover for self-hosted Temporal with global namespaces. Read each row against the recovery goal your business has agreed, then confirm the mechanics in the Temporal documentation for the server version you run. The main takeaway is that the approach you choose sets what the operator must do under pressure, so the test plan should be written before the first failover drill.
| Approach | When it fits | What the operator must do and what is at risk | What must be tested first |
|---|---|---|---|
| Planned handover (confirm against current Temporal docs for your server version) | The primary region is healthy and the team can schedule a window to move active traffic to the standby. | Start the handover, watch replication state and in-flight workflow tasks, and confirm workers reconnect to the new active cluster. Confirm which in-flight work continues across the switch. | Run the handover on a staging cluster with representative workflow histories and confirm worker reconnection and task continuity. |
| Forced failover (confirm against current Temporal docs for your server version) | The primary cluster is unavailable and cannot take part in a planned handover, so the business accepts the risk of unreplicated work. | Decide to fail over without the primary's cooperation, verify the standby's state, and redirect workers and clients. Confirm which replicated history may be missing or conflicting when the primary returns. | Rehearse the decision path, the standby verification steps and the return-to-primary steps, including conflict handling. |
| Running without automated failover (confirm against current Temporal docs for your server version) | Recovery goals allow a manual, human-led switch, and the team accepts an operator-driven response time. | Monitor both clusters, keep runbooks current, and own every switch decision and worker redirection. Confirm that alerting covers replication health and cluster availability. | Test the runbook end to end, including who can authorize the switch and how the on-call team reaches them. |
| Prerequisites for any approach (confirm against current Temporal docs for your server version) | Needed before any failover option is credible, because the standby must stay configured and in step with the primary. | Register the global namespace on both clusters, align server and schema versions, and secure cluster-to-cluster access. Confirm the global namespace and replication settings for your version. | Confirm the standby accepts the same namespace configuration and that cross-cluster traffic works under your network controls. |
| Production readiness (confirm maturity status in current Temporal docs) | Any approach, before production use, once the documented maturity of multi-cluster replication for your version is confirmed. | Record the documented maturity status and decide whether it is acceptable for your recovery goals and change control. Confirm the status for the version you plan to run. | Test server upgrades and failover drills on a copy of the cluster before relying on the feature in production. |
Prerequisites to settle before enabling global namespaces
Both clusters must agree on several settings before a global namespace can replicate between them. The decisions below cover server version, persistence, visibility, deployment packaging and network placement. Settle each one on both sides, then confirm it against the vendor documentation for the exact server version you plan to run.
Matching server versions and upgrade order
Both clusters should run the same Temporal Server minor version before replication is turned on, and each one should be upgraded one minor version at a time. Backward compatibility is guaranteed only between two successive minor versions, so a jump across several minors breaks the assumption replication depends on. Move each cluster to the latest patch of its current minor first, and run schema upgrades before server upgrades when the release notes call for them. Confirm the upgrade sequence for your target version in the upgrade documentation before scheduling either cluster.
Persistence store choice
Choose a persistence store from the list Temporal tests against: Cassandra 3.11, 4.0 and 5.0.4 or later, PostgreSQL 13 to 16, or MySQL 5.7 and 8.0.19 or later. SQLite is intended only for development and testing and should not back a replicated cluster. Global namespace replication runs between the two Temporal clusters, so each cluster needs its own database that your team operates and backs up. Confirm the supported versions for your server release in the persistence documentation.
Advanced visibility store
Advanced visibility powers search over workflow executions, and it is a separate store from persistence. Elasticsearch 7 and 8 and OpenSearch 2 or later are supported from Temporal Server 1.30.1, while MySQL 8.0.17 or later, PostgreSQL 12 or later and SQLite are supported from server version 1.20. Cassandra visibility was removed in 1.24. Temporal recommends Elasticsearch or OpenSearch beyond a few workflow executions, so decide early and confirm the choice matches your server version and expected volume.
Helm chart version compatibility
If you deploy with Helm charts that run each Temporal service in its own Kubernetes pods, the chart version must match the server image. Chart versions below 0.73.1 do not work with server images 1.30 and later. Pin the chart and image versions together in source control, and record which pair runs in each cluster so that a rebuild in either region produces the same release. Check the chart release notes for your chosen server version before the first deployment, because a mismatch typically appears as a failed rollout.
Network placement of services
Temporal services should run on hosts that are not reachable from the public internet, with network access limited to trusted internal networks. Plan the path between the two clusters explicitly, including frontend and internode traffic, and decide which links use mTLS with separate settings for each. If no Authorizer is configured, the default allows every API request, so access control must be in place before any endpoint is exposed. Confirm cross-cluster routing, certificate handling and port requirements in the self-hosted deployment and security documentation for your version.
How conflicts and divergence are handled during failover
The central risk in a namespace that is active in one region and replicated to another is that the two clusters can hold different histories for the same workflow. If the link between regions is partitioned, the active cluster may keep accepting workflow starts, signals, updates and completions while the standby falls behind. After a switch, the standby may lack events the old active wrote, and the old active may hold events the new one never received. The first design question is which cluster you will treat as authoritative for each workflow after the switch, and how you will identify what was lost or duplicated.
Authority works at two levels. At the namespace level, the active region is a property of the global namespace, so the operator decides which cluster accepts writes. At the workflow level, a single execution may have advanced on either side during the partition. Your runbook should answer several questions: how far behind the standby can be before you accept the loss, how you record the failover time and the last replicated position, which executions were running at that moment, and what must happen before the old region is allowed to accept writes again. Confirm with the Temporal documentation for conflict resolution how the server reconciles divergent histories in the version you run, including which events are kept, which are discarded and whether any manual step is required.
Application design determines how much a divergence costs. An activity that calls an external system may run again after a switch if its completion was lost in the partition, so activities should be idempotent. Use a stable business key, such as an order or payment identifier, and send it to the downstream system so that a repeated call can be recognized and ignored. Confirm the retry and timeout behavior documented for your SDK and language. Workflow code that changes between deployments must also be versioned, so that histories written in one region still replay deterministically on workers in the other. Before cutover, replay histories exported from the standby against the worker build you plan to run.
Turn these answers into a runbook with named owners. Decide who approves a forced failover, list the workflows that call payment, messaging or record systems, and rehearse reconciliation in a non-production environment. Record which cluster accepted writes during any partition so that the reconciliation team can compare the two sides. As an illustrative example, a payment capture activity might succeed in region A just before a partition, while the completion event never reaches region B. After the switch, the workflow may retry in region B, so the downstream payment service must reject the duplicate by key. Ask your Temporal contact for the supported procedure for your exact server version, because conflict behavior is version specific.
How to set up a two-cluster global namespace with checks
This planning outline sequences a two-cluster self-hosted Temporal setup with a global namespace, from matching server lines and stores through a planned handover and a forced failover test in a non-production namespace. Each step closes with a check you can record. Validate every command and setting against the current Temporal documentation for your server version before you run it.
Match server versions on both clusters
Your platform team confirms that both clusters run the same supported Temporal Server minor line, and that each deployment uses a Helm chart version that works with that server image. The deployment guidance notes that chart versions below 0.73.1 do not work with server images 1.30 and later, so check that combination first. Upgrade one minor version at a time, moving each cluster to the latest patch of its current minor before any further change, and read the release notes for each step. Done when both clusters report the same server version in your change record and the upgrade notes for that line have been reviewed.
Verify persistence and visibility on each cluster
Confirm that each cluster uses a persistence store and an advanced visibility store on the versions listed in the current persistence and visibility docs. SQLite is meant only for development and testing, and Elasticsearch or OpenSearch is the documented choice for anything beyond a few workflow executions. Connect to each store, start a test workflow on each cluster, and confirm it appears in that cluster's visibility results. Record the store versions for both clusters so later checks can be compared against the same baseline.
Lock down network and authentication first
Before any replication link exists, confirm that the frontend and internode traffic of both clusters is restricted to trusted internal networks and that the services are not reachable from the public internet. Review the authorization setup, because a self-hosted server with no configured Authorizer uses a default that allows every API request. Configure mTLS, the ClaimMapper and the Authorizer as the security docs describe for your version. Check by attempting an unauthenticated call from outside the trusted network, which should be refused, and then an authorized client call, which should succeed.
Configure cluster and namespace replication
Follow the replication configuration in the Temporal documentation for your server version. Define both clusters in the cluster metadata, create the namespace as global, and list both clusters as its replicas with one cluster active. Confirm the exact configuration keys and commands in the docs, and check whether any part of this setup carries an experimental status in your version. Check by describing the namespace from each cluster and confirming that both show the same replica list and the same active cluster.
Run a planned handover test
Start a small set of test workflows in a non-production namespace on the active cluster. The set should include a timer, a signal and an activity, so you can see each type of work carry across the switch. Keep workers polling during the test, then move the active role to the standby cluster in a planned handover. Check that both clusters report the new active cluster, that workers reconnect to it, and that the test workflows finish with complete histories and no unexpected repeated activity side effects. Then hand the role back and record the result.
Run a forced failover test off production
In the same non-production namespace, simulate the loss of the active cluster and force the namespace over to the standby. Before the test, confirm in the docs what replication lag means for work that was in progress, because forced failover can leave recent events that had not yet replicated. Start new workflows on the standby and watch for workers reconnecting without manual intervention. Check that new starts succeed, and compare the histories of the test workflows with what was written before the simulated loss, recording any gap.
Record results and approve production use
Document each check, including the store versions, the replication settings, the handover result, the forced failover result and any events that did not replicate. Confirm the maturity status of every feature used in the docs for your server version. Treat any experimental feature as a risk that the owners accept in writing before production use. Done when a signed test record and a runbook for handover and failover exist, the approvers have signed off, and every open issue from the tests has an owner.
Security controls that must cover both clusters
Six documented controls apply to each self-hosted Temporal cluster on its own, and each must be configured on the standby as it is on the active cluster. Several fail quietly after a failover, when a different identity source, certificate chain or network path is in use. Treat each card as both a pre-cutover check and a post-failover check.
Explicit authorizer on every cluster
If no Authorizer is configured, self-hosted Temporal uses the default noopAuthorizer, which allows every API request with no authentication or access control. A cluster rebuilt from older Helm values or a partial configuration can end up in this state without anyone noticing. Confirm that both the active and standby clusters set an Authorizer explicitly, and inspect the standby's live configuration directly. Do not assume it matches the active cluster.
Separate mTLS for internode and frontend
Temporal configures mTLS separately for internode traffic between cluster services and for frontend traffic from clients and workers. Enabling one does not secure the other, so each setting needs its own review on both clusters. For replication, confirm that the certificate authority trust, certificate names and rotation schedule allow the peer cluster's services to connect. Test that a failover does not depend on a certificate that exists only on the original cluster.
ClaimMapper and Authorizer for namespace roles
A ClaimMapper maps JWT or certificate claims to namespace roles, and the Authorizer plugin decides what each role may do. Together they determine who can start, signal or administer workflows in each namespace. The claim mapping should be identical on both clusters, and the issuer of those claims must supply the same values to workers and operators after cutover. Verify with a sample role check on the standby before traffic moves, using a test identity that mirrors a production role.
OIDC single sign-on for the Web UI
OIDC single sign-on protects the Temporal Web UI, which operators use to inspect workflow histories and manage executions during an incident. Operators need UI access to the standby cluster at the moment a failover is required, so the identity provider's client registration, redirect URIs and group mappings must cover both cluster endpoints. Confirm that a standby UI login succeeds with the same group membership during a planned drill, not for the first time during an outage.
Payload encryption through codecs
Custom codecs encrypt workflow and activity payloads, and a codec server lets the Web UI and CLI decode them for authorized users. Replicated histories remain readable only where the same codec and key material are available. Confirm that codec versions and key identifiers match across clusters, that the codec server is reachable from the failover site, and that workers can decode histories written before cutover. Record which key version protected each namespace.
Services kept off the public internet
The Temporal deployment documentation says services should run on hosts that the public internet cannot reach, with network access restricted to trusted internal networks. For two clusters, replication traffic, frontend endpoints and database connections each need a private path between regions. After a failover, check the standby's exposed ports, confirm that load balancers are internal, and verify that cross-region routes exist only for the services that require them.
Why the experimental status changes the production decision
An experimental label means the operator cannot treat multi-cluster replication as a settled contract. Compatibility guarantees are limited, so the team should assume that behavior of global namespace replication, handover and forced failover may change between releases. Before any production decision, confirm the current maturity label in the Temporal documentation for the exact server minor version you plan to run. Do not rely on a label you read months earlier, and do not assume that a feature described in one version's release notes has the same status in another. The decision is less about whether the feature works and more about whether your organization accepts the risk of a feature that Temporal itself does not yet describe as stable.
Behavior changes between releases are the risk you can manage most directly. Temporal guarantees backward compatibility only between two successive minor versions, so upgrades should move one minor version at a time, starting with the latest patch of the current minor. Schema upgrades must run before server upgrades when the release notes call for them. Keep a staging environment on the same version as production, pin the server version in your deployment, and rerun your handover and forced failover tests after every upgrade, including patch releases. Treat any change in namespace state, replication lag or task processing during those tests as a blocker until the cause is understood.
A documented fallback is the control that makes an experimental feature acceptable to operate. Write down what the fallback is: for example, the criteria for abandoning replication, the decision owner who declares it, the steps to route workers and clients to a single surviving cluster, and the checks that confirm workflow state is consistent afterward. The runbook should be rehearsed, not just written. Record who performed each rehearsal, which version was tested, what went wrong, and how long each step actually took in your environment. If a step cannot be rehearsed safely, that gap belongs in the risk register, not in a footnote.
A go or no-go review should produce a written record that a risk owner can sign. Include the maturity label checked for the chosen version and the date it was checked, the pinned server and persistence versions, the results of the most recent rehearsals, and the open issues from release notes and the Temporal GitHub repository that affect replication. Name the fallback owner and the rollback criteria. State the conditions under which the decision must be reopened, such as a planned minor upgrade, a label change, or a failed rehearsal. If the review cannot fill in these fields, the answer is no-go until the gaps are closed.
Limits to confirm for your version and environment
Multi-cluster replication depends on details that change by server version and by the stores you choose, so none of these limits should be assumed from a general description. Each card names one item to confirm, why it affects a switch, and where to check it. Confirm them against the release notes for your exact version and your environment before you commit to a design.
Persistence stores that support replication
Replication support is set per persistence store and per server version, so a store listed for general persistence does not automatically qualify for global namespace replication. Temporal persistence is tested on Cassandra 3.11, 4.0 and 5.0.4 or later, PostgreSQL 13 to 16, and MySQL 5.7 and 8.0.19 or later, with SQLite meant only for development and testing. Confirm in the persistence docs and the GitHub release notes for your server version which stores can replicate, and check that both clusters use one of them.
Visibility store on each cluster
Each cluster runs its own visibility store, and the two sides can differ. Supported options include Elasticsearch 7 and 8, OpenSearch 2 or later from Temporal Server 1.30.1, and MySQL, PostgreSQL or SQLite from 1.20, while Cassandra visibility was removed in 1.24. Record the store on each cluster, then confirm that the search attributes and list queries your operators depend on work on both sides. Check the visibility docs for your version before relying on the standby cluster for lookups.
In-flight workflows during a switch
Running workflows, pending timers and in-progress activities can behave differently during a planned handover than during a forced failover. Your design should state which work resumes, which is retried, and which needs compensation or manual repair. Confirm the documented behavior for your version in the failover docs and release notes, then test long-running workflows that span a timer and an activity retry. Record the observed outcome for each case.
Schedules and Nexus calls across a switch
Schedules and Nexus operations keep state and callbacks that are not guaranteed to follow a workflow execution in the same way. Confirm whether schedules keep their next run time, overlap and pause state after a switch, and whether Nexus endpoints and callbacks resolve on the newly active cluster. The Nexus HTTP API and callback settings depend on the server version, so check both against your release. Run a test schedule and a cross-namespace Nexus call through a switch before go-live.
Helm chart and server image alignment
The Helm chart version and the server image line must match. Helm chart versions below 0.73.1 do not work with server images 1.30 and later, so a chart that installed cleanly on an older line can fail after an image upgrade. Pin the chart version and image tag together on both clusters, record them in version control, and confirm the supported image range in the chart release notes and the self-hosted deployment docs before each upgrade.
Documented maturity of replication
Confirm the maturity label that Temporal documents for multi-cluster replication in the server version you run, and read what that label commits the project to. A feature still marked experimental can change between releases, so a production design needs a named owner, a rollback plan and a re-check at each upgrade. Check the GitHub release notes for your version and record the decision and its review date in your architecture records.
What cross-region Temporal failover costs and needs from your team
What does cross-region Temporal failover cost to build and run?
Cost comes from four components: infrastructure in two regions, persistence and visibility store sizing, testing time, and the runbook and training work that lets your operators act during an incident. Most of the build cost is one-time: design, configuration, the first planned handover test, the first forced failover test, and runbook sign-off. Recurring cost includes standby capacity in the second region, cross-region replication traffic, database and search storage growth, server upgrades, on-call time and periodic failover drills. Temporal's pricing page lists Temporal Cloud pay-as-you-go pricing starting at 50 US dollars per million actions, with separate active and retained storage rates. That figure is a useful comparison point only. Self-hosted costs sit in your cloud bills and staff time, so compare total ownership over several years, not per-action pricing. Ask any partner for a written quote that separates one-time and recurring items.
Can our in-house platform team build Temporal failover without outside help?
A team can build it in-house if it already runs a self-hosted Temporal cluster in production, has operated a production persistence database, and has managed multi-region networking and Kubernetes or your chosen deployment method. The harder parts are the failover decision process, the forced failover path, and proving that workers and clients follow the cluster you hand over to. Check whether at least two people have performed a full failover drill, whether they can allocate time for a test namespace, and whether they follow a disciplined upgrade path. Also confirm who owns the decision to fail over at 2 a.m. If several of these answers are no, a fixed-scope engagement with a written test plan can cover the gap while your team learns the procedures.
How long does cross-region Temporal setup and testing take?
Duration depends on scope, and no single figure applies to every environment. The main variables are the number of namespaces that need global replication, your choice of persistence and visibility stores, whether both regions already exist, how long network and security approvals take, and how many failover scenarios you want tested. Ask for a written schedule with separate phases for design, build, the planned handover test, the forced failover test and runbook sign-off, each with its entry and exit criteria. Engagements are normally fixed-scope at DeployOpen, so scope, deliverables and timelines are agreed in writing before work starts. Treat any timeline without named dependencies on approvals and test windows as incomplete.
What do we need to provide before a Temporal failover engagement starts?
DeployOpen works inside your infrastructure, so the engagement depends on your inputs. You will need cloud accounts or data center access in both regions, with identity roles scoped to the build, network approvals for traffic between regions and for the Temporal frontend, and a dedicated test namespace that can be failed over without touching production workloads. You also need named on-call owners who can approve changes during test windows, access to the persistence and visibility stores, a documented change process, and a decision-maker who signs off the failover procedure. Ask the partner to list these inputs in the written scope with the person responsible for each one and the date it is needed.
What usually goes wrong during cross-region Temporal failover testing?
The most common problems are version skew between regions, schema upgrades run after server upgrades instead of before them when release notes require that order, and Helm chart versions below 0.73.1 used with server images 1.30 and later. Other frequent faults include visibility stores that lag behind or are not in the planned topology, workers still polling the old cluster after handover, and certificate or namespace role mismatches. Security gaps also appear during drills: the default noopAuthorizer allows every API request if no Authorizer is configured, and Temporal's deployment guidance says services should not be reachable from the public internet. Each failure mode should have a test case, an owner and an expected result written before the drill starts.
How should we size persistence and visibility stores for two regions?
Start from the supported matrix. Temporal's persistence documentation lists tested versions of Cassandra 3.11, 4.0 and 5.0.4 or later, PostgreSQL 13 to 16, and MySQL 5.7 and 8.0.19 or later, with SQLite intended only for development and testing. For advanced visibility, the documentation lists Elasticsearch 7 and 8, and OpenSearch 2 or later from server 1.30.1, and it recommends Elasticsearch or OpenSearch for anything beyond a few workflow executions. Sizing then depends on workflow execution volume, history size, namespace retention and the search query load your operators run during an incident. Confirm how each store replicates across regions with the vendor documentation for your exact versions before committing to a topology.
Is cross-region Temporal failover mature enough for production?
Maturity depends on the specific feature and the server version you run, so check the current Temporal documentation and release notes before you decide. Confirm whether the multi-cluster replication and failover behavior you need is documented as generally available for your version, and whether any part of it is labeled experimental. If a feature is experimental, treat that as an operational risk that needs a written acceptance decision from the business owner, a tested fallback such as restoring from backups, and a clear rule for when it is not used. Ask your partner to map each component to its documented status in the written scope, so that the production decision rests on evidence rather than assumptions.
What ongoing work follows a cross-region Temporal failover build?
The build creates recurring work. Server upgrades should move one minor version at a time, to the latest patch of the current minor first, because backward compatibility is guaranteed only between two successive minor versions. Schema upgrades must run before server upgrades when the release notes call for it. Operators also need periodic failover drills, runbook updates after each upgrade, monitoring and alert reviews, certificate rotation, access reviews and capacity checks for both regions. Decide in advance who performs each task and how often. DeployOpen offers ongoing support, upgrades and continuous testing as retainers, so ask for a retainer scope alongside the build quote if you want those tasks handled after handover.
How DeployOpen scopes and delivers Temporal replication work
DeployOpen plans, builds, documents and supports Temporal multi-cluster replication and failover inside infrastructure you control. Each engagement starts with a written, fixed scope that names the clusters, regions and global namespaces it covers, and ongoing support is available as a retainer.
How we scope
- The written scope names which clusters, regions and global namespaces are in and out of the replication design.
- Scope covers the persistence, network and identity prerequisites each cluster needs before replication is enabled.
- Engagements are fixed-scope, so deliverables, timelines and acceptance criteria are agreed in writing before work starts.
How we build
- Cluster and persistence configuration is built per region, with replication settings checked against the Temporal server version in use.
- Failover runbooks cover planned handover and forced failover separately, with the steps, owners and rollback points for each.
- Conflict handling and workflow behavior during failover are tested with workflow code in a non-production replica environment first.
How we hand over
- Handover includes architecture and runbook documentation, configuration as code and the failover test records.
- Operators rehearse planned handover and forced failover with your team before the engagement closes.
- Feature maturity is confirmed against Temporal's documentation, and any experimental feature is flagged as an accepted production risk.
How we support
- Ongoing support is available as a retainer covering upgrades, configuration drift checks and failover test cycles.
- Server upgrades move one minor version at a time, and schema upgrades run first when release notes require them.
- Each upgrade is followed by a repeat of the planned handover and forced failover tests.
