If you administer a Salesforce org for a nonprofit, you've probably noticed that new features keep landing in Nonprofit Cloud while your NPSP (Nonprofit Success Pack) org sits still. This post is a practical look at what that actually means for your data model and how to plan a migration before you're forced into a rushed one.
No shutdown date has been announced for NPSP. That's precisely why this is worth planning for now, while you can do it calmly.
Problem
NPSP is a managed package layered on top of core Salesforce. It reshapes standard objects into a fundraising-friendly model:
Account → household/organization accounts
Opportunity → donations, with npsp_Primary_Contactc, soft credits, and recurring donations (npe03Recurring_Donation_c)
A stack of NPSP settings, triggers, rollups (Customizable Rollups / CRLP), and batch jobs
Nonprofit Cloud uses a different fundraising data model built around objects such as GiftTransaction, GiftCommitment, GiftCommitmentSchedule, and related designation and donor records.
The core problem: your donor history, recurring gifts, and reporting logic are all expressed in NPSP's model, and they need to be re-mapped, not just copied.
Solution
Treat it as a data-modeling project in four phases.
1. Inventory what you actually have.
Pull the real footprint before you plan anything. A quick way to list your custom fields per object:
# Requires Salesforce CLI (sf)
sf sobject describe --sobject Opportunity --target-org myOrg \
| jq '.fields[] | select(.custom == true) | .name'
Do the same for Account, Contact, npe03_Recurring_Donation_c, and any custom objects. Then check what's genuinely used — a field with 2% of the population across ten years is a migration candidate for deletion, not migration.
2. Map old model → new model. Build an explicit field-mapping sheet: source object/field → target object/field → transformation rule. This is where you decide what's a "must move" (donation history, recurring commitments, core reports) vs. "leave behind" (that 2019 workaround field).
3. Clean before you move. De-dupe households, close dead integrations, resolve ownerless records. A migration will faithfully replicate every bit of mess unless you clear it first.
4. Migrate to a sandbox first, phased, away from year-end. Never do the first run in production. Full sandbox → validate → dry-run the load → reconcile counts → then plan the production cutover on a date you choose.
Example
A minimal reconciliation check after a trial load — verify totals match so a broken mapping doesn't silently drop gifts:
-- Source (NPSP): total closed-won donation amount
SELECT SUM(Amount) total, COUNT(Id) cnt
FROM Opportunity
WHERE IsWon = true
-- Target (Nonprofit Cloud): same population, new model
-- Compare total + count. A mismatch = a mapping or filter bug,
-- NOT "close enough". Investigate before cutover.
If SUM(Amount) and COUNT(Id) don't line up between source and target, stop and find out why. "Off by a few thousand dollars" in a trial load becomes a wrong number on the board report after cutover.
The same principle applies to recurring donations: reconcile the count of active npe03_Recurring_Donation_c records and their expected annual value against the migrated commitments before anyone trusts the new system.
Pitfalls
Treating it as an upgrade. It's a different product and data model. Planning it like a version bump is how projects derail.
Migrating the mess. Skipping the cleanup step just gives you more expensive versions of the same problems.
No reconciliation step. If you don't verify record counts and totals against the source, silent data loss ships to production.
Testing only the happy path. Split gifts, in-kind donations, multi-payment pledges, and soft credits are where mappings break — test them explicitly.
Ignoring adoption. The data can migrate perfectly and the project still fails if staff aren't retrained on the new screens.
Waiting to feel forced. Every new custom field you add before migrating makes the eventual move harder, not easier.
Further reading
If you'd rather map your specific org's model and timeline with people who've done this migration before, that's the kind of planning we help nonprofits with at Maintask.
Top comments (0)