Illustrative example. Riverbend Community Trust is a composite organisation built from patterns we see repeatedly in nonprofit data migration work. It is not a named customer, and the figures shown are representative of the category rather than measured at one client.
At a glance
| Organisation | Riverbend Community Trust, regional community foundation |
| Salesforce footprint | NPSP, 18 users, Household model |
| Volume | 31,000 constituents, 12,400 households, 186,000 gift records |
| The problem | Household relationships could not be resolved without repeated export passes |
| Approach | Legacy donor IDs as the match key across every object |
| Elapsed time | 6 weeks including reconciliation and parallel running |
| Outcome | Gift totals reconciled to the penny, 1,100 duplicates identified before go-live |
The situation
Riverbend had used the same donor database since 1999. It held 27 years of giving history for 31,000 constituents, including people who had given once in 2003 and never again, and families whose relationship with the trust spanned three generations.
Moving to NPSP meant reconstructing the household structure. The legacy system had a household concept, but it was a flat grouping rather than a relational one, and the exports reflected that: a household name in a text column on each constituent record, with no identifier connecting them.
What made it difficult
Households had to exist before constituents could reference them, but the household list had to be derived from the constituent file first.
Names were the only identifier on many records. Older records had no email address at all. Some had no address beyond a town.
The finance team needed exact reconciliation. Total gift value in the source had to match total gift value in Salesforce, to the penny, before the old system could be switched off. Trustees would be asked to sign off on that figure.
Budget was genuinely constrained. Per-record pricing on a 186,000 gift migration was not something the trust could justify against programme spend.
The approach
The team derived a household list from the constituent file, assigned each derived household an identifier, and wrote that identifier back into the source extract. That identifier became the match key for the entire migration.
Households loaded first, each carrying its derived identifier in an External ID field.
Constituents second, referencing the household by that identifier rather than by a Salesforce record ID, with the relationship resolved during the load.
Gifts last, referencing the constituent by the legacy donor ID, which had been preserved on every record in the previous pass.
Because the load was native and free, the team could re-run passes as often as they needed without either a security review of an external service or a per-record cost attached to each attempt. On a migration that ran nine full rehearsals before go-live, that mattered more than any single feature.
“We rehearsed the whole thing nine times. If every rehearsal had cost us money or needed a data processing agreement, we would have rehearsed twice and hoped.”
Operations director, community foundation
What changed
Duplicates surfaced before go-live rather than after. Multi-field matching on name plus postcode flagged around 1,100 constituent records as probable duplicates. These were reviewed by staff who knew the donors, and roughly 800 were merged before anything went live. The remaining 300 were genuinely different people who shared a household.
Household structure was correct on the first real load, because it had been tested on twenty households repeatedly until the NPSP naming and greeting formulas produced what the trust actually wanted.
No donor data left the org at any point. The trust holds information about beneficiaries as well as donors, and the data protection position was simpler with a native package than it would have been with an external service.
Results
Gift totals reconciled to the penny across 186,000 records, which was the condition for trustee sign-off.
Six weeks end to end, including two weeks of parallel running where both systems were live and compared weekly.
Every record traceable. The legacy donor ID sits on every constituent and every gift, so a question about a record from 2007 can still be answered against the original system’s archive.
Zero licensing cost for the migration tooling, which meant the budget went to a data quality contractor for the duplicate review instead. The trust considers that the better use of the money.
What they would do differently
The team tried to standardise address formats during the migration rather than after it. That mixed two problems together and made reconciliation harder, because a record that failed could have failed for either reason. The address cleanup was eventually pulled out into a separate project after go-live.
Import by name, email or code. Skip the VLOOKUP.
Smart Lookup Data Loader is a free, 100% native Salesforce app by TwinStack. Lookups resolve as records land, upserts match on several fields, and every failed row tells you why.
Get It Now, Free