Most vendors describe a rollback plan; few can produce one. Before you hire data migration specialists, ask to see the real document — trigger conditions, data-restore steps, who signs off — instead of a slide describing the idea. If they hesitate, the plan doesn’t exist yet.

Row counts and checksums only prove nothing was lost; they don’t confirm transformation logic ran correctly. Ask how field mappings and business rules get tested on their own — matching totals can hide broken logic underneath, the kind that surfaces in a finance report months later.

Foreign keys, constraints, triggers, and stored procedures can break even when every row lands where it should. Specialists who test referential integrity on its own catch the failures that surface in reports weeks later — orphaned records, broken lookups — not on migration day.

A credible plan rehearses the actual cutover at full data volume first, timings included. Two run-throughs are the practical floor; regulated data — finance, payroll, healthcare — usually needs three or four before anyone comes near production.

We’ll clean it up once it’s moved” is the excuse behind most failed migrations, usually discovered only once a report stops adding up. Ask how duplicates, nulls, and dirty records get flagged and fixed before migration starts, with a named owner for each fix.

A generic platform certification says little on its own. Oracle to Snowflake and SAP to Azure fail in different ways; ask for the specific stack they’ve moved before, what broke the first time, how they fixed it, and what they’d change on the next attempt.