CDP Data Migration Checklist

A CDP data migration is the structured process of moving customer data, identity graph, consent records, audience segments, historical events, and active integrations from one customer data platform to a destination CDP while ensuring the destination produces equivalent or better profile outputs before any production use case switches over.

A CDP migration is not a database migration.

A standard database migration moves records from one environment to another. A CDP migration moves the operational foundation behind customer identity, consent enforcement, audience activation, personalization, attribution, suppression, and lifecycle orchestration.

That makes the risk profile different.

A CDP migration has to preserve not only customer records, but also the logic that makes those records usable. If the identity graph changes, the same customer may resolve differently in the destination CDP. If consent records migrate late or incompletely, opted-out customers may become eligible for activation. If historical events lose timestamps or customer identity links, attribution models and churn models may no longer trust the sequence of customer behavior. If segment logic is copied without validation, an audience that worked in the source CDP may produce different membership in the destination.

The business impact is not limited to a technical delay. A failed CDP migration can create compliance incidents, broken journeys, duplicate profiles, stale audiences, incorrect suppression, and lost rollback capability.

That is why CDP migration planning needs a checklist built specifically for customer data infrastructure.

Unlike a standard data migration, a CDP migration must handle five migration dimensions at once:

• Identity Graph Migration: The destination must either ingest the source CDP’s identity mappings or rebuild the identity graph from migrated profile and event data.
• Consent Record Migration: Opt-in, opt-out, advertising consent, and do-not-contact records must migrate first, with zero data loss.
• Behavioral Event History Migration: Page views, app sessions, email interactions, purchases, loyalty events, and service interactions must preserve original timestamps, schemas, and customer identity links.
• Segment And Audience Logic Migration: Every active audience must be rebuilt in the destination CDP’s query language and validated for membership parity.
• Integration Reconnection: Every source connector and activation destination must be reconnected and retested before production use cases switch over.

The central rule is simple: validation cannot wait until the end. Every migration category needs its own validation gate before the next category begins.

Pre-Migration Audit: What To Inventory Before Moving A Single Record

The pre-migration audit determines scope, risk, timeline, and cutover strategy. It also prevents the most common migration surprise: discovering halfway through execution that the source CDP contains more segments, more integrations, more custom logic, or more identity complexity than the destination can support.

Source Inventory Audit: What You Have

Start by documenting what exists in the source CDP before any migration work begins.

The source inventory should cover six categories:

• First, document profile count and composition. Count total canonical customer profiles, then break them down by identity state: fully resolved, partially resolved, and anonymous only. Also measure the percentage of profiles with complete deterministic identifier sets, such as email, phone, loyalty ID, and user ID. This becomes the reconciliation baseline for profile migration.
• Second, inventory historical event data. Document total event count, event types, oldest event date, event schema variations, and peak event volume. The date range determines how much history to migrate. Peak volume helps determine whether the destination CDP can handle load during replay and post-cutover production use.
• Third, inventory active audience segments. Count every active segment, document the last activation date, and classify segment complexity. Segments that have not been used in more than 90 days are candidates for archive rather than migration. Migrating unused segments adds cost without business value.
• Fourth, inventory source and destination integrations. List every source connector, including CRM, POS, loyalty, mobile app, marketing automation, contact center, ecommerce, and data warehouse. Then list every activation destination, including ESP, SMS, paid media, CRM, push notification, personalization, and analytics destinations. Each should have a named owner, sync cadence, authentication method, and last successful sync timestamp.
• Fifth, inventory consent record scope. Count explicit opt-in records, explicit opt-out records, do-not-contact flags, advertising consent records, and consent timestamps. The opt-out record count is the compliance-critical number. Every opt-out must be accounted for in the destination before cutover.
• Sixth, document calculated attributes and custom logic. If customer lifetime value tier, churn risk, propensity scores, engagement scores, or other computed fields are calculated inside the source CDP, document the logic. The destination CDP cannot reproduce those fields unless the calculation is rebuilt or the computed attribute is migrated directly.

Destination Readiness Audit: What The New CDP Can Receive

The destination CDP must be validated against the source inventory before migration begins:

• The first readiness check is data model parity. Does the destination support the same event types, attribute fields, identifier types, nested objects, and consent structures used in the source? Any missing field or event type requires a mapping decision, redesign decision, or exclusion decision with stakeholder sign-off.
• The second readiness check is integration parity. Does the destination have maintained connectors for every source system and activation destination currently used by the source CDP? If not, the team must plan a custom connector, middleware layer, API build, or use case deprecation.
• The third readiness check is use case parity. For every active use case powered by the source CDP, determine whether the destination can support it in equivalent form. Some use cases will migrate directly. Some will require redesign. Some may need to be deprecated if the destination lacks a feature the source CDP used.

No migration should begin until each use case has a documented target state: equivalent, modified, or deprecated.

The CDP Data Migration Checklist: Eight Categories In Sequence

A CDP migration should follow eight categories in sequence. Categories should not run out of order unless the validation dependency is explicitly understood and approved.

Category 1: Consent And Opt-Out Records

Consent migrates first. Always.

This category includes marketing consent, advertising consent, do-not-contact records, opt-out flags, consent timestamps, and consent source metadata showing how and when consent was obtained.

The migration steps are straightforward but strict:

• Export all consent records from the source CDP.
• Preserve timestamps and consent source metadata.
• Load consent records into the destination CDP’s consent management layer before any profile or event data.
• Reconcile source and destination consent counts.
• Run a consent enforcement test before any production activation destination is connected.

The validation gate is zero discrepancy. The destination consent record count must match the source exactly for all compliance-critical consent categories.

The consequence of failure is severe. Any opt-out record that fails to migrate is a compliance incident. Consent data has no acceptable recovery point objective. If a consent record is lost, it cannot always be reconstructed from behavioral data, profile attributes, or campaign history.

This is the only migration category where “in progress” is not an acceptable cutover state.

Category 2: Historical Event Data

Historical event data includes behavioral events from the source CDP’s event store. This may include web sessions, app sessions, email engagement, purchases, loyalty events, POS transactions, support interactions, and other customer behaviors.

The migration steps should include:

• Export historical events through the source CDP’s export API, database export, or event archive.
• Transform event schemas into the destination CDP’s event model.
• Preserve original timestamps.
• Preserve customer identity links.
• Load events in chronological batches, usually oldest first.
• Quarantine events with null or invalid customer identity fields for identity resolution review.

The validation gate includes event count reconciliation, required field completeness, and schema validation. A practical threshold is destination event count within 5 percent of source, required field null rate below 0.1 percent for event type, timestamp, and customer ID, and 100 percent schema conformance for accepted event records.

The consequence of skipping this validation is profile corruption. Events migrated without original timestamps cannot support accurate attribution or journey reconstruction. Events migrated without identity links become orphaned records. Events migrated with schema errors can quietly corrupt downstream segments and models.

Category 3: Customer Profile Records

Customer profile records include canonical profiles and their attributes: email, phone, loyalty ID, user ID, demographic attributes, loyalty status, last purchase date, churn risk score, LTV tier, and other profile fields.

The cleanest approach is a two-pass migration:

• In Pass 1, migrate deterministic identifiers first: email, phone, loyalty ID, user ID, CRM ID, and account ID. This gives the destination CDP the identity foundation it needs before broader profile attributes load.
• In Pass 2, migrate remaining profile attributes, including demographic fields, loyalty fields, calculated fields, and preference fields.

The validation gate should include:

• Destination canonical profile count within 2 percent of source.
• Manual validation of 100 to 200 sampled profiles.
• All expected attributes present and matching source values.
• Zero duplicate canonical profiles in the validation sample.

The consequence of failure is downstream inaccuracy. Duplicate canonical profiles corrupt segmentation and activation. Missing profile attributes may make audiences smaller than expected. Migrating profile fields without the corresponding event history creates profiles that look complete but lack the behavioral signals needed for models and journeys.

Category 4: Identity Graph Migration

The identity graph is the accumulated mapping of identifiers to canonical customer profiles. It defines which emails, device IDs, cookies, phone numbers, loyalty IDs, app user IDs, and CRM IDs belong to the same customer.

There are two migration approaches:

• The first is direct graph export. In this approach, the team exports the source CDP’s identity mapping table, including source identifier, identifier type, canonical profile ID, match confidence, and first seen date. The destination CDP imports these mappings as seed identity links before its own identity resolution rules run.
• The second is graph rebuild. In this approach, the destination CDP rebuilds the identity graph by running its identity resolution engine against migrated profile and event data.

Either path requires validation.

The destination must resolve known multi-identifier test profiles to the same canonical customer profile as the source. The team should also test false positives by confirming that profiles known to be separate individuals are not merged.

The validation gate should include:

• Identity match rate of 85 percent or higher on test profiles with known identity outcomes.
• Zero duplicate canonical profiles.
• Zero circular merges.
• Zero confirmed identity contamination cases.

The consequence of failure is structural. If the destination resolves customers differently than the source, every downstream use case changes. Segments change. Suppression changes. Personalization changes. Attribution changes. A use case that was validated in the source CDP may silently produce the wrong output in the destination.

Category 5: Segment And Audience Logic

Segment migration is not a copy and paste exercise.

Every CDP has its own query language, segment builder, data model, refresh behavior, and evaluation engine. A segment that looks simple in the source may require different logic in the destination.

For each active segment:

• Export the source segment definition.
• Translate the logic into the destination CDP’s query language.
• Execute the source and destination segments at the same point in time.
• Compare membership counts.
• Sample-validate included and excluded customers.
• Document any segment that requires redesign because the destination does not support the source logic.

The validation gate should include destination segment size within 10 percent of source segment size, plus 100 percent accuracy for sampled included and excluded customers.

Suppression segments deserve stricter treatment. The destination should never suppress fewer customers than the source for compliance-critical or customer experience-critical suppression audiences.

The consequence of failure is immediate business impact. A segment that produces different membership in the destination will send campaigns to different customers on day one. A suppression segment that is smaller in the destination may activate customers who were properly excluded in the source.

Category 6: Source Integration Reconnection

Source integrations include CRM, POS, loyalty, mobile app, ecommerce, marketing automation, contact center, data warehouse, and other systems feeding the CDP.

Reconnect one source at a time.

For each source connector:

• Reconfigure the connector in the destination CDP.
• Run the integration test suite for ingestion, identity, segmentation, and activation dependencies.
• Confirm first delta sync counts.
• Validate schema.
• Confirm consumer lag is within the source’s tier SLA.
• Resolve defects before reconnecting the next source.
• Do not reconnect every source simultaneously. That makes defects harder to isolate.

The validation gate is per-integration. The first delta sync should reconcile within tolerance, required fields should pass validation, and all relevant integration tests should pass before the next source connector begins.

The consequence of skipping this step is data gaps. A source connector that was live in the source CDP but missing or misconfigured in the destination creates stale profiles during the parallel run. If the gap reaches cutover, the destination becomes authoritative with incomplete customer data.

Category 7: Activation Destination Reconnection

Activation destinations include ESPs, SMS platforms, paid media platforms, CRM activation, push notification systems, onsite personalization, and service platforms.

For each activation destination:

• Reconnect the destination CDP connector.
• Run an internal-only test activation.
• Confirm delivery volume reconciliation.
• Confirm activation latency.
• Run the consent enforcement test for that destination.
• Run the suppression enforcement test for that destination.
• Do not allow live campaign activation until every activation test passes.

The validation gate should include delivery volume within 2 percent of expected, 100 percent consent enforcement, 100 percent suppression enforcement, and activation latency within the use case SLA.

Consent enforcement must be tested per destination, not once globally. A global consent test does not prove that every activation connector respects consent flags.

The consequence of failure is direct customer impact. If an activation destination goes live before consent and suppression tests pass, the destination CDP may send to opted-out or suppressed customers.

Category 8: Use Case Parallel Run

The parallel run is where assumptions become evidence.

After the first seven categories pass, the destination CDP should run in parallel with the source CDP for a defined window. For Tier 1 use cases, that window should usually be at least two weeks and often two to four weeks.

During the parallel run:

• The source CDP remains responsible for production activation.

• The destination CDP evaluates the same profiles, segments, and use cases.
• Segment outputs are compared daily.
• Suppression coverage is compared daily.
• Activation timing is tested.
• Use case parity is documented before cutover is scheduled.

The validation gate should include destination segment outputs within the defined tolerance, suppression coverage equal to or greater than source, and activation latency within the same tier SLA as the source.

The consequence of skipping the parallel run is that all use case failures are discovered in production. On a large enterprise CDP program, that can affect millions of customer interactions before the defect is detected and corrected.

The Sequencing Rule No Checklist Should Omit

Categories 1 through 7 are sequential.

Consent must migrate first. Historical events must load before identity graph rebuild if the destination is rebuilding identity from migrated data. Identity graph validation must pass before segment migration because segment membership depends on profile resolution. Segment parity must pass before activation destination reconnection. Integration validation must pass before parallel run. Parallel run must pass before cutover.

The most common sequencing error is starting identity graph migration before historical event data is fully loaded. The second most common error is starting segment migration before identity graph validation. Both create false confidence because the destination may look functional while producing different profile and audience outputs than the source.

The Three CDP Cutover Patterns

Cutover is the highest-stakes tactical decision in a CDP migration. The right pattern depends on risk tolerance, number of use cases, contractual timing, and whether the destination has proven parity during the parallel run.

Pattern 1: Big Bang Cutover

In a big bang cutover, the organization stops writes to the source CDP, runs a final delta sync, validates the destination, and switches all traffic to the destination in one event.

This is the highest-risk pattern. Any undetected defect is discovered in production. Rollback means switching all traffic back to the source within a defined window.

Big bang cutover is best suited for smaller CDP programs with a limited number of simple use cases, or programs where a clean break date is required because the source CDP license is ending.

Before using this pattern, the team needs:

• Completed parallel run with zero open defects
• Final delta sync plan
• Timed rollback runbook
• Named rollback owner
• Business stakeholder sign-off
• Clearly defined rollback trigger metrics

Big bang should never mean “skip validation and hope the cutover works.” It should only occur after the destination has already proven parity.

Pattern 2: Phased By Use Case

In a phased cutover, use cases migrate one at a time, usually starting with lower-risk use cases. The source CDP remains live for non-migrated use cases while the destination handles migrated use cases.

This pattern has medium risk. It isolates defects by use case and protects high-value journeys from early migration issues. The tradeoff is complexity and cost. The organization may need to maintain two CDPs during the phased period.

Phased migration is best suited for enterprise CDP programs with many active use cases, especially when some use cases require destination-specific redesign.

Before using this pattern, the team needs a dependency map. Some use cases share segments, suppression logic, activation audiences, or identity rules. Those use cases may need to migrate together rather than separately.

The most important warning is conflict resolution. Do not rely on timestamp-based last-write-wins logic when two systems are updating related records at the same time. That pattern can silently corrupt customer data. Conflict rules must be explicit.

Pattern 3: Parallel Run With Full Dual Write

In a full parallel run, both source and destination CDPs receive the same write traffic for a defined window. Both systems evaluate the same use cases. Outputs are compared daily. Cutover happens only after parity is confirmed.

This is the lowest-risk pattern for data quality and the highest-cost pattern operationally.

It is best suited for mission-critical CDP programs where use case failure would create meaningful revenue, compliance, or customer experience risk. It is also the best pattern for complex identity graphs where profile resolution needs extended observation time.

Before using this pattern, the team needs dual-write infrastructure. That may require Kafka, AWS EventBridge, middleware, a fan-out connector, or custom routing so source systems can send events to both CDPs during the parallel period.

The team also needs rules for handling disagreement. If the source and destination produce different segment membership for the same customer, the migration team needs a defined escalation path and decision owner.

The Rollback Trigger Rule

Every cutover pattern requires rollback triggers before the cutover date is scheduled.

A rollback trigger is not “if something goes wrong.”

A rollback trigger is a specific measurable condition tied to a named owner and response time. Examples include:

If any opted-out customer appears in any activation output from the destination CDP, initiate rollback immediately.

If any Tier 1 use case segment deviates by more than 10 percent from expected membership within two hours of cutover, escalate to the rollback owner.

If activation success for any Tier 1 destination drops below 95 percent during the first four hours after cutover, evaluate rollback.

If identity contamination is detected, escalate immediately.

If consumer lag for any Tier 1 source exceeds the SLA for more than 30 minutes, initiate investigation and rollback evaluation.

Vague rollback triggers create delay. Specific rollback triggers create control.

The Three Validation Gates Before Declaring The Destination Authoritative

A CDP migration is not complete when the data has moved. It is complete when the destination CDP has passed validation, operated through the parallel run, and survived post-cutover hypercare without triggering rollback.

Validation Gate 1: Data Completeness And Accuracy

Gate 1 aggregates the validation work across the migration categories.

It requires:

• Consent record count equals source with zero discrepancy.
• Profile count is within 2 percent of source.
• Event count is within 5 percent of source.
• Identity match rate is 85 percent or higher on test alias families.
• Zero duplicate canonical profiles.
• Sampled profiles show all expected attributes and matching source values.

Gate 1 does not pass until no open data quality failures remain. It is the prerequisite for beginning the parallel run.

Validation Gate 2: Segment Parity And Use Case Equivalence

Gate 2 runs during the parallel run.

It requires every migrated use case to produce functionally equivalent outputs in the destination CDP. Segment size should be within the defined tolerance, sampled membership should validate correctly, suppression coverage should be equal to or greater than source, and activation latency should meet the same tier SLA.

Gate 2 does not pass until the parallel run has completed its defined window with zero open parity failures.

It is the prerequisite for scheduling cutover.

Validation Gate 3: Post-Cutover Hypercare

The first 72 hours after cutover are the highest-risk period.

During hypercare, the migration team should monitor the destination CDP continuously. The source CDP should remain frozen in a read-only state, not decommissioned, for the full rollback window.

Hypercare should monitor:

• Consumer lag
• Data freshness
• DLQ growth
• Identity match rate
• Profile API latency
• Pipeline error rate
• Activation success rate
• Segment computation time

Any critical breach should trigger rollback evaluation by the named decision owner.

Gate 3 closes only after the 72-hour hypercare period ends with no rollback-triggering events. Only then should the source CDP move toward decommissioning.

How Stable Kernel Manages CDP Migrations

Stable Kernel manages CDP migrations as business continuity projects, not connector replacement projects.

Migration Planning Before Data Movement

Stable Kernel begins with the pre-migration audit: source inventory, destination readiness, use case parity, integration scope, consent record scope, segment inventory, identity graph complexity, and cutover risk.

The most common issue in failed or stalled migrations is sequencing. Consent records were treated as another dataset instead of the first migration category. Segment parity was assumed rather than tested. The parallel run was skipped to meet a date-certain cutover. The source CDP was decommissioned before the destination survived hypercare, eliminating rollback capability.

Stable Kernel’s standing rules are direct:

• Consent migrates first, always.
• Tier 1 use cases require a parallel run.
• Rollback triggers are defined before cutover.
• The source CDP remains read-only through hypercare.
• The cutover should be boring, not an emergency.

Validation Gates As Formal Deliverables

Stable Kernel defines validation gates as formal migration deliverables.

That includes category-level validation, source and destination reconciliation, identity graph validation, segment parity, activation testing, rollback runbooks, and post-cutover hypercare dashboards.

Stable Kernel helps enterprise organizations plan and execute CDP migrations with the pre-migration audit, sequenced migration checklist, cutover pattern selection, rollback trigger design, parallel run, and three validation gates as formal deliverables.

FAQ

What Should A CDP Data Migration Checklist Include?

A CDP data migration checklist should include eight sequential categories: consent and opt-out records, historical event data, customer profile records, identity graph migration, segment and audience logic, source integration reconnection, activation destination reconnection, and use case parallel run. It should also include the pre-migration audit, destination readiness assessment, cutover pattern selection, rollback triggers, and three validation gates. A checklist without category-level validation is only a migration schedule, not a migration plan.

What Is The Most Common CDP Migration Failure?

The most common CDP migration failure is treating validation as the final step rather than running validation continuously throughout the migration. When validation happens late, early defects contaminate later migration categories. For example, if event migration fails but identity graph migration and segment migration have already run, the team may need to rerun multiple categories. The prevention is category-level validation: no migration category should begin until the previous category’s validation gate passes.

How Long Does A CDP Migration Take?

A comprehensive enterprise CDP migration often takes four to six months from audit to source decommissioning. The timeline depends on historical event volume, number of active use cases, number of segments, identity graph complexity, integration count, and cutover pattern. A pre-migration audit may take two to four weeks. Segment migration and parity validation may take three to five weeks for 20 to 50 active segments. Integration reconnection may take two to four weeks for 10 to 20 integrations. A parallel run typically requires two to four weeks for Tier 1 use cases, followed by 72 hours of hypercare.

Why Should Consent Records Migrate First In A CDP Migration?

Consent records should migrate first because the destination CDP must be consent-safe before customer data is loaded or activated. If a customer profile migrates before the customer’s opt-out record, the destination may temporarily treat that customer as eligible for activation. That creates compliance risk. Consent migration requires zero discrepancy between source and destination counts, and the consent enforcement test must pass before any activation destination goes live.

How Do You Migrate An Identity Graph From One CDP To Another?

An identity graph can migrate through direct graph export or graph rebuild. In direct export, the source CDP’s identity mapping table is imported into the destination as seed mappings. In graph rebuild, the destination CDP runs identity resolution against migrated profile and event data. Both approaches require validation using known multi-identifier test profiles, synthetic alias families, false positive tests, and duplicate profile checks. The destination should produce the same canonical profile resolutions as the source before segment migration begins.

How Do You Validate Segment Parity Between Source And Destination CDPs?

Segment parity validation confirms that a segment rebuilt in the destination CDP produces equivalent membership to the source segment. First, translate the segment logic into the destination query language. Second, evaluate both segments against the same data snapshot. Third, compare segment size, with a practical tolerance of 10 percent for most non-compliance segments. Fourth, sample-validate included and excluded customers. Suppression segments require stricter validation because smaller suppression membership in the destination can activate customers who were excluded in the source.

What Are The Three CDP Cutover Patterns?

The three CDP cutover patterns are big bang, phased by use case, and parallel run. Big bang switches all traffic at once and carries the highest risk. Phased by use case migrates one use case or use case group at a time, lowering risk but increasing operational complexity. Parallel run sends equivalent traffic to both source and destination for a defined window and compares outputs before cutover. Parallel run is the safest pattern for mission-critical CDP programs, but it is also the most expensive and operationally complex.

What Rollback Triggers Should A CDP Migration Plan Include?

A CDP migration plan should include rollback triggers for consent enforcement failure, segment output deviation, activation delivery failure, identity graph contamination, and Tier 1 consumer lag. The triggers should be measurable and time-bound. For example, if any opted-out customer appears in an activation output, rollback should begin immediately. If a Tier 1 segment deviates by more than 10 percent from expected membership within two hours of cutover, the rollback owner should evaluate within the defined response window.

Can Stable Kernel Manage A CDP Data Migration?

Yes. Stable Kernel helps enterprise teams plan and execute CDP migrations, including the pre-migration audit, source inventory, destination readiness assessment, consent-first migration sequencing, identity graph migration validation, segment parity testing, integration reconnection, activation testing, cutover pattern selection, rollback trigger design, parallel run management, and 72-hour post-cutover hypercare.