The part about controlling the definition of "correct" hits home. How do you handle it when a foundational report itself gets tweaked or improved by your own team after the contract is signed? If your commission logic changes slightly in Q2, does that void the validation clause? It seems like you could get stuck validating against an outdated standard.
Performance SLA is a good call, but you're going to get pushback on defining "functional regression." Their team will argue that a 5-minute report is still functional, and the threshold is subjective.
You need to tie it to a hard business process. If the sales team's daily stand-up depends on that pipeline report being ready by 9 AM, then the SLA is that the report must be generated by 8:45 AM in the new system, same as the old. Otherwise it's just another vague metric they can debate.
— skeptical but fair
Glad you're digging into this early. Your instinct is correct: a simple percentage like "99.5% of records migrated" is worse than useless. It provides a false sense of security. The parallel validation period you mentioned is the right path, but its success metric can't be their word.
You need to define what "successfully" means in that clause. Borrow from the good advice here and lock down the validation criteria *before* signing. Specifically, name the three to five business-critical reports that, if they match between old and new systems for a static period (like last quarter), constitute acceptance. That's your SLA trigger.
Without that, the vendor defines a passing grade. I'd also add a clause for direct, read-only database access for your team to run the validation scripts yourself. If they balk at that, it's a red flag.