The Nonprofit Success Pack is still supported, and Salesforce says it will stay that way, but Salesforce recommends Nonprofit Cloud for new customers. Moving is not an upgrade. Nonprofit Cloud represents people as person accounts, households as grouped business accounts, and donations as gift commitments and gift transactions rather than opportunities and payments. Plan it as a reimplementation, and move when the gains justify a rebuild. No NPSP retirement date has been announced.
Where NPSP and Nonprofit Cloud stand
NPSP is a managed package that adapts Sales Cloud objects for fundraising: contacts grouped into household accounts, donations stored as opportunities, and extra objects for recurring gifts, allocations and payments. Nonprofit Cloud is built into the platform itself and brings fundraising, programs, volunteer management and outcomes together in one product. Salesforce briefly branded it Agentforce Nonprofit from December 2025 and now uses the Nonprofit Cloud name again, which we use here.
Salesforce's nonprofit package page says NPSP is used by thousands of organizations and will continue to be supported, while pointing new customers to Nonprofit Cloud. Read that as a clear direction, not an eviction notice. New nonprofit capability, including the purpose-built AI agents Salesforce has announced, is arriving on Nonprofit Cloud.
How the data model differs
Almost every core record changes shape. The table maps the main NPSP concepts to their Nonprofit Cloud counterparts as Salesforce documents them.
| Concept | NPSP | Nonprofit Cloud |
|---|---|---|
| An individual | Contact, attached to a household account | Person account, which combines account and contact in one record |
| A household | Household account record type | Business account with a party relationship group of type Household, linked by account-contact relationships |
| A one-time gift | Opportunity, with payment records | Gift transaction |
| A recurring gift or pledge | Recurring donation, or an opportunity with scheduled payments | Gift commitment with a gift commitment schedule, fulfilled by gift transactions |
| Where money goes | General accounting unit allocations | Gift designations |
| Credit to others | Soft credits through contact roles and partial soft credits | Gift soft credit records |
| Honor and memorial gifts | Tribute fields or records | Gift tribute records |
| Cultivation work | Opportunity stages | Opportunities linked to the gift commitment they helped secure |
The fundraising split is the change development teams feel most. In NPSP, one opportunity often doubles as both the ask and the money received. Nonprofit Cloud separates the promise, the payments and the purpose, so a five-year pledge becomes one commitment with a schedule and a series of transactions, each inheriting the designations set on the commitment. Reports on retention, lapsed donors and fund totals all have to be rebuilt against these objects.
Person accounts: the decision that shapes everything
Nonprofit Cloud depends on person accounts, and once person accounts are enabled in an org they cannot be switched off. Salesforce also documents that person accounts are not supported alongside NPSP's household model. That combination forces an early choice: build Nonprofit Cloud in a fresh org and migrate data into it, or prepare the existing org carefully so both models do not collide during the transition. Salesforce's migration guides discuss the options; settle this with whoever will support the org long term before any configuration begins.
Person accounts also ripple outward. Web forms, payment processors, email tools and data loads that assume a separate contact and household account need to be checked or replaced, and duplicate rules must be redesigned around a single person record. Ask every connected vendor whether their product supports Nonprofit Cloud objects, not just Salesforce in general.
A practical migration approach
- Stop adding NPSP customization once the decision is made, so the target stops moving.
- Inventory what the org really does: fields in use, automation, reports staff open, and every integration and installed package.
- Clean before moving. Merge duplicate donors and households and retire fields nobody fills in.
- Design households and relationships in the new model, including how salutations and addressees will be generated.
- Map gifts deliberately: which NPSP opportunities become commitments, which become transactions, and how allocations become designations.
- Move recurring gifts with their schedules and processor references, and time the switch so no donor is charged twice or skipped.
- Rebuild reports, dashboards and acknowledgment processes against the new objects, then test them with development and finance staff.
- Load in stages into a sandbox, reconcile totals by fund and fiscal year, and only then plan cutover.
Finance reconciliation is the gate. If migrated giving by designation and year does not match the figures auditors have already seen, stop and fix the mapping before go-live. Keep NPSP data available read-only for a period afterward so staff can answer questions about older gifts.
Not everything deserves the trip. Decades of closed opportunities, old campaign members and one-off event registrations can often be summarized or archived rather than rebuilt record by record, as long as lifetime giving, first and last gift dates and key relationships survive. Agree those rules with the development director and finance lead early, because every record type you choose to carry over adds mapping, testing and load time.
Budget time for people as well as data. Gift officers, gift processors and volunteer coordinators will find familiar screens replaced by new record pages, new gift entry steps and different report types. Short, role-based sessions using your own donors as examples, followed by a few weeks of floor support after cutover, do more for adoption than a single all-staff demo.
When waiting is the better choice
Stay on NPSP for now if it meets your needs and staff trust the data, if key tools such as your donation forms or payment processor do not yet support Nonprofit Cloud objects, or if nobody internally can give the project real time. Avoid starting during year-end giving, a capital campaign or an audit, when finance and development teams have no room to test. A migration squeezed around peak season usually slips into it.
Moving sooner makes more sense when the NPSP org is already heavily customized or badly degraded, since cleanup would amount to a rebuild anyway, or when you need what Nonprofit Cloud adds natively: program and outcome tracking, volunteer management, grantmaking, or Salesforce's nonprofit AI agents. An organization running programs from spreadsheets alongside NPSP fundraising often gains the most, because the move brings both onto one record for each person.
