Moving customer records is only part of switching customer data platforms. Your current CDP also contains identity decisions, calculated attributes, audience definitions and delivery behavior that teams rely on.
A CDP migration should preserve the history and business meaning those workflows need. Inventory the dependencies, rebuild one complete workflow, compare its results and move destinations in controlled stages.
Key Takeaways
Inventory sources, identifiers, calculated fields, audiences and downstream dependencies before planning cutover.
Preserve source keys and history; don't assume the new platform will reproduce the old identity graph exactly.
Rebuild eligibility and suppression rules explicitly instead of inferring them from list membership.
Compare audience changes in the receiving system, including removals, before switching ownership.
Define rollback criteria and retain the evidence needed to explain differences after launch.
Inventory what the old platform actually does
List the sources feeding the CDP and the destinations receiving its output. For each important workflow, record the owner, schedule, identifiers, field mappings, eligibility conditions and business dependencies.
Include work outside the CDP: warehouse transformations, manual file corrections, destination imports and scripts. A workflow that appears simple in the interface may rely on several external processes.
Use the build-versus-buy framework to identify responsibilities that will change during the migration. Make the new ownership explicit before retiring the old implementation.
Preserve raw history and its interpretation
Retain the source identifiers and event or transaction history required by your agreed use cases. Record timestamp meanings, time zones, cancellations, returns and any rules that affect historical calculations.
Keep the old platform's derived values separately when they are useful for comparison. A lifetime-value field or first-purchase date is not self-explanatory; preserve its calculation and source scope as well as its output.
This is a practical application of customer data unification: the goal is usable customer history, not simply more records in a new location.
Plan for identity differences
A new platform may group records differently, even when both systems receive the same data. Treat those differences as findings to investigate.
Preserve the relationship between source IDs, legacy platform IDs and the new customer IDs where your transition design requires it. Don't assume a legacy ID is a permanent person identifier or force every old grouping into the new graph without review.
Sample customers with shared contact details, changed email addresses and conflicting account information. The distinction between identity resolution techniques helps frame why matching configurations can produce different outputs.
Rebuild one audience from source to destination
Choose a workflow whose inclusion and exclusion rules can be explained record by record. Recreate the profile attributes, audience logic, field mappings and destination configuration.
Compare the old and new outputs before activating the new route. Differences may come from source freshness, identity grouping, timezone handling, calculation rules or destination eligibility. Assign each meaningful discrepancy a cause and an owner.
Validate the audience in its receiving system, not just in an exported file. Correct row counts don't prove that identifiers matched or that the audience can be used as intended.
Test eligibility and removals separately
A customer appearing in a list does not establish permission to contact them. Rebuild the applicable eligibility and suppression logic using the records and rules your organization relies on.
Test what happens when someone leaves an audience, changes a contact address or becomes ineligible. Some destinations replace membership; others add or update records through separate actions. Review the actual connector behavior.
Avoid running two independent workflows against the same managed list unless the destination's behavior and ownership plan support that arrangement.
Use a controlled overlap period
Run comparative processing where it helps validate results, while controlling which system owns each live downstream action. Parallel computation doesn't require duplicate customer communications.
Agree on the conditions for cutover: reconciled source totals, reviewed identity differences, accepted profile calculations and a verified destination test. Document who can approve the switch and what evidence they must see.
Define rollback triggers before the change. Preserve the configuration and operational access needed for the agreed fallback, subject to your retention and access requirements.
Expand and retire in stages
Move additional workflows after the first one is dependable. Reuse validated mappings and business definitions, but repeat the checks when a new source or destination changes the assumptions.
Before retiring the old CDP, confirm historical access, remaining integrations, reporting dependencies and the agreed retention or deletion obligations. Keep a record of accepted differences so future teams don't interpret every changed customer count as a new defect.
Explore our Customer Context Platform and evaluate the identity, profile and activation workflow your migration requires. A successful import is only one acceptance check.
