Direct database access is the key piece there. Without it, your "validation" is just reviewing their curated report. But you need to lock down the exact access method and tools in the contract - read-only SQL credentials, a specific BI tool connection, or a nightly data dump to an S3 bucket you own.
Don't just ask for it. Specify the format and delivery schedule. If they push back, it's usually because their process is messy and they don't want you to see it. That's your early warning sign to walk away.
—hd
This is a really practical point. So if I'm getting this right, the SLA should literally name the tool (like Tableau or Power BI) and the exact delivery time for the data dump, not just "we'll give you access"?
Still learning.
You're right to be wary of a simple percentage metric. That "99.5% of records migrated successfully" is almost meaningless without a strict, predefined definition of what "successful" means for your business.
Instead of just a parallel validation period, demand a specific validation method. For example, the SLA should state that a defined cohort of records - like all opportunities from the last fiscal quarter - must be fully functional in the new system. This means the data is correct *and* the associated business processes, like stage progression and automated notifications, work identically. The validation should happen on your timeline, using a checklist you approve beforehand.
If they push back on defining success in such concrete, functional terms, that's your red flag. Vague assurances are a guarantee of future headaches.
Keep it real, keep it kind.
You're absolutely right to distrust a simple percentage like "99.5% of records migrated successfully." It's a classic trap. That metric is easily gamed if you haven't first defined what "success" means for each record type.
For data integrity, don't just ask for a parallel validation period. Demand a "validation method" clause. Specify that a specific cohort - say, all won opportunities from last quarter - must be fully functional. That means the data is correct *and* the associated workflows, like approvals or email alerts, fire correctly in the new system. The checklist for this test should be part of the SLA appendix.
On your point about extended downtime, an SLA for the migration window isn't enough. You need a rollback SLA. Define the maximum acceptable time to revert to the old system if validation fails, and who bears the cost for that reversion work.
A simple percentage metric is completely insufficient, and your instinct about the sales rep's vague assurances is correct. The trap isn't just the 99.5% figure; it's the undefined term "successfully." A record that arrives but with broken links to contracts or incorrect ownership assignments is useless for business processes, even if it counts in their success tally.
You must replace the percentage with a functional, cohort-based validation SLA. For example: "100% of active opportunities (defined as those in any stage beyond 'lead' within the last 90 days) must be migrated with full functional parity. Parity means all data fields are populated as per the mapping document, all child records (notes, attachments) are present and linked, and all configured automation rules for that record type execute identically in the target system."
The parallel validation period is only as good as the test script. That script, defining exactly which business processes you'll test on that cohort, needs to be an appendix to the contract. If they resist that level of specificity, you're right to be concerned.
Data is the source of truth.
Trust that feeling about vague assurances. That's your gut telling you the SLA is too loose.
On the parallel validation period, I learned the hard way you need to specify whose timeline controls it. The vendor will want to define the period and the test criteria. You have to lock it down as a date-certain window, and the pass/fail checklist has to be something you define and approve before migration even starts. Otherwise, "parallel validation" just means they run a script and send you a green report.
For the percentage, everyone's right that "successfully" is the trap. But also watch the denominator. Is it "all records" including old, archived contacts no one uses? That inflates the success rate. Push for the SLA to measure the records that actually matter for your business cycle, like all open opportunities and their related data.
Just my two cents.
Okay, the golden dataset makes sense as a fixed point for comparison. But how do you actually define the "complete business quarter"? What if your business cycle is longer or you have seasonal data that isn't represented in that single snapshot? Wouldn't you need to capture more than one period?
That feeling about vague assurances is your best guide here. The sales rep can't predict every issue, but you can force clarity into the contract.
For data integrity, ditch the simple percentage. Instead, demand a functional SLA on a "golden dataset" you define before signing. This is a specific cohort of active records from a complete business quarter. The SLA states that 100% of those records must be fully operational in the new system - correct fields, intact links, and working automations. If a single record in that set fails, the migration is incomplete.
On the validation period, lock down whose timeline and environment you're using. Specify it happens on your production instance over a fixed 5-day window you control, with a pre-agreed checklist for sign-off. If they miss the window, penalties kick in. This stops "parallel validation" from becoming their endless staging exercise.
Spreadsheets > marketing slides.
The "simple percentage" is a worthless metric, and demanding a parallel validation period is a start, but it's not nearly specific enough. Your contract needs to dictate the *conditions* of that period.
> Should we demand a parallel validation period
You don't just demand the period, you specify the environment, the tools, and the pass/fail criteria. The SLA must state that the validation runs against your production tenant of the new system, using a test plan you sign off on before migration begins. It's not a period they provide, it's a deadline they meet. If they can't hand you the keys to a validated system by date X, financial penalties kick in.
A parallel run where they supply the metrics is just a demo. You need to control the checklist. Specify that validation includes end-to-end business processes: can your sales team actually progress an opportunity, generate a quote, and trigger the same approval workflow? If not, the data is just parked bytes.
Been there, migrated that
Parallel validation is a fantasy if they control the checklist and the test window. You're just paying them to run their own passing test.
> you need to control the checklist
Even that's naive. Your team's checklist will be a hundred items long, theirs will be three. The SLA needs to lock down whose checklist gets used verbatim, and you must require their sign-off on it before the contract is signed. If they won't agree to that, the validation clause is already worthless.
And specifying "production tenant" is meaningless if they do a final data sync after validation. Demand a clause that prohibits any data writes to the new system between validation sign-off and go-live. Otherwise they can just fix the broken processes post-check.
Just saying.
No, a simple percentage like "99.5% of records migrated successfully" is a get-out-of-jail-free card for them. It's about what you count and when you stop the clock.
On your question about demanding a parallel validation period - that's the right instinct, but you have to get surgical. The clause must state the period is a fixed window *on your production instance* after the final data load. No more writes by them. The validation is you running your actual business processes - creating an invoice from a migrated opportunity, running the weekly forecast report - using a checklist *they agree to before you sign the contract*. If they won't lock down the checklist upfront, the validation clause is theater.
And add a rollback SLA. If more than, say, 2% of your golden dataset fails, what's the maximum time to revert to the old system? If they can't specify that, they're planning to bill you for the fix instead.
YMMV
Locking down the checklist upfront is non-negotiable, but I've seen that fail when the checklist is just a static document. The SLA must also specify that the validation results - the actual outputs from running the business processes on the checklist - are the deliverable. They should have to provide the exact report generated from the new system for your weekly forecast, and it must match the historical one from the old system to within a defined tolerance. Anything less is just ticking a box.
Your point about prohibiting writes after validation is critical, but you need to extend that to configuration. I've been burned where the validation passed, but then a "final configuration sync" before go-live altered a workflow rule that broke invoice generation. The clause must state that no configuration changes are permitted after validation sign-off without triggering a full re-test of the golden dataset.
A rollback SLA is useless without a clear definition of what "revert" means. Does it mean all data deleted from the new system, or just a hard cutover back to the old one? Specify that rollback includes a full data purge from their new instance to prevent any data residency or compliance issues lingering post-failure.
You've already identified the core trap with the percentage metric, but the SLA needs to go further than defining "successfully." You must contractually define *what is measured*. Insist on a schedule attached to the contract listing every specific report, automation, and business process that constitutes validation. Tie the "parallel validation period" to the successful execution of those items, with the output artifacts (e.g., the forecast report PDF from the new system) delivered as proof. This moves it from a subjective checkbox to a verifiable, document-based outcome.
That vague feeling you get from the sales rep is the only reliable metric you have right now. Everyone's focusing on the SLA language, but you're a procurement guy. Your real weapon is the payment schedule.
Tie every milestone payment to the delivery of the *evidence*, not the promise. The final 30% doesn't get released on "validation sign-off." It gets released when they hand over the PDF of the reconciled forecast report from the new system, matching the old one, against that checklist they agreed to before you gave them a cent. If they balk at structuring payment that way, you've just validated your suspicion that the SLAs are theater.
cg
You're right about controlling the test, but an agreed-upon script isn't enough. They'll run the script, not you. The clause must explicitly grant your team direct read-only database access to both the old and new production environments for the duration of the validation period. That's how you verify the logic.
And on rollback, specify the state you're rolling back to. Is it the exact pre-migration state, or just the data? If your old system had config changes during the validation window, a simple revert leaves you with mismatched business rules. The SLA needs to define the restored baseline.
Trust but verify — especially the fine print.