Okay, so you've got your new CDP picked out and the migration plan mapped. The technical team is on board. But now you have to get buy-in from leadership, finance, maybe even sales and support. This is where I've seen projects stall.
The core challenge is that non-technical stakeholders hear "migration" and think "cost, risk, and disruption." They won't ask about event schema, but they *will* ask: "Why is this taking so long?", "What's the ROI?", and "What breaks during the switch?"
Here's what's worked for me. Frame it as a *data foundation upgrade*, not just a platform swap. Connect it directly to their goals: "This is what enables the personalized onboarding journeys the sales team asked for," or "This is the system that will finally give us a single customer view for the support team."
Be ready for their specific questions. Finance will ask about cost. Prepare a simple comparison: show the total cost of ownership of the old stack (license + maintenance + workarounds) versus the new one. Leadership will ask about risk. Have a clear rollback plan and phased cutover timeline. Marketing will ask about downtime. Be explicit: "There will be a two-week period where we cannot create new segments, but all existing campaigns will run uninterrupted."
Use analogies. I often say, "We're moving from a bunch of separate filing cabinets to one centralized, searchable library. The move itself is messy, but finding any customer detail afterwards will be 10x faster." Avoid terms like "backfill" or "id resolution"—say "we're bringing all historical data over and making sure John's website visit and support ticket are connected to his one profile."
The key is to control the narrative. Proactively address their unspoken concerns about timeline and business impact, and you turn skeptics into supporters. What's everyone else's go-to tactic for this? I'm always refining my approach.
✌️
✌️
Great point about framing it as a data foundation upgrade. That shift in language makes it strategic instead of operational.
One thing I'd add to preparing for finance's questions is to explicitly budget for the migration effort itself. It's not just license A vs. license B. You need to account for the engineering hours spent on the cutover, parallel running costs if applicable, and any new training. Bundle that into the TCO comparison upfront so it's not a surprise later.
For the rollback plan, I find it helps to describe it in terms of a "light switch" metaphor for non-technical folks. "We can flip back to the old system within X hours if critical issues arise." It makes the contingency feel tangible and controlled.