NPSP to Nonprofit Cloud Migration: What Nonprofits Should Know Before They Move

1. Do You Actually Have to Move?

Not yet, and anyone selling you a migration against a deadline is selling you a deadline that doesn't exist. Here are the facts as of October 2026. Salesforce stopped adding new features to NPSP in March 2023, when it launched Nonprofit Cloud. NPSP is still available and still supported — meaning Salesforce will help with problems, not that it's still improving. There is no announced end-of-life date. What has changed is the front door: brand-new nonprofits signing up today are pointed to Agentforce Nonprofit, the new name for Nonprofit Cloud, not to NPSP.

So the honest question isn't "when is the deadline?" It's "is NPSP still the right home for where we're going?" A frozen product doesn't break overnight, but every year you build more on it, the eventual move gets bigger.

Signs it's time to start planning:

• You want features that only exist in the new product — modern program and case management, guided intake forms, built-in AI tools.
• You're about to make a big investment in your current setup anyway, like a redesign or a new integration. Building it twice is the expensive option.
• Your NPSP org is already cluttered with years of workarounds, and a clean start sounds more like relief than risk.

Good reasons to wait:

• NPSP is doing its job, your staff are comfortable, and nothing on your roadmap needs the new product.
• You're in the middle of a campaign, audit, or staff change. A migration needs your people's attention, not just a vendor's.
• An app you can't live without doesn't support Nonprofit Cloud yet (more on that in section 6).

2. Why It's a Move, Not an Upgrade

NPSP is an add-on: a set of packages installed on top of standard Salesforce, bringing their own objects and automation. Nonprofit Cloud is built into Salesforce itself, with a different data model underneath. You can't flip one into the other — the two can't run side by side in the same org, and Salesforce recommends implementing the new product in a fresh org. Think of it as moving house: your belongings come with you, but every room is laid out differently, so nothing goes back exactly where it was.

How the main pieces translate:

Every row in that table is a translation job, not a copy job. Your data comes across, but it gets reshaped on the way in — and every report, automation, and integration that pointed at the old shape has to be pointed at the new one.

3. Households Are the Biggest Change in Thinking

If your team has used NPSP for years, "household" means one thing: a Household Account that holds the family's contacts and rolls up their giving. In Nonprofit Cloud, every person is their own account, and the household is a separate group record that ties them together. Most of the surprises in a migration live here — in how households get created, who is allowed to see them, and what happens behind the scenes when a new one appears.

What to plan for:

• Decide how each NPSP household becomes a household group, and how the people inside it become Person Accounts. Do a test run on real data before you commit.
• List every place households get created: staff screens, online forms, imports, integrations. Each one needs to be rebuilt and tested.
• Check who can see household records — especially on public websites and portals, where visitors aren't logged in.

4. Your Automation Has to Be Rebuilt — Not Copied

A lot of what makes NPSP feel helpful is automation you never see: it creates households when you add a contact, totals each donor's giving, and keeps names and addresses in sync. That automation is part of the NPSP packages, so it doesn't come with you. Nonprofit Cloud has its own built-in features for some of it, and anything your organization added on top — custom flows, code, scheduled jobs — has to be rebuilt to fit the new data model.

How to approach it:

• Make a full inventory first: every flow, scheduled job, and piece of custom code, plus the NPSP behavior your staff quietly rely on.
• For each item, decide: does Nonprofit Cloud already do this, do we rebuild it, or do we drop it? Some of it will turn out to be workarounds nobody needs anymore.
• Rebuild for the volume you'll have in five years, not the volume you had when NPSP was installed.

5. Use the Move to Fix Who Sees What

Permissions in an old org tend to grow like a junk drawer: a profile cloned for one new hire, a sharing rule added in a hurry, access nobody remembers granting. A new org is the cheapest moment you will ever have to fix that. You're setting up access from scratch anyway, so design it on purpose — starting from "nobody sees anything" and opening up only what each role needs.

Questions to answer before you build:

• Which roles exist in your organization, and what does each one genuinely need to see and edit?
• What sensitive information do you hold — income, health, immigration status, children's records — and who should see it?
• What do volunteers, partners, and portal users see, and what must they never see?

6. Check Your Other Apps Before You Commit

Most nonprofits run Salesforce alongside other tools: online donation forms, email marketing, payment processors, accounting software, texting apps. Many of them were built to talk to NPSP's data model. Because Nonprofit Cloud stores people, households, and gifts differently, an app that works perfectly today may not work in the new org — or may need a different version, a new connector, or custom work.

The checklist:

• List every app and integration that reads or writes Salesforce data — including the ones only one staff member knows about.
• Ask each vendor directly: "Do you support Nonprofit Cloud, and does that cover our setup?" Get the answer in writing.
• For anything custom-built, budget a rebuild. It's pointing at objects that won't exist in the new org.

7. A Realistic Migration Roadmap

Every migration is different, but the shape is always the same. One published case study describes an international nonprofit's move taking about six months. The phases below are where that time goes — and where things usually go wrong.

The phases:

• Assess — inventory your data, automation, apps, and reports. Goes wrong when: nobody asks the staff what they actually use.
• Design — map each NPSP piece to its Nonprofit Cloud home and decide what to drop. Goes wrong when: the plan is "copy everything."
• Build — set up the new org, security, automation, and integrations. Goes wrong when: it's built on sample data instead of your real mess.
• Test-load data — move a full copy of your data into a test environment, more than once. Goes wrong when: households and gift history are checked by eye instead of by count.
• Staff testing — the people who use Salesforce daily run their real tasks in the new org. Goes wrong when: it's squeezed into the last week.
• Go-live — final data move, switch-over, and a plan for undoing it if needed. Goes wrong when: there's no plan B.
• Retire the old org — keep it read-only for a while, then close it. Goes wrong when: it's switched off before anyone has checked last year's numbers.