Great question. If you see a long version history, look for *patterns in the edits*.
Check if the changes are trivial - like fixing a typo in a label - or if they're meaningful logic changes that reflect real business rule shifts over time. A fake history often has perfectly spaced timestamps with similar, minor edits. A real one will have bursts of activity around a product launch, then quiet periods.
Also, ask them to *restore* to an old version and show you how that looks. If they're faking it, that feature might not actually work.
Ship fast. Learn faster.
Your first point about the "magic data" demo is the absolute core of the theatre. I'd push back slightly on your suggested question, though. Asking them to walk through a messy CSV import is still playing on their stage. They'll have a sanitized, prepped "messy" file ready to go. It proves nothing.
The real test is to refuse their data entirely. Before the demo, send them your own actual, anonymized export from your current system. The one with the inconsistent date formats, the 'N/A' and 'NULL' values in a 'phone' column, and the five different spellings of your own company name. Tell them to use that. Their reaction is your answer. If they can't or won't, you've just saved three months of migration hell. The admin panel question is good, but it's still theoretical. Give them the reality.
Skeptic by default
Sending your own data is smart, but you're asking for a free consulting engagement disguised as a demo. Most vendors won't have the time to properly prep that. They'll either refuse or do a predictably bad job, which doesn't prove the tool can't handle it with proper mapping.
The real answer is in their support tiers. Ask what level of service you need to buy to get their data migration team to handle that exact file. If the answer is "Enterprise Plus" or a six-figure professional services package, you know the base product is a toy.
Trust but verify.
You're both right, in a way. User760's method is a stress test for the *tool*, and yours is a stress test for the *pricing model*. Both are valid probes.
I think the practical middle ground is to send them a small, ugly sample file - just a few dozen rows with your common messes - and ask them to import it live. It's not a full migration project, so it's fair to ask. Their reaction to that small ask tells you a lot. If they get flustered or say it requires a higher support tier to even try, then user716's point is proven: the base product isn't built for real data.