Summary of "The Path Forward" conversation

General
1

I’m putting this in “General” for the widest audience. And anyone who was on the call, please feel free to correct this and/or provide more context as needed. This is AI-generated (check out those emdashes!) from the transcript and reviewed and edited by me.

NPPatch: Two Potential Paths Forward

Summary of the Architecture Call — July 8, 2026

This call took up a foundational question: should the project focus on building improvements on top of the existing NPSP, or on developing a new standalone product — and in what order? Two themes framed the discussion: organizations consistently say they don’t want to move off NPSP and nothing is technically broken for them, yet much of the current pressure comes from concern that Salesforce will stop supporting it — as much a question of confidence as of technology. No decision was made.

Path 1: Build on top of existing NPSP

Release smaller, installable improvements into organizations already running NPSP — utilities, add-ons, fixes for known annoyances, and potentially a community-maintained installer — while deferring the larger product question.

Stated advantages

  • Meets organizations where they are: they’ve said they don’t want to migrate — they want help with what they have.
  • Largest immediate reach with the lightest lift: small, portable releases could serve the existing installed base of tens of thousands of orgs.
  • Visibly demonstrates the community can ship — building trust, name recognition, and engagement for any larger effort, while the group develops its release processes and input channels.
  • A maintained installer could fix a known pain point (difficult post-install setup), helping new NPSP implementations too.

Stated concerns

  • Small add-ons may not resolve the underlying anxiety, which is emotional as much as technical.
  • Some of the envisioned larger functionality does not work well technically as an NPSP extension.
  • Keeps the work tied to legacy design decisions the group might otherwise fix.
  • Everything released creates an ongoing maintenance responsibility.
  • Open questions about licensing and how building on a Salesforce-owned code base without formal permission would be perceived.

Path 2: Build a new standalone product

Develop a net-new product — forked from the NPSP code base or designed more “greenfield” — intended to eventually serve as a successor, paired with a migration tool for existing organizations.

Stated advantages

  • NPSP is no longer being improved and its add-on modules are disjointed; a need remains for a modern successor.
  • Freedom to fix long-standing design issues and evolve the data model, with a wide-open future under community governance.
  • Gives new implementations a confident answer today — several attendees are uneasy recommending the current options for net-new projects.
  • A comparable community effort reportedly built its initial product faster than expected.
  • A credible successor with a promised migration path can itself be reassuring to existing orgs.

Stated concerns

  • Organizations say they don’t want to move; migration is a large, intimidating change, and automated migration tooling is complex to build and maintain.
  • Positions the project as a competitor to existing offerings, with governance as the main differentiator.
  • Risk of spending years pursuing the “perfect” package with limited volunteer capacity, and of a big promise straining credibility.
  • If the new product diverges too far from NPSP, compatibility for existing orgs loses its value.
  • Does little in the near term for the anxiety existing organizations feel right now.

Common ground and next steps

Attendees repeatedly noted these paths are not necessarily mutually exclusive: hybrid and sequencing options (a modular core first; extensions designed to fold into a larger product later) received substantial discussion, with capacity and cost named as the main constraints. There was broad, though not formally confirmed, alignment that the most urgent need is “the signal” — visible proof that the community can deliver. Next steps: write up the decision points into a shared document, open it for community discussion, bring it to the next All Hands, and potentially distill it into a survey for broader input.

2 Likes
2

One thing I would add is that even if we were able to build a fully fledged migration tool, it wouldn’t work for any integrations or external form tools. That’s why I have been so concerned about maintaining the core object/fields.

3

Karen I’m really curious about what objects and fields you’re seeing used/customized the most in NPSP orgs. If you can do it without sharing sensitive data, would you mind looking a a couple of clients and listing what objects/fields you usually have mapped in forms, etc?

I may just be overly focused on payment processing integrations, but my assumption has been that most customizations for forms are done on the opportunity and contact objects, and a lot of those are in custom fields, not NPSP-native ones.

4

Here are some examples of what I’ve seen set through FormAssembly forms for my clients:

Contact: Personal Email, Work Email, Preferred Email, Mobile Phone, Home Phone, Work Phone, Preferred Phone, Primary Affiliation

Relationship: Creating a relationship between two contacts (parent/child for this example)

Organization Affiliation: Creating an affiliation between a contact and organization

Opportunity: Tribute Type, Honoree Name, Primary Contact, Acknowledgement Status, Acknowledgement Date

There are also tons of flows that deal with these same objects/fields, as well as GAUs. I am not sure whether a migration tool would also involve updating flows/layouts/validation rule, etc.

5

I hadn’t realized until this call that it would be possible for us to maintain a fork of NPSP and related installer that would still use the same namespace. That’s actually a very exciting idea to me!

If, in the short term, we could make our own installer that also adds some of the metadata that used to be part of the trial, that would

  • make self-implementing viable again
  • send a signal that NPSP is still going to exist because the community (we) are going to support it.

Then in the medium term if we could make a new version that replaces some of the older bits with new updates (like the improved Settings page) then I assume we could have an installer with options for

  • New org, leave out the old, include the new.
  • Existing org, install the new and either turn off the old as part of the install or we’d have post-install instructions to do so.

This, of course, could be iterative as we build some of these new bits.

Then in the long term we eventually get to a place where we have “NPSP 4.0” (or whatever it’s called) and we work on guidance for those orgs that actually want to “migrate fully to NPPatch,” whatever that might mean.