If you started using Salesforce’s NPSP a while ago, you might have used what are now called Legacy Recurring Donations (LRDs.) They provided some great functionality but there was a fatal flaw (see below) at the center of the implementation. It went wrong one day in March 2018, and sometime after that Salesforce decided to overhaul Recurring Donations. That overhaul is Enhanced Recurring Donations (ERDs.) Salesforce has said they won’t be improving LRDs, and so most organizations who use Recurring Donations will want to migrate at some point.
Salesforce has provided some tools to make migrating more practical. I’ve had a good experience with those tools, but the migration is still a real process. I recently completed my first big production migration and since I couldn’t find many accounts like this, I figured I would publish mine!
The organization I migrated is one that has been using NPSP and Recurring Donations since 2015 and had about 6,000 active Recurring Donation records when we did the migration. For a variety of reasons we had set Recurring Donations to have 36 months of future pledges rather than 12 months, so we had a lot of Opportunities.
Should you migrate?
I think migrating is worth the effort. I also think you probably can’t migrate safely unless you have recurring donations controlled outside of Salesforce. That’s true of most organizations, but if some external processor looks to Salesforce to charge or not charge a donor, touching Recurring Donations at all is high risk, and migrating is a lot of changes!
Salesforce’s documentation for this process is good, and the tool they’ve built worked really well for us. We wound up needing a few hours of downtime on a Saturday that didn’t both our users.
The big lesson I take away from our experience is that this should not be attempted without a full sandbox. I know a lot of small to medium NPSP organizations don’t want to pay for it, but I’d really encourage you to do that. Unless you’ve practiced several times in a full sandbox, you have no idea how long the downtime will be while you migrate. Our downtime wound up being 3-4 hours, which we scheduled on a Saturday afternoon and prepared everyone for for months.
For us, the key thing we did in the full sandbox was to work through the many, many validation errors the migration tool encountered. All of them were solvable, but many of the changes required to our data were precisely the kind of changes that LRD wasn’t great at dealing with, so being able to make those changes in the Sandbox, verify that they addressed the validation error and then to verify that those data changes didn’t have other side effects was fantastic. I’m sure some organizations will have minimal validation errors, but we had to update thousands of records in order to pass that stage of the migration, and some of the fixes took several tries. (More on that below.)
How to make the business case to migrate
Less Fragile Data: Particularly if a full sandbox is a new expense, you’ll probably need to make the case that migrating is worth the time and money. We’d found over the years that LRDs were more fragile than any other record in Salesforce. I’d had to set things up so that users could only edit Recurring Donations via a few specific quick actions and I used several reports to constantly monitor for issues. The total number of problems we had over the years was small, but when the data was bad it was very bad! I explained to everyone on the team that our total cost of ownership for Recurring Donations would be lower once we’d moved to ERDs and users would be happier.
Less Clutter: This organization found LRDs to generate a lot of clutter, and it was worse because we were creating 36 months of pledges rather than the typical 12. The cleaner ERD model with one pledge at a time appealed to users.
Easier automations: Like most organizations, we have some automations that run when a new Opportunity is created. With LRDs, each time a monthly record was created, that meant 36 Opportunities! Creating fewer Opportunities meant a lower risk that these automations would hit limits.
Supported Functionality: Of course we want to use a supported feature set from Salesforce that will get improvements!
Validation errors
While we only had about 6,000 active LRD to migrate, we had lots of LRDs that were closed, and those also had to be migrated. We ran into a variety of validation errors, some of which were easy to fix, and some of which weren’t! While I found that the documentation for migrating was pretty good, I don’t think they could anticipate all the different errors people might run into.
A big one I ran into was that we had a lot of LRDs that had a number of planned installments that was smaller than the number of paid installments. They were all closed. I am pretty sure these originated from LRDs being created with a zero in the planned installments field rather than null. (Just one thing to hate about LRDs!) I hated to bulk update this field because it is one of the fields I’d found to be so problematic with LRDs, but I did make that fix and everything worked out well.
The other troublesome error was about Open Ended Status being Closed and Schedule Type being blank. In that case, the migration tool requires that the number of planned installments be 1. Schedule type was my other most-hated LRD field, so I guess I shouldn’t have been surprised that this was an issue. I did do this bulk update and it worked out fine.
Projected revenue reports after migration
One really nice thing about the future pledges that LRD uses is that it makes it so easy to create reports for projected future recurring donations. While ERD does provide some useful functionality for this, I found that we needed an additional field as well as a lot of new reports to be able to do this. Because our users were accustomed to seeing Opportunity reports with pledged and closed won Opportunities, particularly for the current calendar year, I created a report that allowed them to continue to see similar reports, but with a new field called CY Dashboard Value. You can think of this as CY Pledged Value, but for this particular group of users, the term dashboard is useful. This let them continue to separate pledged vs. closed won revenue for the year in one report, and to get a total of both.
The field is a formula that is the Amount value for one time or closed won gifts. If the gift is pledged, it is the amount for all future payments for the rest of the calendar year.
if(
or( ISBLANK(npe03__Recurring_Donation__c), ispickval(StageName, 'Closed Won'), Recurring_Donation_Frequency__c = 'yearly' ),
Amount,
(Amount * (13 - month(CloseDate)) ))Updating reports in a Salesforce instance that is 9 years old is always a challenge! I let users know that they could look for a ✅ emoji in the report description to indicate that the report had been updated after the migration. Our most used reports were all updated as soon as the migration was finished.
* The fatal flaw in Legacy Recurring Donations
At the top of this post I mentioned the fatal flaw with LRDs. I’d used LRDs in multiple organizations for years when suddenly one day something weird happened to several hundred Recurring Donation records overnight in one of those orgs. I was absolutely certain none of us had updated the records that had changed, and we had no automated processes in place ourselves that were capable of doing such a thing. As I dug into the issue, I found out all kinds of things, but the big thing I discovered in the ensuing conversations with Salesforce support is that LRD Opportunities are deleted and recreated with fake created dates every night.
On one very unlucky night in March of 2018, this process made some mistakes, changing some close dates and amounts. Not all of them, just some. In some Salesforce instances nothing was changed. I never figured out a pattern to these changes, but wound up having to review millions of records to see if they’d been changed by this process that ran amok. It was absolutely awful and Salesforce really didn’t care.
I was on the phone with someone at Salesforce when they (I think accidentally) said out loud that all the Opportunities were being deleted and recreated every night, and I felt like I’d had the breath knocked out of me. I tried to imagine what would happen if one of us outside of Salesforce submitted an app for review on the appexchange that did such a thing! I’m still pretty speechless about it. I did confirm with them that ERDs do not do this.
In retrospect, I guess the amazing part is that this worked as well as it did. But it obviously isn’t a great way to set things up, and it meant that every night the code was trying to be very clever about “fixing” Recurring Donation records, and it shouldn’t surprise any of us that sometimes it got too clever – especially with fields that were interrelated and confusing for users.
Artisanal Data 