SfSkills Domains Docs GitHub

Home / architect / npsp-vs-nonprofit-cloud-decision

npsp-vs-nonprofit-cloud-decision

Use this skill when an organization must decide whether to stay on NPSP (Nonprofit Success Pack) or move to Nonprofit Cloud (NPC), evaluate the timeline for that move, and understand what the migration entails at an architectural level.

Open the skill folder on GitHub

NPSP vs. Nonprofit Cloud Decision

Use this skill when a nonprofit organization on Salesforce must evaluate whether to remain on the Nonprofit Success Pack (NPSP) or migrate to Nonprofit Cloud (NPC), and needs a structured framework to make and justify that decision. This skill produces a decision recommendation with rationale; it does not implement the migration itself.

Before Starting

Gather this context before working on anything in this domain:

Core Concepts

1. NPSP Is Feature-Frozen — Not End-of-Lifed

The Nonprofit Success Pack (NPSP) is an open-source managed package that Salesforce acquired via its acquisition of the Nonprofit Starter Pack. In March 2023, Salesforce launched Nonprofit Cloud as the successor product and simultaneously stopped all new NPSP feature development. NPSP remains installable and supported with critical security and bug patches, but no new capabilities will be added. Organizations on NPSP are trading stability for an increasingly widening feature gap against NPC.

The absence of a hard EOL date does not mean NPSP is safe indefinitely. Managed package support lifecycles can be affected by Salesforce API version deprecations, platform changes, and third-party dependency updates. Organizations should treat NPSP as a platform in slow wind-down, not as a stable long-term foundation.

2. Nonprofit Cloud Is a Different Data Model — Not an Upgrade

Nonprofit Cloud is not a newer version of NPSP. It is a separate Salesforce product built on different foundational objects:

This data model divergence is the primary reason no in-place migration path exists. Converting a Household Account org to a Person Account org requires a full data re-architecture, not a configuration change.

3. Migration Requires a Net-New Org and Formal Data Migration

There is no Salesforce-provided tool to convert an existing NPSP org into an NPC org. The migration path is:

  1. Provision a new Salesforce org with NPC licenses
  2. Rebuild all configurations (page layouts, record types, flows, custom objects, integrations) in the new org
  3. Extract constituent, donation, program, and relationship data from the NPSP org
  4. Transform data to match NPC's object model (e.g., convert Household Contacts to Person Accounts)
  5. Load data into the new NPC org using ETL tooling (Data Loader, MuleSoft, Informatica, etc.)
  6. Validate data integrity and run parallel operations during cutover

This is a full reimplementation project, not a configuration migration. Organizations should budget 6–18 months depending on complexity and data volume.

4. Feature Gap and When NPC Wins

NPC offers capabilities unavailable in NPSP:

Organizations that need any of these capabilities have no path to obtain them on NPSP.

Common Patterns

Pattern 1: The "Stay on NPSP" Decision

When to use: Organization has deep NPSP customizations, is operationally stable, has no immediate need for NPC-exclusive features, and has limited implementation budget or internal change capacity.

How it works:

Why not move now: A migration with no business driver creates disruption, cost, and risk without corresponding value. Premature migration is an anti-pattern. The stay decision is valid as long as NPSP meets operational needs.

Pattern 2: The "Move to NPC" Decision

When to use: Organization needs a NPC-exclusive feature (Gift Entry Manager, native Program Management, Grantmaking, deeper AI integration), is undergoing a major org consolidation, or is a new-to-Salesforce nonprofit that has not yet launched on NPSP.

How it works:

Why not wait: Organizations that delay migration accumulate more NPSP-specific technical debt, making the eventual migration more expensive. New Salesforce investments (AI features, Einstein, Agentforce for Nonprofits) are being built exclusively on NPC.

Decision Guidance

SituationRecommended ApproachReason
New nonprofit organization evaluating Salesforce for the first timeImplement Nonprofit Cloud directlyNo migration cost; immediate access to full NPC innovation roadmap
Existing NPSP org, stable, no NPC-exclusive feature need, limited budgetStay on NPSP with a formal re-evaluation triggerNo business driver for disruptive migration; NPSP still receives security patches
Existing NPSP org that needs Gift Entry Manager, native Program Management, or GrantmakingPlan migration to NPCRequired features are NPC-exclusive; NPSP will never receive them
Existing NPSP org undergoing an org consolidation or CRM re-platformConsolidate onto NPCMigration is already required; NPC is the correct destination for a net-new build
Existing NPSP org heavily customized with Apex, CRLP rollups, and third-party packagesConduct migration readiness assessment before decidingComplexity must be quantified; migration is possible but expensive — ROI analysis required
NPSP org with PMM (Program Management Module) installedEvaluate NPC Program Management fit carefullyNPC's native Program Management replaces PMM but has feature parity gaps; validate before committing
NPSP org using Elevate for payment processingNPC migration preferred long-termSalesforce is deepening Elevate–NPC integration; NPSP Elevate support will not evolve

Step-by-step instructions for an AI agent or practitioner working on this task:

  1. Confirm the current platform. Verify the org is on NPSP (installed managed package, API name npsp) and not already on Nonprofit Cloud. Check Setup > Installed Packages. This step prevents recommendations based on a wrong premise.
  2. Assess NPC-exclusive feature needs. Produce a feature requirements list from stakeholder interviews. Map each requirement to NPSP vs. NPC availability. If any requirement is NPC-exclusive, the migration case exists regardless of other factors.
  3. Inventory NPSP customizations and integrations. Document custom fields, Apex triggers, Process Builders, active Flows, installed packages, and external integrations. Score complexity on a low/medium/high scale. High-complexity orgs need a professional migration assessment before a go/stay decision is finalized.
  4. Assess data volume and model complexity. Count Contacts, Household Accounts, Opportunities, Allocations, and Recurring Donations. Map out relationship structures. Large data volumes and complex relationship hierarchies extend migration timelines significantly.
  5. Produce the decision recommendation. Use the Decision Guidance table above. Document the primary driver for the recommendation and the top three risks of the recommended path. If uncertainty is high, recommend a formal migration readiness assessment as the next step rather than a final go/stay.
  6. Define next steps for the chosen path. For Stay: document the re-evaluation triggers. For Move: outline a high-level migration project structure (discovery, sandbox build, data migration, UAT, cutover) and identify required partner or internal resources.

Review Checklist

Run through these before marking work in this area complete:

Salesforce-Specific Gotchas

Non-obvious platform behaviors that cause real production problems:

  1. No in-place upgrade path exists — There is no Salesforce tool or process to convert an NPSP org to an NPC org. Any guidance suggesting otherwise (including AI-generated suggestions) is incorrect. Migration always requires provisioning a net-new org with NPC licenses and performing a full data migration.
  2. NPSP and NPC use different default Account models — NPSP defaults to Household Accounts (standard Accounts typed as Household); NPC defaults to Person Accounts. These are mutually exclusive org-level settings. An org with Person Accounts enabled cannot use the NPSP Household model without serious conflicts, and vice versa.
  3. NPSP is feature-frozen, not end-of-lifed — No hard Salesforce-announced EOL date exists for NPSP as of April 2026. However, no new features will ever be added. Practitioners who tell clients "NPSP is still being actively developed" are incorrect. The correct statement is: NPSP receives security and critical bug patches only.
  4. PMM (Program Management Module) does not map 1:1 to NPC Program Management — Organizations running the NPSP Program Management Module must validate NPC's native Program Management against their specific use cases before committing to migration. Feature parity is not guaranteed, and configuration differences are significant.
  5. CRLP rollup fields do not migrate automatically — NPSP uses Customizable Rollup Summaries (CRLP) to calculate total giving, last gift date, and similar metrics on Accounts and Contacts. These rollup definitions do not transfer to NPC. Each must be rebuilt using NPC's native rollup framework or recalculated post-migration.
  6. Recurring Donation records require data model transformation — NPSP Recurring Donations are managed package custom objects. NPC uses Gift Commitments as the native recurring giving object. A data migration must transform each Recurring Donation record and its installment Opportunities to the NPC Gift Commitment and Gift Transaction model.

Output Artifacts

ArtifactDescription
Decision RecommendationGo/Stay recommendation with primary driver, top risks, and immediate next steps
Feature Gap AnalysisTable mapping the organization's feature requirements to NPSP vs. NPC availability
Customization InventoryList of NPSP customizations that would require migration effort, scored by complexity
Migration Readiness ScoreLow/Medium/High assessment of migration complexity based on data volume and customization depth

Package files