Salesforce data migration with a record count you sign off
A migration is judged on one question: do the numbers match? Here is how we make sure they do, what went wrong before at a non-profit with 100,000 records, and the one document that makes a migration safe to sign.
Bohdan PyrihCEO, AdvirixWhy migrations go wrong
Not because of the tool. Because nobody agreed what "all the data" meant before it moved. A legacy system has records that were deleted but not purged, duplicates that two people created on the same day, fields that changed meaning in 2019, and relationships held together by a spreadsheet. Move all of that faithfully and you have migrated the problem. Move "only the good records" without saying which, and you have lost data nobody can name until an invoice bounces.
Keep Texas Beautiful
A Texas non-profit moved from a legacy system to Salesforce with more than 100,000 records: members, affiliates, donors, programmes, invoices. For a non-profit a bad record is not cosmetic; it is a donor relationship, a missed renewal, an invoice sent twice. The migration was built around counts and rules: validation rules so bad data could not come back in, custom automations for the calculations the old system did by hand, and a cleanup pass with the numbers agreed before and after. Data errors fell by 95%, manual entry and repetitive tasks dropped, and invoices went out faster. The client's review on Clutch is two sentences long: organised and responsive. That is what a migration should feel like from the inside.
The method, in six steps
1. Inventory
Every object and table in the source, with a count and an owner. Not "contacts": 48,212 contacts, of which 3,104 have no email and 1,790 are marked inactive. The inventory is the first document you sign.
2. Mapping
Source field to target field, with transformation rules and what happens to values that do not fit. Every field has a decision: migrate, migrate and transform, or leave behind with a reason. Nothing is implied.
3. De-duplication rules
What makes two records the same: email, name plus postcode, tax ID. Which record wins. What happens to the loser's history. The rules are written, tested on a sample, and the merge count is agreed before the merge runs.
4. Dry runs
The full migration into a sandbox, at least twice. Counts compared object by object. Spot checks by your people on records they know. Every discrepancy explained or fixed before production.
5. Validation rules on the way in
The rules that would have stopped the bad data in the first place, switched on in the new org before go-live: required fields, formats, relationships. The migration is the one moment the data is clean; the rules keep it that way.
6. The count you sign
Before: records in source, by object. After: records in Salesforce, by object, and the list of what was deliberately left behind and why. Both numbers on one page, signed by both sides. That page is what makes a migration safe to accept.
What it costs
Data Migration and Cleanup starts at $4,500 for a single-source migration with de-duplication, quoted as a fixed number once the inventory exists. The inventory itself is part of the Health Check, which is why the migration is usually the second step, not the first. If the data is already in Salesforce and the problem is trust in the reports, the same method applies without the move: counts, rules, cleanup, validation.
Three questions before you accept any migration quote
- Will I get a before-and-after count by object, signed?
- What are the de-duplication rules, in writing, and who decides the winner?
- Which validation rules will be on before go-live, so the bad data cannot come back?
A sample inventory page
| Object | In source | Decision |
|---|---|---|
| Contacts | 48,212, of which 3,104 without email, 1,790 inactive | migrate 45,108; archive 3,104 |
| Organisations | 6,430, with 410 probable duplicates by name and postcode | merge to 6,020 |
| Donations / invoices | 112,900 over nine years | migrate all; validate totals by year |
| Notes and attachments | 31,000 files, 14 GB | migrate last five years; archive the rest |
Illustrative figures in the shape of a real inventory; the point is that every row has a number and a decision before anything moves.
What to do with the records you leave behind
Nothing is deleted. Records that do not migrate go to an archive you can query: an export with the same IDs, kept for as long as your retention policy says. The list of what was left behind, and why, is the second half of the count you sign. Six months later, when someone asks about a donor from 2017, the answer is in the archive, not gone.
The Keep Texas Beautiful case, and the Data Migration and Cleanup package.