Cloud Exit Strategy for Marketing and Customer Data: Template and Checklist

A cloud exit strategy is a documented, tested plan for leaving a cloud or SaaS provider without losing data, identity, consent state or live campaigns. Regulators ask for one: DORA Article 28(8) requires exit strategies for ICT services supporting critical or important functions, and the EU Data Act abolishes switching charges from 12 January 2027. This guide gives a ten-section template, a worked customer data platform (CDP) and email service provider (ESP) example, and a checklist.

Who this is for: vendor-risk, security, privacy and marketing-operations leads. Part of the guides hub. Pair it with the DORA marketing-stack guide.

Why regulators ask for exit plans

Concentration and lock-in turn a vendor problem into a systemic one, so several frameworks require you to show you can leave.

What the EU Data Act changes for exit

The Data Act (Regulation (EU) 2023/2854) gives customers of data processing services switching rights that you should mirror in contracts 6:

• Written terms. Switching rights and provider duties must be in a written contract (Art. 25(1)).
• Notice and transition. Maximum notice to start switching is two months; the mandatory maximum transitional period is 30 calendar days, with provider assistance and continuity (Art. 25(2)(a), (d)).
• Exit support. The provider must support your exit strategy and give an exhaustive list of exportable data and digital assets (Art. 25(2)(b), (e)).
• Retrieval and erasure. At least 30 days to retrieve data, then full erasure (Art. 25(2)(g), (h)).
• Charges. Reduced, cost-based switching charges were allowed from 11 January 2024; from 12 January 2027 none may be imposed (Art. 29).
• Formats. Where no standards exist, providers must export exportable data in a structured, commonly used, machine-readable format on request (Art. 30(5)).

Do not read this as "egress becomes free". Whether a particular SaaS product is a data processing service, how multi-cloud traffic is treated, and the Digital Omnibus proposal to carve out custom services are all unsettled 78. The 30-day period is also not a project plan: an identity and consent migration with a parallel run usually needs the old service live for longer, so write the continued-service period into the contract. Details in EU Data Act and cloud switching.

The ten-section cloud exit strategy template (downloadable outline)

Copy the block below into your document system. Square brackets are fields to fill. Section 3 is the one most plans omit: for a customer data platform, the identity graph and consent state are the assets, not just the raw events. See identity resolution and consent withdrawal architecture.

# Cloud exit plan: [service] ([provider])
Owner: [role] | Version: [x.y] | Last tested: [date] | Next test: [date]
Classification: [critical or important function? yes/no; basis]

## 1. Scope and triggers
- In scope: services, environments, contracts, DPAs, sub-processors: [list]
- Scenarios: planned switch; provider failure or insolvency; service degradation;
  regulatory or sanctions event; change of control; price or terms change
- Trigger indicators and thresholds (SLA misses, incidents, sub-processor
  notices, notice of acquisition): [list]
- Who may invoke the plan, and who approves: [roles]

## 2. Data inventory and formats
| Data set | Volume | Export format | Export method | Frequency | Last verified restore |
(profiles, events, traits, audiences, templates, journeys, suppression lists,
configuration, logs and audit trail)

## 3. Identity graph and consent export
- Identifier crosswalk; merge history and match rules; survivorship rules
- Consent and suppression records: status, timestamp, source, purpose, legal basis
- Reconciliation test: record counts, sampled profiles, consent parity = 100%

## 4. Destination re-pointing
- Inventory of sources and destinations (SDKs, server-side, webhooks, ESP, ads,
  CRM): owner, credentials, endpoint or DNS change, sequence, fallback

## 5. Parallel run
- Dual write and event replay window; shadow sends; comparison metrics;
  go/no-go criteria; rollback steps

## 6. Timeline
- Notice period; transition period; retrieval period; erasure confirmation;
  critical path; freeze windows (peak season, regulatory filings)

## 7. Roles (RACI)
- Plan owner; vendor manager; data engineering; security; DPO; marketing
  operations; legal; supplier contact: [names, deputies]

## 8. Costs
- Switching or egress charges; dual running; migration labour; licence overlap;
  contingency; approved budget: [amounts]

## 9. Testing and review
- Tabletop [frequency]; technical restore test [frequency]; full rehearsal
  [frequency]; review on material change; evidence retained: [location]

## 10. Legal and contractual clauses
- Termination rights and notice; continued-service period; data return in an
  open format; assistance at fixed or no cost; deletion certificate;
  sub-processor flow-down; audit rights; liability: [clause references]

## Sign-off and evidence log
- Approvals: [names, dates]; test results: [links]

For clause wording and architecture patterns that make this plan cheap to execute, see vendor lock-in clauses; for the migration itself, the 90-day plan for migrating off a SaaS CDP.

What each level of testing proves

Frequency should follow criticality; DORA and the technical standard call for plans that are sufficiently tested and periodically reviewed, not for a fixed interval 12.

Make exit cheap by design

The cheapest exit is the one you have already half-built. Keep a copy of raw events in storage you control, hold the identity crosswalk and consent ledger in your own database or warehouse with a nightly export, use first-party collection endpoints so re-pointing is a DNS change rather than an SDK release, and document schemas in an open format. The vendor lock-in clause checklist covers the contract side of the same ideas.

Common mistakes

• Testing the export once, at contract signature, and never again.
• Exporting events but not merge history, so identities cannot be rebuilt.
• Omitting suppression and opt-out records, or losing their timestamps and sources.
• Forgetting the destination inventory, so a cutover silently breaks ad, CRM or ESP feeds.
• Costing the exit without dual-running and labour.
• Relying on vendor goodwill instead of contract terms and your own copies.

Worked example: a customer data platform and an email service provider

This is a hypothetical illustration; every figure is invented to show the shape of a plan.

Situation. A regional EU bank runs a SaaS customer data platform and a SaaS email service provider. Regulated notices are sent through the ESP, so the bank classifies both as supporting an important function. The CDP vendor announces an acquisition and a new sub-processor outside the EU. The bank's trigger indicators (section 1) fire.

Two details decide success. Consent parity must be exactly 100% before cutover, because a missed opt-out is a compliance incident, not a defect. And the ESP exit is mostly about reputation and authentication, not data: plan sending-domain and IP warm-up separately from the CDP move.

Cloud exit readiness checklist

• Every service has an owner, a classification and a written exit plan.
• Exit scenarios and trigger indicators are defined and monitored.
• A full export of data, identity graph, merge history and consent state has been restored in a sandbox within the last 12 months.
• Export formats are open and documented; no step needs vendor staff.
• Contracts contain termination rights, a continued-service period, data return and deletion certificate.
• Destinations and sources are inventoried with owners and re-pointing steps.
• Costs of exit (charges, dual running, labour) are estimated and budgeted.
• Parallel-run and rollback criteria are written down.
• Testing cadence is set and evidence is stored.
• The register of information is current (see the martech vendor register worksheet).

---