Migrating Off a SaaS Customer Data Platform: A 90-Day Plan for Identity Graphs, Consent State and Destinations

A customer data platform (CDP) migration fits in 90 days if you split it into five phases: inventory and contract review (weeks 1 to 2), data contracts and schema mapping (3 to 4), identity graph and consent-state export and validation (5 to 8), destinations and dual-run (9 to 10), and cutover and decommission (11 to 12). The hard parts are anonymous identities, merged profiles, suppression lists and historical replay, not the SDK swap.

Who this is for: teams leaving Twilio Segment, mParticle or a similar SaaS for another vendor, an open source stack or a customer-owned deployment. You get a week-by-week plan, checklists, the legal terms that shape the exit, a risk register and a go/no-go checklist. Part of the guides hub.

The 90-day plan at a glance

Table 1. Phases, outputs and gates

Start from the contract, not the calendar. A missed non-renewal notice can lock in another contract term. For pricing context see Twilio Segment pricing and alternatives; for the target options see open-source customer data platforms compared.

Weeks 1 to 2: inventory and contract review

Build a register of everything the platform does. The migration scope is whatever the old platform quietly does for you.

• Sources: every web, mobile, server and cloud source, with SDK versions and write keys.
• Destinations: each destination, whether it runs in cloud mode or device mode, and its owner.
• Audiences, traits and transformations: definitions, schedules, functions and any logic living in the vendor UI.
• Identity rules: which identifiers merge, in what priority, and any custom external IDs.
• Consent integrations: the consent management platform (CMP), categories and how events are gated.
• Access and data held: users, API keys, webhooks, and which history exists only inside the vendor.

Then read the contract and the vendor's plan limits. Several export tools are plan-gated. Segment's Replay is available only on Business plans and is not self-serve: you contact support with the workspace, source, destinations and time period 1. Profiles Sync, which sends unified profiles and identity-graph tables to a warehouse, requires a Business tier account 2. Segment Data Lakes is also Business-only, is in limited access, and has been fully deprecated in the EU 5. Free and Team workspaces are limited to one warehouse 6.

Contract review checklist

• Term, renewal date, auto-renewal and the notice period to stop it.
• Rights to export all customer data, and in which formats.
• Exit assistance: scope, duration, price and named contacts.
• Return and deletion of data after termination, with a certificate.
• Sub-processors, data processing agreement, any business associate agreement, and fees on termination or retrieval.

Decide the target now. Another SaaS vendor means mostly mapping. An open source or self-built stack means you also build identity, consent and audit (see what you must build or buy). A warehouse-native stack moves the profile store into your warehouse. A customer-owned private deployment, such as PrivyCDP or Meiro's self-hosted option, moves operations to your side. Use the RFP template and the 3-year TCO model to compare.

Weeks 3 to 4: data contracts and schema mapping

A data contract is an agreed, versioned definition of an event: name, properties, types, identifiers, owner and consent category. Write them before you move anything.

• Export the current tracking plan or infer one from live traffic, then keep the canonical schema in version control.
• Map every source property to the target schema, including renames and type changes.
• List all identifiers (anonymous ID, user ID, email, device ID, external IDs) and their formats.
• Note semantic differences. Segment treats userId, anonymousId and groupId as case-insensitive, so User_123 and user_123 resolve to one profile 3. A target that is case-sensitive will split them.
• Validate at the edge: reject or quarantine events that break the contract, and set how long old and new schema versions run in parallel.

If you choose a Segment-compatible target, the SDK change can shrink. The rudder-server README describes Segment API compatibility 11, and the Jitsu README lists a Segment proxy as a collection path 12. Compatibility covers the call shapes; it does not cover identity, consent or audience behaviour.

Weeks 5 to 8: identity graph and consent-state export and validation

This is the longest phase because errors here cause real-world harm: wrong merges, lost history, and messages to people who opted out. For background see identity resolution explained.

Export the identity graph

With Segment's Profiles Sync, the raw tables are external_id_mapping_updates, id_graph_updates and profile_traits_updates, and the materialised tables are user_identifier, user_traits and profile_merges, all backfilled with full history 2. Event tables backfill only the last two months 2. Syncs run hourly, are limited to 3 TB each, and support Snowflake, Redshift, BigQuery, Azure Synapse, Postgres and Databricks 2. If another vendor is your source, ask for the equivalent artefacts in writing.

Decide between porting merges and recomputing from raw events. Porting preserves existing profile IDs and decisions that downstream systems already reference. Recomputing applies your rules cleanly but changes who is "the same person". One workable approach is to port the mapping, keep profile_merges as the audit trail, and recompute only when rules change.

Table 2. Identity export artefacts and validation checks

Export consent state

Suppression lists

Gather every list that stops contact: unsubscribe lists in email service providers, SMS opt-outs, do-not-sell signals, erasure requests and complaint or bounce suppressions. Build one union list and load it into the target before any activation is switched on. See consent withdrawal across channels.

Validation tests before leaving this phase

• Profile counts by identifier type agree within the tolerance you set.
• A fixed sample of 500 people yields the same segment membership in old and new systems.
• Every person on the suppression union list is blocked in the target for every channel.
• No deleted person exists in the target.

Weeks 9 to 10: destinations and dual-run

Rebuild destinations in priority tiers: tier 1 revenue and compliance systems, tier 2 analytics and engagement, tier 3 the rest. Segment's replay tool shows the issues: only cloud-mode destinations that handle timestamps are eligible, rows cannot be excluded, and some destinations do not deduplicate 1.

• Each destination has an idempotency key or message ID strategy so retries do not duplicate.
• Rate limits and retry policies are tested against the destination's API, not assumed.
• Device-mode destinations have a replacement plan, since they run in the browser or app.
• Shadow mode: the new pipeline receives the same events and writes to test or sandbox targets.
• Parity report per destination: event counts, field values, latency, error rates.

Webhook and SDK swap. Move server-side sources first, then web with a feature flag, then mobile. Mobile releases lag: old app versions will keep calling the old endpoint for weeks or months, so run a forwarding proxy and set an end-of-life date. Use a first-party custom domain for collection so future moves need no SDK change.

Weeks 11 to 12: cutover and decommission

• Freeze window agreed; cutover order tier 3, tier 2, then tier 1 destinations, with the suppression union list live first.
• Rollback plan tested: how to point sources back, and for how long the old platform stays paid and active.
• Old write keys revoked after a stated grace period, and a final export of anything unique to the old platform stored with checksums.
• Deletion requested in writing, with a vendor certificate, and the termination notice served on time.
• Evidence pack stored: inventory, mappings, validation reports, consent audit, deletion certificate.
• Post-migration review at 30 days.

The hard parts

Anonymous identities. Pre-login history is linked through anonymous IDs. Keep the same anonymous ID values in cookies and local storage so sessions continue; resetting them at cutover orphans history.

Merged profiles. Survivorship rules decide which traits win and which profile ID survives. Document them, keep merge history and keep unmerge possible. Wrong merges are worse than missed ones. Segment's priority-based merge algorithm is not explained on its public page 3, so ask for the rules in writing and test shared devices and shared emails.

Suppression, erasure and replay. Apply the union suppression list before activation and keep it synchronised afterwards. Deleted people must not return from a replay, which is also subject to the limits above.

Contract and legal points

This section is general information, not legal advice. Check your own contract and regulator guidance.

Exit assistance clauses. Specify scope (data, configuration, tracking plans), open documented formats, duration, price and named people. See vendor lock-in clauses and the cloud exit strategy template.

DORA, for EU financial entities. Regulation (EU) 2022/2554 requires, for ICT services supporting critical or important functions, exit strategies that cover provider failure, service decline or termination, and that let the entity leave without disrupting operations or harming clients; plans must be documented, tested and reviewed, with alternatives identified (Art. 28(8)) 8. Contracts must allow termination in defined situations (Art. 28(7)), give access to and return of data in an accessible format, including on insolvency or termination (Art. 30(2)(d)), and for critical or important functions include exit strategies with a mandatory adequate transition period (Art. 30(3)(f)) 8. Record the vendor in your register of information and the vendor register worksheet.

GDPR. Processor contracts must provide, at the controller's choice, deletion or return of all personal data at the end of services (Art. 28(3)(g)) 10. Portability (Art. 20) covers only data provided by the individual on a consent or contract basis, so it is not your exit mechanism 10.

Risk register

Go/no-go checklist

Agree thresholds with data owners before week 9.

• Contract notice served or confirmed, with dates agreed in writing.
• Event volume parity within the agreed tolerance (for example 1 percent) for seven consecutive days.
• Identity match rate and merge parity within tolerance on the sample set.
• Suppression union list verified blocking on every channel, with a test.
• Consent parity audit signed by the DPO or compliance.
• Every tier 1 destination passes its parity report.
• Rollback tested, with the old platform kept read-only for the agreed window.
• Support and on-call rota covers the cutover weekend.
• Evidence pack ready for auditors.

If any item is red, the answer is no-go.

Checked 17 October 2026 unless stated.