There are so many reasons to upgrade to NPSPv3, and there is no shortage of documentation and help docs to allow for a fully successful, in-house upgrade. However, I have found that almost all help docs overlook telling you how this process will affect, and possibly break, the integrations you have with installed apps and API connections.
Because there are significant changes with the database schema from one version of NPSP to another, there are additional steps and testing you will need to plan for. Before you even start a test install in your sandbox, do a review of all installed apps in your instance and API integrations. Check to see if they have specific instructions on pre/post NPSPv3 installation. If not, ask around on the HUB to see if anyone had any disharmony between the app and NPSPv3.
If you still don’t know where to start, here are just a few to help you along the process.
Mail Merge and Mail Files – It doesn’t matter if you are using an integrated app to do mail merging, exporting a report and use Word create your letters/envelopes/labels, or if you export your data and send it out to a mail house or caging company for them to do the work – if you are going to take advantage of the new, bright and shiny Household naming and address functionality (Which you should – oh my, yes- you should), you will need to update all reports and templates with the new Household name and address fields.
API connections and online Form Builders – This is pretty much a wash, rinse, and repeat scenario as your mail merge process above. Make sure you check all your API and form field mappings to ensure that they are pointing to the correct NPSPv3 fields and objects.
Reports: Households/Accounts – Remember, NPSPv3 has a completely different account/household model. That means you will need to re-write all household/contact/account reports that you regularly use. There are also new summary rollup fields on the Household, so make sure you update any reports with account/household giving summaries (or any other rolled up summaries of any of your custom objects).
Reports: Opportunities/Grants/Recurring – You get new record types for Grants in Opportunities and a whole new object for Recurring donations. Make sure you update/create new reports to take these donation structure changes into account.
Mass Email Platforms – While mass email platforms are contact specific and use the standard, Salesforce Email field, you may still need to edit some of your email templates depending on what merge fields you include in your emails.
Click & Pledge – Click & Pledge is compatible with NPSPv3, but you will want to make sure you have the most recent upgrade for C&P. They have a complimentary upgrade assistance program. Once you are upgraded, make sure you turn off and hide all NPSP Recurring object functionality. You will also need to delete seven deprecated NPSPv2 fields for C&P Temporary Contacts to work.
KELL Fund Allocations vs NPSP Allocations – If you are using KELL Allocations, you need to determine if you are going to migrate from the KELL package to the new, NPSP Allocations functionality. You can’t have both running; they directly conflict with each other. If you decide to migrate from KELL’s package to NPSP functionality, make sure you give yourself enough time to map the data and test everything.
KELL has step-by-step instructions on how to disable the NPSP functionality if you choose to stay with the KELL Fund Allocations app.
