NPSP to Agentforce Nonprofit: What Changes, What Breaks, and How to Sequence the Move

Your development director asks for ten more licenses for the new regional office. You open the Power of Us portal the way you have every year since 2019, and the Nonprofit Success Pack option is not on the page. What sits there instead is ten free Agentforce Nonprofit CRM licenses, plus ten free Agentforce Sales and Service licenses. NPSP is not on the menu any more.

That change landed in December 2025, and it is the clearest signal Salesforce has sent about where nonprofit orgs are heading. It is also the one most often misread. Nothing about it retires the org you already run, and nothing about it starts a countdown on your data. What it did was close the front door.

What Salesforce has said, and what it has not

Three facts, ordered by how often they get garbled in a board meeting.

NPSP is frozen, not dead. Salesforce launched Nonprofit Cloud in March 2023 and announced the end of innovation for its nonprofit managed packages, NPSP included, the year after. End of innovation means no new features. It does not mean no support. Your org still gets maintenance, still upgrades with each release, and still works on Monday morning.

There is no announced end of life and no announced end of sale. People keep inventing one. Salesforce has not published a date, and until it does, anyone selling you a migration against a deadline is selling you a deadline they made up.

Nonprofit Cloud and Agentforce Nonprofit are the same product. The rename happened as Salesforce folded its industry clouds under the Agentforce brand. If a 2024 blog post says Nonprofit Cloud and a 2026 one says Agentforce Nonprofit, they are describing the same objects. Read both.

So you are not being evicted. You are living in a building where the landlord stopped doing renovations, and every new tenant is being shown a different building. That is a real strategic problem on a three to five year horizon, and it is not an emergency this quarter. The distinction matters, because the migration is expensive and doing it badly under invented time pressure is how nonprofits lose twenty years of donor history.

The first decision is the only irreversible one

Before you map a single field, settle Person Accounts.

Nonprofit Cloud is built on the same Industries architecture as Health Cloud and Financial Services Cloud, and it puts the individual constituent at the center of the model using Person Accounts. Salesforce lists them as a prerequisite you configure before you turn on Fundraising or Program Management. They are not strictly required for Grantmaking, but for everything else the product assumes them.

Here is the part that should stop you: once Person Accounts are enabled in an org, they cannot be disabled. Ever. There is no toggle back, no support case, no cleanup script. It is one of a very small number of genuinely permanent decisions the platform lets an admin make.

NPSP solved the same problem the other way. Its household model gives every Contact an Account of a Household record type, created and maintained by the package. One person means two records that the package keeps stitched together. It works, it has worked for a decade, and every report, list view, and integration your org owns has an opinion about which of those two records it points at.

Agentforce Nonprofit fuses those into one Person Account record and moves household grouping out to Party Relationship Groups, a separate structure that lets a person belong to a household, a giving circle, and a board committee without any of those memberships fighting each other. That is a better model. It is also a different one, and the difference reaches every corner of the org.

Test this in a sandbox whose fate you do not care about. Enabling Person Accounts in a full copy sandbox to see what breaks is the correct move. Enabling them in the developer sandbox that your consultant also uses for the payment gateway rebuild is how you lose a sandbox for a quarter.

Opportunity stops being the donation

This is where most migration estimates fall apart, because it is where the assumption breaks that a migration is a field mapping exercise.

In NPSP, a donation is an Opportunity. Installments are npe01__OppPayment__c. A monthly donor is npe03__Recurring_Donation__c generating Opportunities forward. Fund accounting runs through General Accounting Units and Allocations. Everything you report on is built from standard sales objects that were bent into fundraising shapes.

Agentforce Nonprofit does not bend Opportunity. It ships a purpose-built Fundraising data model with more than thirty standard objects, and the donation lives on GiftTransaction. Here is the mapping that matters:

GiftCommitment is the object I would look at first, because it is the clearest evidence that this model was designed by people who have run a development office. One record covers a recurring gift, a pledge, an accepted grant proposal, and a planned gift. Its Status moves through Draft, Active, Paused, Failing, Lapsed, and Closed. It carries ExpectedTotalCmtAmount, TotalPaidTransactionAmount, NextTransactionDate, and WrittenOffAmount as real fields rather than as three formula fields and a scheduled batch job you wrote in 2021.

Failing deserves a sentence of its own. NPSP had no first-class way to say "this monthly donor's card is declining and nobody has called them." You built that with a custom picklist, or you did not build it and found out at the annual review. Here it is in the schema.

The tradeoff is honest. A richer model means more objects, and more objects mean more security config and more training. GiftTransaction rows created by a commitment sit in Unpaid status until the payment arrives, which means expected revenue and received revenue live in the same table. Every report your finance team has ever written assumes those are different tables.

The rollup change your fundraising team will notice first

I have watched this one land badly more than once, so I will be blunt about it.

NPSP gives you Customizable Rollups. Total Gifts This Year, Largest Gift, First Gift Date, Last Gift Amount, all of it calculated by the package and, for most orgs most of the time, current. A gift officer opens a donor record before a meeting and reads a number they trust.

Agentforce Nonprofit calculates the equivalent through Data Processing Engine. Fundraising ships three template definitions, DonorGiftSummary, OutreachSummary, and GiftDesignation, and none of them do anything until you clone them, activate the copies, and build a schedule-triggered Flow that runs them. Salesforce is explicit that these calculations are not real time by design, and points you at the Data Processing Engine considerations before you decide how often to run them.

That is a defensible architecture. Batch aggregation over a proper data model scales better than a package recalculating roll-up summary fields on every save. It is also a behavior change your users will hit within a week, in the specific form of a gift officer taking a $50,000 ask into a meeting off a donor total that was accurate at 2am and stopped counting the online gift that came in at 9:15.

Plan for it in three places. Decide the DPE schedule against the giving calendar, not against a default, because year-end needs a different cadence than July. Tell the fundraising team in words, before go-live, that the totals on the page have an as-of time. And put that as-of time on the page layout where they can see it, rather than leaving them to discover the lag by being wrong in front of a donor.

Program management gets the objects you have been faking

If you run the Program Management Module on top of NPSP, the migration story here is better than the fundraising one.

The naming shifts first. What PMM calls a Service, Agentforce Nonprofit calls a Benefit, and the related objects follow that word. Program Engagement becomes Program Enrollment. Program and Program Cohort keep their names.

The interesting part is what got added. Benefit Assignment, Benefit Session, Benefit Schedule, Benefit Type, and Program Cohort Member have no PMM equivalent, and together they close a gap every program director knows. PMM tracked service deliveries, meaning things that happened. It had no clean way to record that a participant was assigned a benefit that was never delivered. So teams faked it with a status picklist on a custom object, or they reported on deliveries and quietly had no visibility into the participants who fell through.

Agentforce Nonprofit separates assignment from disbursement. Assigned but not disbursed is now a query, which means it is now a report, which means it is now a weekly list of the people your program did not reach. For an outcomes-funded organization, that single distinction can be worth the migration on its own.

What you give up

Migration posts written by people selling migrations tend to skip this part.

The first loss is fifteen years of accumulated answers. When an NPSP rollup misbehaves, the fix is usually one search away, because thousands of admins have already hit it and written it down. The Agentforce Nonprofit corpus is younger and thinner. You will spend more time reading documentation and less time finding somebody who already solved your exact problem, and that difference shows up as staff hours nobody budgeted.

The second is the long tail of small package conveniences. Go through your org and check what your team actually touches: NPSP's address management with its household sync and seasonal addresses, engagement plan templates that spawn a standard set of tasks, donor levels that reassign themselves as giving changes. Some of these have a clean equivalent in the new model, some become a Flow you now own, and some become a habit your staff has to give up. Find out which is which before the design workshop, not during user acceptance testing.

The third is cost, and it is the one to take to your finance committee early. NPSP was a free managed package installed on licenses you already held. Agentforce Nonprofit is a licensed product, and Power of Us covers ten users. Organizations with thirty staff on Salesforce should price the target state before they price the project, because the annual number can be larger than the one-time number.

None of this argues against migrating. It argues against migrating on a schedule set by somebody who has not costed the second year.

This is a re-implementation with a data conversion attached

There is no push-button path from NPSP to Agentforce Nonprofit, and there will not be one. The two products do not share a data model, so a migration tool would have to be a re-implementation engine. Third-party tooling exists to move data and metadata between orgs, and some of it is genuinely good, but it moves records once you have decided what the target looks like. It does not decide for you.

Budget and staff it as a new implementation. That means design workshops, a fresh object and security model, rebuilt reports and dashboards, retrained staff, and a data conversion at the end rather than at the start. Teams that treat it as an upgrade discover in week six that nobody owns the decision about how twenty years of soft credits map onto GiftSoftCredit, and the project stalls there.

A sequence that has held up:

1. Inventory before you design. Every custom object, every automation, every integration user, every scheduled job, every report that a human actually opens. Most orgs find that a third of their reports have not been run in two years, and that is a third you do not have to rebuild.
2. Settle Person Accounts in a throwaway sandbox. Confirm what breaks. Write it down.
3. Design the target org fresh. Do not port NPSP customizations that only existed to work around NPSP. A surprising amount of your config is scar tissue.
4. Convert history last, in slices. Constituents, then designations, then commitments, then transactions. Reconcile totals after each slice rather than at the end, because a mismatch found after four objects have loaded is a mismatch you can still trace.
5. Run parallel through one giving cycle if you can afford it. If you cannot, cut over immediately after year-end close, never before it.

The inventory step nobody does early enough

Your integrations are the schedule risk, not your data.

Almost every nonprofit AppExchange product built before 2023 writes to NPSP objects. Payment processors create Opportunities and npe01__OppPayment__c rows. Wealth screening tools stamp fields on Contact. Email platforms sync against the household Account. Event and peer-to-peer fundraising apps assume the NPSP recurring donation shape. Your own Data Loader routines and any custom code do the same.

Ask every vendor one question, in writing, before you commit to a date: do you support the Agentforce Nonprofit Fundraising objects today, and if so, since when. Not "are you planning to." The answer sorts your integrations into three piles, and the third pile is the one that sets your timeline.

Who should move in 2026, and who should not

Move now if you are implementing Salesforce for the first time. There is no decision to make. New orgs get Agentforce Nonprofit through Power of Us, and building on a frozen package in 2026 is choosing a migration for 2029.

Move now if your NPSP org is already being rebuilt. If a program redesign or a merger has you re-implementing anyway, the marginal cost of landing on the current model is far lower than doing it twice.

Move now if the Fundraising model solves a problem you are currently paying for. Complex pledge and planned giving programs are the strongest case. If your development shop has three custom objects and a batch class approximating GiftCommitment, you are already maintaining a worse version of what ships in the box.

Wait if your NPSP org is stable, heavily integrated, and your staff capacity is committed. NPSP is supported. There is no published deadline. Spend 2026 on the inventory and the vendor questions, and take the migration to your board with real numbers in 2027 rather than a rushed one now.

Wait if a single named person is your entire admin capacity. This is not a project one part-time admin absorbs alongside their day job, and starting it that way is how organizations end up mid-migration with two half-configured orgs.

Whichever pile you are in, do the inventory this quarter. Open Setup, export the list of installed packages, the list of connected apps, and the list of active scheduled jobs, and put them in one spreadsheet with a column for who owns each. That document is the first deliverable of a migration, it is useful even if you never migrate, and it takes an afternoon. Everything else in this post is a decision you can only make well once you have it.

About the Author

Dipojjal Chakrabarti is a B2C Solution Architect with 29 Salesforce certifications and over 13 years in the Salesforce ecosystem. He writes and edits salesforcedictionary.com, published by KineticBit Inc., to help admins, developers, architects, and cert/interview candidates sharpen their fundamentals. More about Dipojjal.