Most data migrations don't fail at cutover — they fail three weeks earlier
By the time a migration goes dark in production, the actual mistake usually happened during scoping, when nobody surveyed what was really running.
Every failed cutover we've been called in to fix has the same postmortem shape: a pipeline nobody knew existed, a report one finance analyst built five years ago and never told anyone about, a permission that only worked because of a service account someone forgot to renew. None of that shows up in an architecture diagram. All of it shows up in production, at the worst possible time.
The instinct is to blame the migration tooling, or the target platform, or the timeline. Usually the real gap opened much earlier — during scoping, when the estate was inventoried by asking people what they thought was running instead of measuring what was actually running.
A proper survey doesn't take people's word for it. It traces every query against the source warehouse, maps which reports are live versus abandoned, and treats "nobody remembers why this job exists" as a finding, not a dead end. That inventory is unglamorous work. It's also the only thing standing between a calm cutover weekend and a war room.
The fix isn't more testing at the end. It's spending the first two weeks of any migration finding out what you don't know, before you commit to a date.