If you administer an NPSP org, the fastest way to understand why Salesforce calls the move to Agentforce Nonprofit — the platform formerly named Nonprofit Cloud — a reimplementation is to put the two data models side by side. Nothing maps one-to-one. This is the object-by-object walkthrough — drawn from Salesforce’s own Agentforce Nonprofit Migration Guide (v2.0, June 2026) — of what changes, and what each change means in practice for your donor data.
The NPSP vs Agentforce Nonprofit object map
The headline transformations, in one table:
| NPSP architecture | Agentforce Nonprofit architecture | What the change really is |
|---|---|---|
| Contact | Person Account | Identity transformation, not a rename |
| Household Account | Party Relationship Group | Household restructuring — and a choice about which households migrate at all |
| NPSP Relationship | Contact-Contact Relationship | Relationship type and direction mapping |
| NPSP Affiliation | Account-Contact Relationship / Constituent Role | Preserving historical affiliations |
| NPSP Address | Contact Point Address | Address history and seasonal preferences |
| Opportunity / Payment | Gift Transaction (+ Opportunity for open solicitations) | Splitting financial records by what they represent |
| Recurring Donation | Gift Commitment + schedules | Keeping live donor arrangements alive |
| GAU / Allocation | Gift Designation + junction records | Fund-accounting continuity |
| Campaign hierarchy | Campaigns + Outreach Source Codes | Attribution restructuring |
| Engagement Plan | Action Plans | Process redesign, not a data copy |
Constituents: Contacts become Person Accounts
The foundation of Agentforce Nonprofit is the Person Account — a single record that is both an Account and a Contact. Every NPSP Contact must be transformed into one, which is why Salesforce strongly recommends a new org: enabling Person Accounts in a live NPSP org is a one-way change the guide explicitly warns against. For your migration, that means every custom Contact field, every Contact-triggered flow, every integration that writes Contacts needs a mapping decision — and duplicate donors become identity collisions if you don’t resolve them first.
Households: not every household should migrate
NPSP’s Household Account becomes a Party Relationship Group — but the guide recommends asking a sharper question first: which households does your organization actually use? Single-person households, duplicate structures, and households with no giving history or operational purpose are candidates for consolidation or archiving rather than migration. The move is a chance to shed structure you never needed.
Affiliations: the one-ACR collision problem
Here is the kind of detail that separates a data model diagram from a migration plan. NPSP lets a person hold multiple Affiliations to the same organization — board member 2015–2018, volunteer 2019, employee today. The target Account-Contact Relationship model allows one ACR per person-organization pair. Historical multi-role affiliations cannot all become separate ACRs; the guide points to Constituent Role records for some of those cases. If your org tracks board service history, you need a design decision here, not a field mapping.
Gifts: the hardest part, per Salesforce
Salesforce’s guide calls gift migration “one of the most complex and time consuming portions” of the entire move — because NPSP records donations as Opportunities and Payments, while Agentforce Nonprofit splits financial reality across purpose-built objects. The destination depends on what each record actually represents:
| Your NPSP record today | Candidate destination |
|---|---|
| Completed one-time donation | Gift Transaction |
| Active recurring donation | Gift Commitment + Schedule + Transactions |
| Open major-gift solicitation | Opportunity |
| Multi-payment pledge | Gift Commitment + Transactions |
| Refund | Gift Refund |
| GAU allocation | Gift Designation records |
| Soft credit | Gift Soft Credit |
These are candidate patterns, not automatic mappings. Two orgs with identical objects can need different rules — if you track historical donations as closed Opportunities without Payment records, no tool can assume each one represents a completed transaction without understanding your recording conventions. Classification before transformation is the whole game. And recurring donations deserve special fear and respect: active donor arrangements, payment-processor integrations, and open installments must survive the cutover without a missed or duplicated charge.
Addresses, campaigns, engagement plans
Addresses: NPSP’s Address object — with its seasonal addresses and history — maps to Contact Point Address, and the move is better than it sounds: the new model supports multiple addresses with configurable overwrite behaviors and seasonal support, and automation now keeps the Person Account’s billing address in sync with the relevant Contact Point Address. The migration work is attaching historical addresses to the right accounts so none of that history is lost. Campaigns: the hierarchy survives, but attribution moves to Outreach Source Codes, which is a restructuring of how you answer “which appeal raised this gift?” — and campaign revenue rollups change too, since gifts are no longer Opportunities (more below). Engagement Plans become Action Plans — the guide treats this as a process redesign, because the constructs differ enough that copying data would copy the wrong thing.
The rollup problem nobody mentions
Every NPSP org leans on rollup fields — total giving, last gift date, largest gift — and every consultant demo glosses over what happens to them. In Agentforce Nonprofit, NPSP’s rollups are replaced by Data Processing Engine (DPE) definitions: per Salesforce’s Fundraising Implementation Guide, donor data points like Last Gift Date, Highest Gift Amount and Best Gift Year come from DPE jobs, campaign revenue rolls up into an Outreach Summary record populated by a DPE definition the guide says should run nightly, and a built-in RFM score (recency · frequency · monetary value) ranks donors natively. Two practical consequences: your custom NPSP rollup fields need a mapping decision like everything else, and anything downstream of them — reports, automations, integrations that read Total Gifts — inherits that decision. Budget design time here; it is invisible in the object map and very visible at go-live.
Programs: PMM’s Service becomes a Benefit stack
If you run the legacy Program Management Module (PMM), there is a second migration inside your migration. PMM’s flat Service object — what you offer, connected directly to a client’s delivery record — becomes a structured stack in Agentforce Nonprofit, per the Program Management Implementation Guide: a Benefit Type (the category, like “Counseling”) with a Unit of Measure (like “Hours”); a Benefit in a strict master-detail under its type and specific to a Program; a Benefit Assignment acting as the entitlement record for how many units a participant may receive; and Benefit Disbursements recording actual delivery. One trap the guide calls out: units are not automatically deducted when a benefit is disbursed — if your compliance reporting assumes they are, that behavior must be configured. Program Enrollment and Benefit Assignment both anchor on Person Accounts, which is one more reason the constituent transformation comes first.
NPSP vs Nonprofit Cloud at a glance
Zooming out from objects to platform — the comparison nonprofit teams actually ask for:
| Area | NPSP | Agentforce Nonprofit (Nonprofit Cloud) |
|---|---|---|
| Architecture | Managed packages installed on Sales Cloud | Native industry platform — nothing to install |
| Constituents | Contacts + Household Accounts | Person Accounts + Party Relationship Groups |
| Donations | Opportunities, Payments, Recurring Donations | Gift Transactions, Gift Commitments + schedules |
| Relationships | Affiliations, Relationships | ACRs, Constituent Roles, Actionable Relationship Center graph |
| Rollups | NPSP rollup fields | Data Processing Engine definitions + RFM scoring |
| Automation | Flow, Process Builder era tooling | Flow + OmniStudio + Business Rules Engine + Batch Management |
| Programs | PMM add-on package (Service object) | Built-in Benefit Types → Benefits → Assignments → Disbursements |
| Feature development | Ended March 2023; maintenance only | Active — all new nonprofit innovation ships here |
Platform rows per Salesforce’s Nonprofit Cloud, Fundraising and Program Management Implementation Guides; status row per Salesforce Ben. Most platform services require Permission Set License assignment and configuration — capabilities to implement, not switches.
What this means for your migration plan
Every row in the map above expands into dependency questions in a real org: which flows reference Recurring Donations, which reports depend on NPSP rollup fields, which integrations write Opportunities, which custom fields carry data worth moving. That inventory is measurable before anyone commits to a plan — it’s exactly what our NPSP Migration Readiness Assessment produces. For the strategy view, start with the full NPSP to Agentforce Nonprofit migration guide; for the should-we-even question, read our decision framework.
