Before you even look at a new CDP's feature list, you need a clear picture of what you're actually bringing with you. An incomplete or inaccurate audit of your current data is the single biggest cause of migration headaches—things like broken user journeys, silent data gaps, and skewed analytics post-switch.
I see many teams focus on the *destination* (the new tool's capabilities) and skip a thorough assessment of the *source*. Think of it this way: you're moving houses. You wouldn't just grab boxes randomly; you'd inventory what you have, note what's fragile, and discard what you don't need. Your CDP data is the same.
Here's a practical starting point for that audit, focusing on **completeness**:
**1. Core Entity Coverage:** Are your user profiles consistently populated? Check for blanks in critical fields like `email` or `user_id` across key sources (your app, website, CRM sync). A 90% completion rate might sound good until you realize the missing 10% are your highest-value customers.
**2. Event Stream Integrity:** Pick 5-10 critical behavioral events (e.g., `checkout_started`, `trial_upgraded`). For each, sample the raw data over the last 30 days. Ask:
- Is every event tied to a recognizable user ID, or are there anonymous events you can't afford to lose?
- Are your property schemas consistent? (e.g., `plan_name` vs. `subscription_tier`)
- What's the volume? A sudden drop could indicate a broken instrumentation pipeline you've inherited.
**3. Historical Depth & Gaps:** Your current CDP might only retain raw event data for 30 days, while your models need 12 months. Document the *actual* historical time window available for each data type. This will directly impact your backfill strategy and cost with a new vendor.
This audit isn't about blaming the old tool; it's about creating a factual baseline. That baseline lets you set clear requirements for the new CDP ("must support X months of backfill") and protects you from assuming a capability exists in your current data that actually doesn't.
Has anyone else done a similar audit? What were the most surprising gaps you found?
~ Amy
Spot on about the event stream integrity. That's where most of my custom integration work ends up living.
One thing I'd add to your point about sampling the raw data: make sure you're looking at the *unprocessed* event stream, not the version your current CDP has normalized or deduplicated. I've seen teams audit the cleaned data, migrate, and only then realize their old CDP was silently merging duplicate `page_view` events from the same session, which their new tool doesn't do. The resulting traffic spike in reports looked like a bug.
A quick way to spot-check is to pull a sample of raw webhook payloads from your source (like Segment, or your own collector) and compare them to the same events as they appear inside the CDP's interface. The delta can be very revealing.
api first
Oh, that's such a great point about the *unprocessed* stream. I spend way too much time comparing the processed event tables between tools and forget to peel back that layer.
Your duplicate `page_view` example hits home. We had a similar surprise with `form_abandon` events. Our old CDP was silently dropping any abandon event that happened less than two seconds after a field interaction, calling it "noise." When we switched, our abandon rate looked like it had doubled overnight and triggered a full funnel investigation. Took us a week to trace it back to that hidden filtering logic.
Now I always add a "raw vs. cooked" column to my comparison matrix. If the delta isn't documented, I assume there's hidden logic that'll bite me later.
Great metaphor about moving houses. It's so true that the missing profiles often belong to your most valuable users, because they might be coming from high-touch, low-friction channels like a sales-led invite. That's a painful gap to discover later.
On event sampling, I'd add to go one layer deeper than raw vs. processed. Check the event *timestamps* in your source system against what the CDP recorded. We found a whole segment of mobile events that were timestamped in UTC by our collector but got localized to PST by the old CDP's processing rules. Our new tool didn't do that, so all the session logic broke for that cohort. That timestamp drift can silently corrupt your journey data.
ian
Totally agree on the "highest-value customers" being the ones with missing data. That's the cruel twist. In our audit, we found the missing `user_id` profiles were almost exclusively from our enterprise plan - their onboarding bypassed the main signup flow because sales set them up manually. The system logged their activity as anonymous events tied to a temporary placeholder ID that never got resolved.
Which leads me to my addition: your point about checking across key sources is vital, but you also need to trace the *failure path* for those blanks. Don't just count them. Figure out if the gap is at ingestion (the data never arrived), mapping (it arrived but wasn't attached to the right profile), or a sync issue (it's in the CRM but the CDP connector dropped it). Each has a different migration risk.
Otherwise, you'll just recreate the same gap in the new system. Been there, fixed that, got the frustrating t-shirt.
Demos are just theater. Show me the real workflow.
Yes, the moving houses metaphor is perfect. I'd add that you need to check those "critical fields" like `email` for *formatting* consistency, not just presence. We once found that 15% of our user profiles had emails, but they were stored in three different formats (plain, obfuscated with `[at]`, and URI-encoded) across different source systems. Our old CDP normalized them quietly, but the new one treated them as three separate users. The merge logic post-migration was a nightmare.
Your point about the missing 10% being high-value customers is the real kicker. That's why you can't just run a high-level completeness query. You have to segment that gap by user tier or acquisition source to see where the pain will actually be.
Automate all the things.