# Hybrid and Multicloud Architecture: [Organisation or platform name]

> Architecture document for running workloads across on-premises data
> centres, edge sites and more than one public cloud: drivers and
> principles, the hybrid and multicloud patterns chosen, workload
> placement criteria and decisions, connectivity, identity federation,
> the management and control plane, data placement and portability,
> consistent security, observability, cost, resilience and an exit
> strategy. Pattern names follow the Google Cloud Architecture Center
> hybrid and multicloud patterns; the exit strategy section reflects the
> cloud switching rules in Chapter VI of Regulation (EU) 2023/2854 (the
> Data Act, applicable from 12 September 2025) and its Article 34 on
> in-parallel use. Replace every
> `[bracketed]` value and every row marked *Example*; the examples
> follow a retailer with two data centres, a primary public cloud and a
> second provider for analytics. This is a documentation format, not
> legal advice.

<!--
Guidance: How to use this template
- Write one document per organisation or major platform. It sets the
  rules for where workloads run and how environments connect; it does
  not design each workload.
- Start with drivers (section 1). Multicloud for its own sake adds cost
  and operational load; every environment in scope needs a named driver.
- Settle placement criteria (section 4) before connectivity and
  tooling, because placement decides traffic flows and skills.
- The network detail belongs in the Network Architecture Design
  (`architecture/network-architecture-design`); each provider's
  foundation belongs in its Landing Zone Design
  (`architecture/landing-zone-design`).
- Related documents: Cloud Adoption Strategy
  (`architecture/cloud-adoption-strategy`), Zero Trust Architecture
  Plan (`security/zero-trust-architecture`), Resilience Tiering and
  HA/DR Design (`architecture/resilience-tiering-ha-dr-design`),
  Application Migration Assessment
  (`architecture/application-migration-assessment`), FinOps Cost Review
  (`ops/finops-cost-review`).
-->

## Document control

<!-- Guidance: Identify the environments in scope and who owns the cross-environment platform. Adding or removing an environment is a new major version. -->

| Field | Value |
|---|---|
| Document ID | [HMA-001] |
| Environments in scope | [Data centre A], [Data centre B], [Provider 1], [Provider 2], [Edge sites] |
| Primary cloud provider | [Provider 1] |
| Version | [0.1] |
| Status | [Draft / In review / Approved / Superseded] |
| Owner | [@chief-architect] |
| Approvers/reviewers | [@cio], [@ciso], [@platform-lead], [@network-lead], [@finops-lead], [@legal-counsel] |
| Classification | [Internal / Confidential] |
| Last updated | YYYY-MM-DD |
| Next review | YYYY-MM-DD |
| Related documents | [Cloud adoption strategy], [Landing zone designs], [Network architecture design] |

### Approvals

| Role | Name | Decision | Date |
|---|---|---|---|
| Executive sponsor | [@name] | [Approve / Approve with conditions / Reject] | YYYY-MM-DD |
| Enterprise architecture | [@name] | [Decision] | YYYY-MM-DD |
| Security | [@name] | [Decision] | YYYY-MM-DD |
| Platform and operations | [@name] | [Decision] | YYYY-MM-DD |
| Legal and procurement | [@name] | [Decision] | YYYY-MM-DD |

### Revision history

| Version | Date | Author | Change summary |
|---|---|---|---|
| 0.1 | YYYY-MM-DD | [@name] | First draft |
| 1.0 | YYYY-MM-DD | [@name] | *Example:* Approved: Provider 1 primary, Provider 2 for analytics, data centre B retained for manufacturing systems |
| 1.1 | YYYY-MM-DD | [@name] | *Example:* Exit plans added for Tier 1 workloads after contract renewal |

## Contents

<!-- Guidance: Keep this list aligned with the headings. -->

1. [Drivers, scope and principles](#1-drivers-scope-and-principles)
2. [Current estate](#2-current-estate)
3. [Patterns chosen](#3-patterns-chosen)
4. [Workload placement](#4-workload-placement)
5. [Connectivity between environments](#5-connectivity-between-environments)
6. [Identity and access federation](#6-identity-and-access-federation)
7. [Management and control plane](#7-management-and-control-plane)
8. [Data placement, sovereignty and portability](#8-data-placement-sovereignty-and-portability)
9. [Security consistency](#9-security-consistency)
10. [Observability and operations](#10-observability-and-operations)
11. [Cost management](#11-cost-management)
12. [Resilience across environments](#12-resilience-across-environments)
13. [Exit strategy and switching](#13-exit-strategy-and-switching)
14. [Roadmap, risks and decisions](#14-roadmap-risks-and-decisions)
15. [Glossary and references](#15-glossary-and-references)

## 1. Drivers, scope and principles

<!-- Guidance: Name the business reason for each environment. Questions: is the second cloud for capability, resilience, regulation, negotiation leverage or acquisition history? Pitfall: "avoid lock-in" as the only driver, with no measure of what lock-in would cost. -->

### 1.1 Drivers

| ID | Driver | Environments it justifies | Measure of success |
|---|---|---|---|
| DRV-001 *(Example)* | Manufacturing systems need sub-10 ms latency to plant equipment | Data centre B, edge sites | Control loops stay on site; no plant outage from WAN loss |
| DRV-002 *(Example)* | Analytics team depends on a data warehouse service only available on Provider 2 | Provider 2 | Analytics workloads delivered, egress cost within budget |
| DRV-003 *(Example)* | Regulator expects a credible exit plan for critical outsourced services | Provider 1 and 2 | Exit plan tested yearly for Tier 1 workloads |
| DRV-004 *(Example)* | Data centre A lease ends YYYY-MM-DD | Provider 1 | Data centre A empty by lease end |
| DRV-005 *(Example)* | Acquired subsidiary runs on Provider 2 | Provider 2 | Integrated identity and security within 12 months |
| [DRV-NNN] | [Driver] | [Environments] | [Measure] |

### 1.2 Scope

| In scope | Out of scope |
|---|---|
| *Example:* All production and non-production workloads, edge sites, both data centres, both providers | End-user devices and SaaS used only through a browser |
| *Example:* Cross-environment network, identity, security, observability, cost | Detailed design of individual workloads |
| [Item] | [Item] |

### 1.3 Principles

| ID | Principle | Consequence |
|---|---|---|
| HMP-001 *(Example)* | One primary cloud; a second provider only with an approved driver | New workloads default to Provider 1; exceptions go to the architecture board |
| HMP-002 *(Example)* | A workload runs in one environment unless its resilience tier requires more | Cross-environment active-active is the exception, not the norm |
| HMP-003 *(Example)* | Identity, policy and telemetry are consistent everywhere | One identity provider, one policy catalogue, one observability backend |
| HMP-004 *(Example)* | Portability is designed where its cost is justified | Tier 1 workloads keep portable data formats and infrastructure as code; others accept provider services |
| HMP-005 *(Example)* | Data stays where it is mastered; analytics copies are governed | Every cross-environment copy has an owner, a purpose and a retention period |
| [HMP-NNN] | [Principle] | [Consequence] |

## 2. Current estate

<!-- Guidance: Summarise what runs where today, with numbers. Pitfall: forgetting shadow cloud accounts created by business units. -->

| Environment | Role today | Workloads | Compute footprint | Data held | Contract or lease end |
|---|---|---|---|---|---|
| Data centre A *(Example)* | General purpose, being vacated | 180 | 1,400 VMs | 900 TB | YYYY-MM-DD |
| Data centre B *(Example)* | Manufacturing, retained | 45 | 300 VMs, 20 physical | 250 TB | Owned site |
| Edge sites *(Example)* | 12 plants, local control and buffering | 12 stacks | 3 nodes per site | 2 TB per site | Not applicable |
| Provider 1 *(Example)* | Primary cloud | 120 | 1,100 VMs, 14 Kubernetes clusters | 600 TB | Commitment ends YYYY-MM-DD |
| Provider 2 *(Example)* | Analytics, acquired subsidiary | 30 | 4 Kubernetes clusters, warehouse | 400 TB | Commitment ends YYYY-MM-DD |
| [Environment] | [Role] | [Count] | [Footprint] | [Data] | [Date] |

## 3. Patterns chosen

<!-- Guidance: Name the patterns you use and where. Use one vocabulary so that teams compare like with like. Pitfall: an estate that uses every pattern at once without saying which applies to which workloads. -->

The Google Cloud Architecture Center groups hybrid and multicloud
architecture patterns into distributed patterns (tiered hybrid,
partitioned multicloud, analytics hybrid and multicloud, edge hybrid)
and redundant patterns (environment hybrid, business continuity hybrid
and multicloud, cloud bursting), with networking patterns (mirrored,
meshed, gated egress, gated ingress, gated egress and ingress,
handover). The table records which ones this organisation uses. The
pattern names are a shared vocabulary; the decisions are yours.

| Pattern | Used | Where | Reason | Networking pattern |
|---|---|---|---|---|
| Tiered hybrid *(Example)* | Yes | Customer web front ends in Provider 1, order back ends in data centre A until migrated | Move user-facing tiers first | Gated egress from cloud to data centre |
| Partitioned multicloud *(Example)* | Yes, limited | Subsidiary workloads on Provider 2 | Acquisition history, DRV-005 | Gated ingress and egress between providers |
| Analytics hybrid and multicloud *(Example)* | Yes | Operational data from Provider 1 and data centre B fed to the Provider 2 warehouse | DRV-002 | Handover (data pushed through managed transfer) |
| Edge hybrid *(Example)* | Yes | Plant control at edge sites, central management in Provider 1 | DRV-001 | Gated egress from edge |
| Environment hybrid *(Example)* | No | Not used: test and production share an environment per workload | Avoid drift between environments | Not applicable |
| Business continuity hybrid and multicloud *(Example)* | Selective | Two Tier 1 workloads keep a recovery copy in data centre B | DRV-003 | Meshed (routed recovery network, no mirrored ranges) |
| Cloud bursting *(Example)* | No | Not justified by demand profile | Licence and data gravity costs exceed benefit | Not applicable |
| [Pattern] | [Yes / No] | [Where] | [Reason] | [Networking pattern] |

```mermaid
flowchart LR
  subgraph DCB[Data centre B]
    MES[Manufacturing systems]
    REC[Recovery copies, Tier 1]
  end
  subgraph EDGE[Edge sites x12]
    CTRL[Plant control and buffer]
  end
  subgraph P1[Provider 1, primary]
    WEB[Customer front ends]
    CORE[Core business services]
    MGMT[Central management and observability]
  end
  subgraph P2[Provider 2]
    DWH[Analytics warehouse]
    SUB[Subsidiary workloads]
  end
  CTRL -->|gated egress| MGMT
  WEB --> CORE
  CORE -->|private link| MES
  CORE -->|managed transfer| DWH
  MES -->|managed transfer| DWH
  SUB <-->|gated ingress and egress| CORE
  CORE -. recovery replication .-> REC
```

## 4. Workload placement

<!-- Guidance: Make placement a repeatable decision with criteria, not a negotiation per project. Questions: which criteria are hard constraints and which are weighted preferences? Who decides ties? Pitfall: criteria that every environment satisfies equally, so they decide nothing. -->

### 4.1 Hard constraints

A workload must run where every hard constraint is met. If no
environment meets them all, the conflict goes to the architecture board.

| ID | Constraint | Test |
|---|---|---|
| PLC-H01 *(Example)* | Data residency: personal data of [country] residents stays in [jurisdiction] | Region list of the environment |
| PLC-H02 *(Example)* | Latency to plant equipment under 10 ms | Measured round trip |
| PLC-H03 *(Example)* | Regulated workloads only in environments with the required certification | Provider attestation register |
| PLC-H04 *(Example)* | Hardware dependency (dongles, special adapters, non-x86) | Inventory |
| [PLC-HNN] | [Constraint] | [Test] |

### 4.2 Weighted criteria

| ID | Criterion | Weight | Scoring guide |
|---|---|---|---|
| PLC-W01 *(Example)* | Proximity to the data the workload reads most (data gravity) | 25 % | 5 when the main data set is in the same environment |
| PLC-W02 *(Example)* | Fit of managed services to the workload | 20 % | 5 when a managed service removes a component the team runs today |
| PLC-W03 *(Example)* | Team skills and support model | 15 % | 5 when the owning team already operates in that environment |
| PLC-W04 *(Example)* | Run cost including egress | 20 % | From the TCO model |
| PLC-W05 *(Example)* | Resilience tier fit | 10 % | 5 when the environment supports the tier pattern natively |
| PLC-W06 *(Example)* | Exit cost (portability) | 10 % | 5 when the workload uses portable formats and open interfaces |
| [PLC-WNN] | [Criterion] | [Weight] | [Guide] |

### 4.3 Placement decisions

| Workload | Hard constraints met in | Weighted score (P1 / P2 / DC B) | Placement | Decision ID |
|---|---|---|---|---|
| Customer web shop *(Example)* | P1, P2 | 4.3 / 3.6 / not eligible | Provider 1 | PLD-001 |
| Order management *(Example)* | P1, P2, DC B | 4.1 / 3.2 / 3.4 | Provider 1 (after migration) | PLD-002 |
| Manufacturing execution *(Example)* | DC B only (PLC-H02) | Not scored | Data centre B | PLD-003 |
| Sales analytics *(Example)* | P1, P2 | 3.5 / 4.3 / not eligible | Provider 2 | PLD-004 |
| [Workload] | [Environments] | [Scores] | [Placement] | [PLD-NNN] |

*Example calculation for PLD-004 on Provider 2:* data gravity 5 x 0.25
= 1.25, managed services 5 x 0.20 = 1.00, skills 5 x 0.15 = 0.75, cost
3 x 0.20 = 0.60, resilience 4 x 0.10 = 0.40, exit cost 3 x 0.10 = 0.30;
total 4.30. Weights add up to 100 %, so the maximum score is 5.00.
Recompute every score whenever a weight or input changes.

## 5. Connectivity between environments

<!-- Guidance: Summarise the cross-environment links and the rules that govern them; keep detailed routing in the network design. Pitfall: provider-to-provider traffic hairpinning through a data centre that is being closed. -->

| Link ID | Between | Type | Capacity | Resilience | Traffic allowed |
|---|---|---|---|---|---|
| HCN-001 *(Example)* | Data centre B and Provider 1 | Dedicated private connectivity at two locations | 2 x 10 Gbit/s | Maximum resiliency model of the provider | Business services, recovery replication |
| HCN-002 *(Example)* | Data centre B and Provider 2 | Partner interconnect | 2 x 1 Gbit/s | Two locations | Data transfer to the warehouse |
| HCN-003 *(Example)* | Provider 1 and Provider 2 | Private interconnect between providers (colocation exchange, or a provider product such as Google Cross-Cloud Interconnect) | 2 x 10 Gbit/s | Two metros | Analytics feeds, subsidiary integration |
| HCN-004 *(Example)* | Edge sites and Provider 1 | SD-WAN over internet with IPsec | 200 Mbit/s per site | Dual ISP per site | Telemetry, management, updates |
| [HCN-NNN] | [Between] | [Type] | [Capacity] | [Resilience] | [Traffic] |

Rules: no environment acts as transit for two others unless the
network design says so; address space is unique across all
environments (one IP plan, managed in one IPAM); name resolution across
environments follows the hybrid DNS design in the network document.

## 6. Identity and access federation

<!-- Guidance: One workforce identity everywhere, short-lived credentials for machines. Questions: which provider is authoritative? How do workloads in one cloud call services in another without static keys? Pitfall: separate local admin accounts in each cloud, never reviewed. -->

| Decision | Choice |
|---|---|
| Workforce identity provider *(Example)* | Corporate identity provider, federated to every cloud and to data centre management tools |
| Provisioning *(Example)* | Automated user and group provisioning to each provider; no manual cloud users |
| Privileged access *(Example)* | Just-in-time elevation, phishing-resistant MFA, session recording for data centre consoles |
| Workload identity across clouds *(Example)* | Workload identity federation using OpenID Connect tokens; no long-lived access keys between providers |
| Kubernetes identity *(Example)* | Cluster workloads use provider workload identity; cross-cluster calls use service mesh certificates from one internal CA |
| Subsidiary directory *(Example)* | Trust established during integration; merged within 12 months (DRV-005) |
| Break-glass *(Example)* | Per provider, as in each landing zone design |

## 7. Management and control plane

<!-- Guidance: Decide which tools manage which environments and where the single view lives. Questions: one tool across all, or native tools with a common reporting layer? Pitfall: a "single pane of glass" project that duplicates every native console and is never finished. -->

| Capability | Approach | Tool category | Environments covered |
|---|---|---|---|
| Infrastructure as code *(Example)* | One language and module registry, provider-specific modules | Terraform or OpenTofu | All |
| Configuration and policy *(Example)* | Policy as code with a shared catalogue, enforced natively per provider | Provider policy engines plus an open policy engine in pipelines | All |
| Server and Kubernetes management *(Example)* | Project non-native servers and clusters into the primary provider's management plane | For example Azure Arc for servers, Kubernetes and SQL Server outside Azure, or the equivalent of the chosen provider | DC B, edge, Provider 2 clusters |
| Kubernetes fleet *(Example)* | GitOps with one repository structure per cluster group | GitOps controller | All clusters |
| Inventory and CMDB *(Example)* | Discovery feeds from every environment into one CMDB | CMDB with cloud connectors | All |
| Patch and vulnerability *(Example)* | One scanner, native patch tools | Vulnerability management | All |
| [Capability] | [Approach] | [Tool] | [Coverage] |

If you use a provider's management plane for resources outside that
provider, record the dependency it creates: an outage or exit of that
provider affects management of the others. Section 13 covers this.

## 8. Data placement, sovereignty and portability

<!-- Guidance: Data is the hardest thing to move and the most regulated. Questions: where is each data domain mastered? Which copies exist and why? What format would you export it in? Pitfall: analytics copies that become a second system of record without anyone deciding it. -->

| Data domain | Master location | Copies (location, purpose) | Residency rule | Export format and method | Owner |
|---|---|---|---|---|---|
| Customer *(Example)* | Provider 1, [region] | Provider 2 warehouse, pseudonymised, analytics | EU only | Parquet via managed transfer; database dump in open format | @customer-data-owner |
| Orders *(Example)* | Provider 1 after migration | Provider 2 warehouse, analytics; DC B recovery copy | EU only | Same | @order-data-owner |
| Production telemetry *(Example)* | Edge sites, buffered 7 days | Provider 1 time-series store | None beyond contract | Open time-series export | @plant-data-owner |
| Product master *(Example)* | Data centre B | Provider 1 read replica | None | CSV and JSON exports, documented schema | @product-data-owner |
| [Domain] | [Location] | [Copies] | [Rule] | [Format] | [@owner] |

Keep data residency, transfer mechanisms and records of processing
consistent with the data protection assessments for each domain.
Favour open formats and documented schemas for any data you might need
to move; a proprietary format with no export path is an exit cost.

## 9. Security consistency

<!-- Guidance: Same control outcomes everywhere, implemented with native tools where that is stronger. Pitfall: lowest-common-denominator controls chosen because one environment cannot do better. -->

| Control area | Common requirement | Provider 1 | Provider 2 | Data centres and edge |
|---|---|---|---|---|
| Posture management *(Example)* | Continuous misconfiguration detection against one benchmark set | Native posture service | Native posture service | Agent-based scanner |
| Threat detection *(Example)* | Findings in one security operations platform within 15 minutes | Native, forwarded | Native, forwarded | Network and host sensors, forwarded |
| Encryption *(Example)* | Encryption at rest and in transit; customer-managed keys for confidential data | Provider key service | Provider key service | Hardware security modules |
| Network policy *(Example)* | Default deny between segments, see zero trust plan | Native firewall and security groups | Same | Data centre firewalls, micro-segmentation agents |
| Secrets *(Example)* | No secrets in code; short-lived where possible | Provider secret store | Provider secret store | Central vault |
| Logging *(Example)* | Security logs retained [1 year] in an immutable store outside the source environment | Forwarded | Forwarded | Forwarded |
| [Area] | [Requirement] | [Provider 1] | [Provider 2] | [On premises] |

Map these controls to the Zero Trust Architecture Plan
(`security/zero-trust-architecture`) and to the Security Architecture
(`security/security-architecture`).

## 10. Observability and operations

<!-- Guidance: One way to see and run everything, even if the agents differ. Pitfall: each environment has its own on-call rota and runbooks, so cross-environment incidents have no owner. -->

| Item | Design |
|---|---|
| Telemetry standard *(Example)* | OpenTelemetry for traces and metrics where supported; logs in a common schema |
| Backend *(Example)* | One observability platform hosted in Provider 1, with a buffer at each edge site |
| Service map *(Example)* | Cross-environment dependencies shown for every Tier 1 service |
| Incident management *(Example)* | One incident process and on-call rota per service, not per environment |
| Provider health *(Example)* | Provider status feeds and service health alerts routed to the platform on-call |
| Runbooks *(Example)* | Each runbook states which environment it applies to and the escalation path to the provider |
| Capacity *(Example)* | Quarterly review per environment, see Capacity Plan (`ops/capacity-plan`) |

## 11. Cost management

<!-- Guidance: Multicloud cost is mostly in data transfer, duplicated tooling and skills. Make those visible. Pitfall: comparing compute prices between providers and ignoring egress. -->

| Cost element | Measure | Example value | Control |
|---|---|---|---|
| Inter-environment data transfer *(Example)* | TB per month by link | 120 TB per month on HCN-003 | Transfer budget per data product; compress and filter at source |
| Duplicated platform tooling *(Example)* | Annual licence and run cost per environment | [Value] | Prefer tools that cover all environments |
| Skills and staffing *(Example)* | FTE per environment | [Value] | Training plan, shared platform team |
| Committed spend *(Example)* | Commitment use per provider | [Value] | Quarterly review; avoid commitments that block exit |
| Unit cost *(Example)* | Cost per order, per analytics query | [Value] | FinOps reporting in one format across providers |

*Example:* at 120 TB per month across HCN-003 and an assumed blended
transfer price of USD 0.02 per GB, transfer costs 120,000 GB x 0.02 =
USD 2,400 per month, USD 28,800 per year. Use your contracted prices.
Report costs in a common schema across providers (for example FOCUS 1.4,
the FinOps Open Cost and Usage Specification, ratified 2026-06-04, using
columns such as BilledCost, EffectiveCost, ServiceCategory and
ServiceProviderName) and review them in the FinOps Cost
Review (`ops/finops-cost-review`).

## 12. Resilience across environments

<!-- Guidance: Use a second environment for resilience only where the tier requires it and the team can operate it. Pitfall: claiming multicloud resilience for a workload whose identity provider, DNS or CI pipeline runs in one provider only. -->

| Tier | Pattern | Environments | Shared dependencies to check |
|---|---|---|---|
| Tier 1 *(Example)* | Multi-region in Provider 1; recovery copy in data centre B for two named workloads | P1 two regions, DC B | Identity provider, DNS, certificate authority, pipeline, observability |
| Tier 2 *(Example)* | Multi-zone with backup to a second region | P1 | Same |
| Tier 3 *(Example)* | Single zone, restore from backup | Any | Backup store location |

Detail recovery targets and patterns in the Resilience Tiering and HA/DR
Design (`architecture/resilience-tiering-ha-dr-design`) and test them
through the Disaster Recovery Plan (`ops/disaster-recovery-plan`).

## 13. Exit strategy and switching

<!-- Guidance: Write an exit plan per provider and per critical workload before you need it. Questions: what triggers an exit? How long would it take? What would it cost? What does the contract allow? Pitfall: an exit plan that assumes the provider stays fully available and cooperative throughout. -->

### 13.1 Exit triggers

| ID | Trigger | Response |
|---|---|---|
| EXT-T01 *(Example)* | Provider ends a service the workload depends on | Plan migration within the provider's deprecation period |
| EXT-T02 *(Example)* | Material price increase or contract dispute | Commercial negotiation, then stressed exit if unresolved |
| EXT-T03 *(Example)* | Regulator or auditor requires exit from a provider | Stressed exit within the period set by the regulator |
| EXT-T04 *(Example)* | Persistent failure to meet SLA or security obligations | Planned exit |
| [EXT-TNN] | [Trigger] | [Response] |

### 13.2 Regulatory baseline (EU Data Act)

For customers of data processing services in the EU, Chapter VI of
Regulation (EU) 2023/2854 (Articles 23 to 31) sets switching rights, and
Article 34 in Chapter VIII covers in-parallel use of several providers.
In summary (check the consolidated text on EUR-Lex for the binding
wording):

| Article | Topic | What it means for the exit plan |
|---|---|---|
| Art. 23 | Removing obstacles to switching | Providers must not hinder a customer from switching to another provider or to on-premises infrastructure |
| Art. 25 | Contract terms on switching | The contract must allow switching on a notice period of at most two months, followed by a transitional period of at most 30 calendar days (a provider may propose a longer period of up to seven months if 30 days is technically unfeasible, and the customer may extend once), and give at least 30 calendar days to retrieve data afterwards |
| Art. 26 | Provider information | The provider must describe switching procedures, data formats and known restrictions |
| Art. 29 | Switching charges | Reduced charges, capped at the provider's direct costs, are allowed until 12 January 2027; from that date no switching charges may be imposed |
| Art. 30 | Technical aspects | Infrastructure-type services must help the customer reach functional equivalence on the destination; other services must offer open interfaces and export in structured, commonly used, machine-readable formats |
| Art. 31 | Specific regime | Custom-built services and non-production testing versions are partly or fully exempt; the provider must say so before contract |
| Art. 34 (Chapter VIII) | In-parallel use | Rules on interoperability and data transfer charges when a customer uses several providers at the same time |

The Regulation applies from 12 September 2025. Article 50 gives later
or transitional dates only for Article 3(1), Chapter III and Chapter IV
(unfair contractual terms); the Chapter VI switching rules carry no
transitional period for existing contracts. Confirm with legal counsel
how each existing contract, and any later amendment to the Regulation
(for example the Commission's Digital Omnibus proposals, if adopted),
affects you.

### 13.3 Exit plan per workload

| Workload | Provider | Exit target | Portability level | Estimated duration | Estimated cost | Last tested |
|---|---|---|---|---|---|---|
| Customer web shop *(Example)* | Provider 1 | Provider 2 | High: containers, IaC, open database engine | 3 months | [Value] | YYYY-MM-DD (table-top) |
| Order management *(Example)* | Provider 1 | Data centre B (temporary), then another provider | Medium: managed PostgreSQL, provider queue service | 6 months | [Value] | YYYY-MM-DD |
| Sales analytics *(Example)* | Provider 2 | Provider 1 | Low: proprietary warehouse SQL dialect | 9 months | [Value] | Not yet tested |
| [Workload] | [Provider] | [Target] | [High / Medium / Low] | [Duration] | [Cost] | [Date] |

Each exit plan names the data export method, the services that need a
replacement, the contract steps (notice, transitional period, data
retrieval period) and the people who would run it. Test Tier 1 exit
plans at least yearly, as a table-top for the whole plan and a technical
test for the data export.

## 14. Roadmap, risks and decisions

<!-- Guidance: Show how the estate gets from today to the target, and record the decisions that shaped it. Pitfall: a roadmap that adds environments faster than the platform team can operate them. -->

### 14.1 Roadmap

| Phase | Period | Outcome |
|---|---|---|
| 1 *(Example)* | Q1 to Q2 | Identity federation and one IP plan across all environments; cross-cloud interconnect live |
| 2 *(Example)* | Q2 to Q4 | Data centre A migrated to Provider 1; management plane covers DC B and edge |
| 3 *(Example)* | Next year Q1 | Subsidiary integrated; exit plans tested for Tier 1 |
| [Phase] | [Period] | [Outcome] |

### 14.2 Risks

| ID | Risk | Likelihood | Impact | Response | Owner |
|---|---|---|---|---|---|
| RSK-001 *(Example)* | Skills spread too thin across two providers | High | Medium | Primary-provider default (HMP-001), shared platform team | @platform-lead |
| RSK-002 *(Example)* | Egress costs exceed budget as analytics grows | Medium | Medium | Transfer budgets, filtering at source | @finops-lead |
| RSK-003 *(Example)* | Management plane depends on Provider 1 | Medium | High | Documented in section 7; native tools remain usable | @chief-architect |
| RSK-004 *(Example)* | Exit plan for analytics untested | Medium | High | Technical export test by YYYY-MM-DD | @analytics-lead |
| [RSK-NNN] | [Risk] | [L / M / H] | [L / M / H] | [Response] | [@owner] |

### 14.3 Decisions

| ID | Decision | Date | Record |
|---|---|---|---|
| HMD-001 *(Example)* | Provider 1 is the primary cloud | YYYY-MM-DD | Architecture Decision Log entry |
| HMD-002 *(Example)* | Provider 2 limited to analytics and the subsidiary | YYYY-MM-DD | Same |
| [HMD-NNN] | [Decision] | YYYY-MM-DD | [Link] |

Keep the decisions in the Architecture Decision Log
(`architecture/architecture-decision-log`).

## 15. Glossary and references

<!-- Guidance: Define the terms and list the sources with the date you checked them. -->

### 15.1 Glossary

| Term | Meaning |
|---|---|
| Hybrid cloud | Use of public cloud together with on-premises or edge environments as one estate |
| Multicloud | Use of more than one public cloud provider |
| Placement | Decision on which environment a workload runs in |
| Data gravity | Pull that large or latency-coupled data sets exert on the applications that use them |
| Exit plan | Documented, tested way to move a workload away from a provider |
| Switching | Moving from one data processing service to another provider or to on-premises infrastructure, in the sense of the Data Act |
| Functional equivalence | Minimum level of functionality on the destination service, in the sense of the Data Act |
| Egress | Data leaving a provider's network, usually charged |

### 15.2 References

| Reference | Version or date checked | Use |
|---|---|---|
| Regulation (EU) 2023/2854 (Data Act), OJ L, 22 December 2023, Chapter VI, Article 34 and Article 50, eur-lex.europa.eu | Applicable from 12 September 2025; check the consolidated text | Section 13 |
| European Commission, Data Act policy page, digital-strategy.ec.europa.eu | Checked YYYY-MM-DD | Application date |
| Google Cloud Architecture Center, "Hybrid and multicloud architecture patterns", docs.cloud.google.com | Page updated October 2024 | Pattern names in section 3 |
| Microsoft Learn, "Azure Arc overview" | Page dated August 2025 | Management plane example in section 7 |
| FinOps Open Cost and Usage Specification (FOCUS), focus.finops.org | Version 1.4, ratified 2026-06-04 | Cost reporting schema in section 11 |
| [Provider contracts and exit clauses] | [Date] | Section 13 |

## Standard and licence note

Based on Regulation (EU) 2023/2854 (Data Act), Chapter VI on switching
between data processing services and Article 34 on in-parallel use, with pattern names from the Google
Cloud Architecture Center hybrid and multicloud patterns. EU legislative
texts are free to reuse; the articles are summarised in original
wording and no text of the Regulation is reproduced. Provider guidance
is used for names and vocabulary only. All other text is original and
written for this collection. Check the consolidated text on EUR-Lex and
the current provider documentation before use. This is a documentation
format, not legal advice. AWS, Microsoft Azure, Azure Arc, Google Cloud
and the products named are trademarks of their owners; this template
is not affiliated with or endorsed by them. Template licence: MIT.