Horus Eye · NPSP → Agentforce Nonprofit

The NPSP migration admin’s checklist

A working NPSP migration checklist for the Salesforce administrator or product owner who carries the move from the Nonprofit Success Pack to Agentforce Nonprofit (Salesforce Nonprofit Cloud) — from knowing what you have, through the decisions and the rehearsals, to cut-over and after. Print it, or work it on screen; either way, every ticked box should have evidence behind it.^[2]

Request an Assessment The roadmap & gates

Estimated effortXS hours S a day or two M about a week L weeks XL a workstreamIndicative, relative sizes for a typical mid-size org — your org’s evidence decides. Dates and estimates belong to your implementation partner.

The seven phases of the NPSP migration admin checklist: know what you have, decide, prepare data, rebuild, rehearse and validate, cut over, after go-live — The whole checklist at a glance — seven phases, each exiting on something demonstrated.

Decide, in dependency order

Phase 1 L

Target org strategy first — Person Accounts^[3] cannot be switched off once enabled.
Household model; then each Opportunity record type’s classification; then the gift grain.
Recurring collection method for every active recurring donation; the legacy-recurring path if yours are legacy.
Each vendor’s written confirmation, or a replacement or retirement plan.
A destination for every field without a direct target that your org actually uses.
Which historical totals and reports must survive, and the closed period you will reconcile against.
Program data: migrate what holds data, or archive history (PMM only).
Security, data scope and archive, campaign attribution, duplicate rules during the load, record types, household soft credits.
Every answer recorded with who decided it and when, in one register.

The decision chain in dependency order: target org, households, gift classification, recurring, and the parallel decisions — Phase 1 at a glance: the order the decisions fall in — one recorded answer unblocks the next.

Prepare the data, before any load

Phase 2 L

Resolve each shared-e-mail group: same person, or different people. L
Repair orphaned records, or record the decision to exclude them; complete the values the target requires.
Choose the primary affiliation for contacts that have several; create the missing side of one-sided relationships.
Decide what empty legacy households become; write the archive plan and say where the archive lives.
Build the owner map: NPSP user → target user, with a default owner for inactive users.
Get every in-scope field mapping approved in the mapping workbook^[1].

Rebuild, in the target sandbox

Phase 3 XL

Person Accounts, household groups and the gift objects configured with the approved record types.
Triggers, handlers, Flows and validation rules rewritten on the target objects. L
Rollups and totals rebuilt; reports re-pointed; dashboards rebuilt.
Page layouts, record pages, list views, components and gift-entry mappings rebuilt.
Each kept integration re-pointed and configured.

Rehearse and validate

Phase 4 L

Each migration step previewed first — a preview writes nothing.
Each step run into the sandbox; re-runs add zero records.
The exception queue empty, or every entry accepted by a recorded decision.
Two trial loads reconcile: counts per object; amounts by fiscal year, record type and currency; designations per fund; refunds under their transactions. L
Recurring continuity proven: next date and amount match, one pending installment, nothing created early.
Integration smoke tests pass; UAT signed off by fundraising and finance; each persona passes its access check.
The cut-over runbook rehearsed end to end, including back-out before the point of no return.

The Validate stage comparing source and target by count on a sandbox — What phase 4 looks like when it is working: source and target compared by count, on your own sandbox (test org).

Cut over

Phase 5 M

Freeze entry to every in-scope object in NPSP; pause NPSP scheduled jobs.
In the target, pause automatic recurring transactions and auto-lapse; hold rollup runs.
Load users and the owner crosswalk first; run load steps in order — a child step starts only after its parent reconciles.
Reconcile; finance signs off the closed-period totals.
Restore the target’s automation and prove the migration bypass is gone: a test record by an ordinary user fires every rule.
Every go / no-go criterion met and recorded; the executive sponsor authorizes.

The go / no-go criteria page with each criterion and its threshold — Phase 5’s gate on paper: every criterion, its threshold, and its state (example data).

After go-live

Phase 6 S

Hypercare window, owner and exit criteria named.
NPSP kept read-only and licensed for its agreed period (new-org strategy).
Archive verified readable; decommissioning plan for NPSP and its integrations.
A post-migration re-scan of the target, to confirm no NPSP dependency is left.

Sources & further reading

References

1. Salesforce · Agentforce Nonprofit Migration Guide v2.0 (PDF) — The official guide this content follows: platform differences, migration recommendations, and how NPSP features map to Agentforce Nonprofit. ↩︎
2. Salesforce Help · Nonprofit Cloud Migration and Implementation Guides — Salesforce’s index of the migration, implementation, Fundraising and Program Management guides. ↩︎
3. Salesforce Help · Enable Person Accounts for Fundraising — The enablement step — and why it is planned, not casual: Person Accounts cannot be disabled once enabled. ↩︎

“Salesforce”, “Agentforce” and related marks are the property of Salesforce, Inc. Horus Eye is an independent product and is not affiliated with, endorsed, or sponsored by Salesforce, Inc.

Take it with you as a PDF

Printable download

What you’ll get

The full phase-by-phase checklist — know what you have, decide in dependency order, prepare the data, rebuild, rehearse and validate, cut over, and the after-go-live items — formatted as a printable PDF with tick boxes.

Everything in the PDF is on this page too — the download is for printing, sharing with the team, and the project binder.

Download the checklist

Protected AI — the Trust Layer

Every AI read in Horus Eye is metadata-first: built from an allowlist, sanitized by pattern, made through one audited gateway and checked by an output firewall on the way back — and AI is off by default, per org. Every request carries an audit id and an AI Data Scope manifest you can open.

See the Trust Layer

Want this checklist pre-filled for your org?

Horus Eye

An assessment turns the generic checklist into your org’s own: which items are already done, which are open, and the evidence behind each.

Try Horus Eye Free Request an Assessment All Horus Eye pages

Free start · 250 credits for 60 days · no card required · scans are free