Salesforce Consulting · Cornerstone

NPSP to Agentforce Nonprofit: the 2026 migration guide for Australian not-for-profits

NPSP to Nonprofit Cloud migration for Australian not-for-profits: what changed, whether to move at all, how the data models differ, and how a migration runs.

Shubham Shrivastava — Quantum Associates

· 8 min read

Since December 2025, the product previously called Nonprofit Cloud has been called Agentforce Nonprofit, and a lot of Australian not-for-profits have been told that an NPSP to Nonprofit Cloud migration is now urgent. It is not urgent. It may well be the right move for your organisation, but the urgency is manufactured, and the first thing a senior practitioner owes you is that distinction.

The answer up front: there is no published NPSP end-of-life date, so nobody can honestly sell you a deadline. Migrate when the new data model solves a problem you actually have — program delivery, case management, outcomes reporting — not because a product got renamed. If NPSP is quietly doing its job for fundraising and nothing else, staying put for another year or two is a defensible, adult decision.

What actually changed, and what did not

Three things are true at once, and vendors tend to blur them.

Salesforce stopped developing NPSP in March 2023. Feature development ended. The Nonprofit Success Pack remains available and supported, but it receives no new features. That is a slow signal, not a cliff.

Salesforce has not published any NPSP retirement or end-of-life date. None. Not a year, not a quarter. If a partner or reseller tells you that NPSP switches off on a particular date, ask them to show you the Salesforce notice. They cannot, because it does not exist. Treat that as the tell it is, and be sceptical about the rest of their scope while you are at it.

The December 2025 rename moved nothing. Nonprofit Cloud became Agentforce Nonprofit, under the umbrella brand Agentforce 360 for Nonprofits. Your NPSP org was not renamed, your records were not moved, and no configuration changed. It is marketing architecture, not system architecture.

One genuine change does affect new and expanding organisations: since December 2025, the Power of Us program no longer grants NPSP. Qualified nonprofits receive ten Enterprise Edition licences, and they choose either ten Agentforce Nonprofit or ten Sales and Service Cloud. Worth clearing up a persistent myth here: there has never been such a thing as an “NPSP licence”. NPSP is a set of managed packages installed on top of Sales Cloud licences. That matters, because it means the licensing conversation and the data model conversation are separate, and only one of them has a real deadline attached.

A smaller signal, but a directional one: Salesforce is retiring 24 certifications on 1 February 2027, with last registration on 24 July 2026 and the last exam on 31 August 2026. The Nonprofit Success Pack Consultant certification is on that list. Certifications already earned remain valid. Retiring a credential is not the same as retiring a product, but vendors do not build exam pipelines for things they intend to invest in.

Should you do an NPSP to Nonprofit Cloud migration at all?

Honest criteria, in the order I would apply them.

Strong reasons to move:

  • You deliver programs and services, not just fundraising. If you are tracking who is enrolled in what, what was delivered, and what changed for the client, the new model was built for that and NPSP never was.
  • You are running case management in custom objects, spreadsheets or a separate system, and the seams are costing you.
  • You need outcomes reporting for government or philanthropic funders and you are currently assembling it by hand each quarter.
  • You are already facing a major rebuild for some other reason. If you are going to pull the org apart anyway, do it once.
  • You are a new organisation or standing up a new org, where there is no migration at all, only an implementation.

Good reasons to stay on NPSP, for now:

  • You are primarily a fundraising organisation and NPSP handles donations, households and soft credits perfectly well.
  • You have heavy customisation on top of NPSP that works, is understood, and would have to be rebuilt from scratch.
  • You have no internal capacity this financial year. A migration is not something you squeeze in around an appeal.
  • Your data is in poor shape. Migrating mess produces cleaner mess. Fix the data first; you will need to anyway.

“Not yet” is a real answer. The cost of waiting is that you keep running on a platform with no new features. The cost of moving badly is considerably higher. If you want the feature-by-feature comparison before deciding, we have written it up separately in NPSP versus Agentforce Nonprofit.

Where the two data models part ways

This is where migrations actually stall, and it is worth understanding before you take a quote.

NPSP is built around Household Accounts and Contacts. A person is a Contact, hung off an Account that represents their household, with a layer of NPSP automation keeping the relationships and rollups in order. It is a fundraising model, and for fundraising it is good.

Agentforce Nonprofit is built around a different set of primitives:

  • Person Accounts rather than the household-and-contact pairing. This is not a field rename. It is a different record architecture with different sharing, different reporting and different integration behaviour.
  • Program Management, where a Program has Program Enrollments recording who is participating in what, over what period.
  • Benefit Disbursements, which record actual service delivery — the visit, the meal, the session, the payment.
  • Case Management and Outcome Management as first-class structures rather than things you bolt on.

The practical consequence: there is no lift-and-shift path. Every NPSP concept has to be re-expressed, and some of your data does not map cleanly to anything. Historical activity records are the classic example. In one migration I delivered with the implementation partner for an Australian community-care provider, 17,248 legacy task records had to be converted into Benefit Disbursement records, because that is where service delivery now lives. Tasks are free text; Benefit Disbursements are structured. Bridging that gap is analysis work, not data-loader work.

Scope creeps from the field level too. On that same engagement, the Contact object alone carried 314 fields. Every one of them needed a decision: map it, drop it, or merge it.

How a migration actually runs

Four phases, in this order, with no shortcuts that survive contact with reality.

1. Analysis and mapping. Object by object, field by field. What exists, what is used, what is duplicated, what dies here. The deliverable is a mapping document that a sceptical person can argue with. Most of the risk in the project is retired in this phase, which is exactly why under-quoted projects skimp on it. Our NPSP data migration checklist covers the field-level detail.

2. Rehearsal in a sandbox. Full-volume, end to end, more than once. The first rehearsal always fails somewhere. The purpose of rehearsal is to find out where, on a day when nothing is at stake, and to produce a repeatable load sequence with known timings.

3. Staged cutover. For anything beyond a small org, move in cohorts rather than attempting a single weekend big-bang. On the community-care migration, we cut over by staff cohort, with delta loads between cohorts to carry across records created in the legacy system while the next group was still working there. It is more engineering, but it keeps frontline service running. The mechanics are worth understanding in detail before you commit — see how a staged cutover works.

4. Reconciliation. Counts, spot checks, and sign-off by the people who own the data. Not by the consultants. For reference, the reconciled scope on that engagement was 2,313 people, 625 organisations, 2,097 cases and 2,519 contact-detail records, plus 201 home-visit risk assessments carrying 4,645 question responses, loaded with zero failures. That last number is a product of rehearsal, not luck. The full write-up is in the NPSP to Nonprofit Cloud migration case study.

What goes wrong

  • Discovery is under-scoped. The quote assumes a clean model. Field 240 of 314 turns out to hold twelve years of unstructured notes that someone depends on.
  • Data quality is discovered late. Duplicates, orphans and broken relationships surface during the first rehearsal, and the timeline absorbs the repair work.
  • Person Accounts are treated as a toggle. They are an architectural decision with consequences for integrations, sharing and every report you own.
  • Integrations are forgotten. Your donation platform, mail tool, finance system and rostering tool all point at the old model.
  • Reporting is left until last. Users judge a migration by whether their reports still work. Rebuild the critical ones before cutover, not after.
  • Nobody owns the decisions. Consultants can map data. Only your organisation can decide what a Program is.

What it takes from your own team

This is the honest part that quotes rarely include. You will need a decision-maker who can settle data-model questions in days rather than weeks, at least one person who genuinely knows the history of your data, subject-matter experts to define programs and service types, testers from the frontline rather than from the executive, and time for training that is scheduled and protected rather than hoped for.

If your organisation cannot commit that, delay the project. A migration with an absent client is the most reliable way to burn a budget. The same principle applies to the cost side of the equation: the variable that moves the number most is your own readiness.

How to choose help

Ask any prospective partner four things. Have you completed an NPSP to Nonprofit Cloud migration end to end, and may I speak to that client? How do you handle historical activity data that has no home in the new model? What does your rehearsal approach look like, and how many full-volume rehearsals are in the quote? And — the diagnostic question — when is the NPSP end-of-life date? Anyone who answers that last one with a date is either misinformed or selling you fear. The correct answer is that Salesforce has not published one.

Prefer the partner who spends the first conversation asking about your programs rather than demonstrating agents.

If you are weighing this decision and want a straight read on whether to move now, later, or not at all, get in touch. Thirty minutes with someone who has done the work is usually enough to tell you which of the three you are looking at.

Next step

Want to talk about this with a senior partner?

30 minutes, no pitch, no deck — just a working conversation about how this applies to your situation.