Everyone talks about schema mapping and backfill. Fine. But the real budget killer is downstream connectors.
You pick a new CDP, map your events, think you're done. Then you find out:
* The old CDP's "Segment" compatible endpoint had quirks your internal service relied on.
* Your webhook payloads are slightly different, breaking three internal dashboards.
* The new SDK batches differently, overloading your event processor.
Seen it three times now. Teams budget for the migration, not for the rewiring of every little service that *consumed* the data. That's where the 20% gets eaten. It's not for the CDP itself, it's for the ecosystem you glued to it over the years.
So yeah, add the contingency. Or enjoy the panic when Finance asks why you need another sprint.
Twenty percent? That's optimistic. I'd double it for any system older than eighteen months. The part you've nailed is the "glued to it over the years" angle. Nobody documents the hacks.
Last year, moving off Marketo, we found a "dead" webhook listener for a deprecated product. The new system didn't send a `lead_source` field the same way - blank meant `null` before, but now it sent an empty string. That one field mismatch caused a silent fail in a script that fed a quarterly compliance report. Took six weeks and an audit to trace it. The budget line was "data migration," not "forensic accounting for custom scripts."
Your point about the SDK batching is also a silent killer. It's not just about overload. It changes the order of events in your queue. If you have any logic that depends on sequence, like calculating a state transition, it collapses. You don't find that in testing with trivial volume.
So yes, the contingency is for the ghosts in the machine. The 20% is for the known unknowns. The other 20% you didn't mention is for the stuff you'll find in production when someone in Sales asks why their lead score hasn't moved in two weeks.