Skip to main content

Salesforce NPSP Migration Map

Published: Last updated: Reviewed:

TLDR

When a nonprofit is facing the Salesforce NPSP to Agentforce Nonprofit transition, formerly the Nonprofit Cloud transition, the real work is not exporting records. It is mapping the current data model, automations, and reporting structure to decide what should move, what should be rebuilt, and whether a purpose-built platform is the better long-term fit.

Why This Map Exists

If your nonprofit is on Salesforce NPSP today, the transition to Agentforce Nonprofit, formerly Nonprofit Cloud, can feel like a technical project. In practice, it is a business process project. The source of risk is not the export button. The risk is that your team has built years of donor, grant, and finance logic into a Salesforce org that now needs to be translated into a different structure.

This map is designed to help you do two things before you sign a migration statement of work:

  1. Inventory what actually exists in your org.
  2. Decide whether the work is a migration, a rebuild, or a sign that you should evaluate a different platform entirely.

That distinction matters. A clean org with limited customization can often be migrated with modest effort. A heavily customized org with multiple automations, custom objects, and reporting dependencies can turn into a long consulting engagement with no clean end state. The point of the map is to surface that reality early, when the options are still open.

For a mid-sized nonprofit, the most useful mindset is operator-first, not platform-first. Do not ask, “How do we preserve Salesforce?” Ask, “How do we preserve donor history, grant tracking, restricted fund visibility, and compliance reporting with the least operational drag?”

Inventory the Current Salesforce Footprint

Start by listing the building blocks in the current org. Do not rely on memory. Pull the configuration, export the metadata where possible, and ask each functional owner what they actually use.

Salesforce itemWhat to captureWhy it matters
NPSP Accounts and ContactsHousehold structure, organization links, primary relationships, communication preferencesThese records usually become the core donor/contact model
OpportunitiesGift type, amount, close date, stage, campaign, primary contact, general ledger mappingThis is where donation and pledge history lives
Recurring DonationsFrequency, start date, installment behavior, pause/cancel logicRecurring gift logic often breaks if it is treated as plain history
CampaignsAppeal names, source codes, revenue attribution rulesCampaign history helps preserve fundraising reporting
Affiliations and RelationshipsIndividual to organization links, spouse/partner ties, committee rolesThese relationships often hold institutional knowledge
Custom objectsGrant-specific, event-specific, finance-specific, or board-specific objectsCustom objects are where migrations get expensive
Reports and dashboardsInputs, filters, folder ownership, schedule frequency, recipientsA report that cannot be reproduced is a hidden loss
Flows, Process Builder, workflow rulesTrigger conditions, field updates, approvals, notificationsAutomation rarely maps one-to-one
IntegrationsAccounting, email, forms, fundraising, document storage, BI toolsEach integration can add scope to the migration

Do the same for permissions, record types, sharing rules, validation rules, and duplicate management. These are easy to ignore until users go live and discover they cannot see what they need or cannot enter data in the same way they used to.

If a field, automation, or object is owned by a single consultant or one internal admin, mark it as a risk. Anything that depends on tribal knowledge is expensive to recreate because the migration team has to reverse engineer it before it can be rebuilt.

Salesforce NPSP Migration Map

A practical mapping guide for nonprofits deciding whether to migrate from Salesforce NPSP or Agentforce Nonprofit into a purpose-built system. It shows how to inventory exports, custom objects, reports, workflows, and relationships before any rebuild begins. Delivered by email.

We'll email the resource and a short follow-up sequence. Unsubscribe any time.

Frequently asked

Frequently Asked Questions

It is a working document that lists the Salesforce objects, custom fields, reports, flows, integrations, and record relationships in your current org and shows how each one maps into the target system. The goal is not just to move data, but to preserve the business logic your team relies on.
No. Most nonprofits should migrate active donor records, active grant records, key notes and activities, and the reporting structures that staff use every week. Historical clutter, obsolete automation, unused custom objects, and old test data usually add cost without adding value.
Use the map to estimate rebuild effort. If your org depends on custom objects, consultant-built automations, and fragile reporting workarounds, the migration cost can make a purpose-built nonprofit platform more practical than rebuilding Salesforce again.