For our second post on the journey from NGO Connect (NGOC) to Nonprofit Success Pack (NPSP), we’re going to dig a little deeper into how the package functionality compares in both products: mainly, which NGOC features have corresponding NPSP counterparts and which do not. And more than that, how can you plan to account for that delta?
A note on best practice for any migration:
It’s important to consider process transformation before deciding on functionality. Even if you’re using an NGOC feature in a certain way today, you may not need a corresponding feature in NPSP — or you could simplify what you need in your future state. We hope this deeper dive will be helpful for you, but be sure to think about your business needs, current pain points, and opportunities for change as you plan your NPSP roadmap.
NGOC vs. NPSP: Overall feature comparison
First, let’s start with an easy reference table of direct mapping. Remember, for any feature that doesn’t have a NPSP partner, the effort to develop something in your new org may vary by use case. In fact, even if there’s a matching NPSP feature, you may still need to configure or customize it based on your organization’s unique needs. So, it’s important to think through the process rather than using this table alone to assess gaps.
What’s already there?
As you can see from this table, there’s a similar foundational structure that maps more easily from NGOC to NPSP. However, it’s still important to pay attention to the details as the features may be slightly different.
Let’s look further into some of these items:
Batch Upload Processing vs. Batch Data Import
Batch Upload (BUP) is a huge and complex feature in NGOC, allowing folks to import or integrate external data into a flat structure via this staging object, which then validates and transforms that information into the NGOC object model. BUP can handle moderate to large size batches and can create/update Account, Contact, Opportunity, Soft Credit, and Preference data natively. Batches are run through scheduled jobs and most often serve to transform donation and event data into NGOC.
Batch Data Import (BDI) is a more streamlined feature with a slick Lightning mapping interface and fewer objects that it creates/updates out of the box, which has its own pros and cons. Mainly, BDI natively creates/updates Accounts, Contacts, and Donations, with an interface to create matching rules within the product itself. Developers can create custom apex or Salesforce flow that acts upon the BDI records and creates/updates additional object records as needed. This simplicity is intentional as it allows customers to add what they need, rather than navigate extra design that may not fit them.
What you need to know: As you consider the migration, think through what types of external data you’ll be receiving. What are the sources and what information do you get? Are you mainly processing donations (outright gifts, sustainer pledges and payments) from new and existing donors? The only thing to add here is creation/search on Recurring Donations in NPSP. Are you receiving files from third party entities (payroll deductions/employee gifts/matching gifts etc)? Do you receive the list of donors from the entity in the external file? You can consider updating BDI to include Partial Soft Credits, which may take more file manipulation before import, OR you can add these Partial Soft Credits after the BDI job has run using a tool like Dataloader.
As you can see, the possibilities with a product like NPSP—that allows for flexibility and enhancement without extensive overhead—are nearly endless, but it is critical to think about what your team needs to assess how to move forward.
Fig. 1: Power of Us Product Documentation Image: Create NPSP Data Import Records Created to a Batch
As you can see from the table above, there are a few items that don’t have corresponding features in NPSP. Let’s take a look at a few of these common NGOC functions to understand the potential gap in NPSP.
What it did: Such a deceptively simple name, yet an object that does so much. In NGOC, Preferences track anything from constituent interests to board/committee memberships to communication lists. NGOC also allows users to create preference codes for external data processing that can be leveraged for segmentation. Nonprofits who used products before NGOC, like Raiser’s Edge or Donor Direct/PIDI, have loved this object because of its correlation to what they’ve known (i.e. attribute, flag, and interest tables). However, NPSP does not have a discrete object to track these details, so naturally the first thought would be “let’s just create one!”, right? Hold your horses, Preferences does a lot, yes, but does it do it the way you want or need it to? Let’s look further.
What you need to do: First, assess what types of data you’re storing in Preferences today. The most common and well-used business area is the tracking of communication preferences/subscriptions or opt-outs. How are you using this data? Segmentation for different campaign channels? What downstream systems or even external vendors are using this information? Are there other ways we could track this (e.g. Marketing Cloud)? By thinking about what we actually need to track and why, we can create a data structure and process that supports that work. Then continue this activity for all of the various ways you are using Preferences today.
While evaluating Preferences is more time consuming than recreating it, ultimately it will lead to better system and user performance and even more accurate and useful data.
What’s missing? While source codes are a common business need for many nonprofits, particularly enterprise nonprofits, NPSP does not have the source code data model and customization that are included in NGOC.
Why is that? The answer is likely tied to some common customer challenges — flexibility by the organization is imperative. There is not one standard length or structure for a source code: some are 10 characters, some are 14; some start with FY and others start with local chapter codes; some are shared between parent and appeal codes, and others need to be unique for every child campaign. Even more than that, some entities use an external vendor that segments data and creates source codes for the team, which really would only necessitate a text field on the Campaign and likely the ability to use that code for manual gift entry and import of direct mail responses. Other nonprofits came to NGOC with an existing source code structure and length that was already baked into their scan lines that cannot be changed without significant cost or impact on direct mail and that didn’t fit the 13 character source code structure that came in NGOC.
So one “feature” is therefore very difficult to work across use cases and customers. This makes it challenging to design a source code feature that meets the needs of all nonprofits.
So what does “not having source codes in NPSP” really mean? It means evaluating what your organization needs and creating just that. Do you need that text field to capture codes from your external vendor? How long is your code? What are the segments? How many attributes are these based on? Could this change over time? How will you use source code in gift entry and reporting/future segmentation? The answer to these questions could result in a build that’s anywhere from small to large, but the bottom line is, it will be a feature that exactly fits what your team needs.
Getting started on your NGOC to NPSP migration
We’ve only touched on a few of the feature comparisons between NGOC to NPSP, but you can already see there’s a lot to think about. Remember: always plan first and think about the users you are trying to support. For this and so much more, we’re here to help.