No — NPSP's Recurring Donations don't map field-for-field onto Nonprofit Cloud. Both products track the same thing — a supporter's commitment to give on a schedule — but the underlying objects are different enough that migrating them is translation work, not a copy-paste. For a fundraising ops team, this is usually the part of an NPSP to Nonprofit Cloud migration that gets underestimated, because "recurring donations" sounds like a simple, well-understood concept on both sides.
Not sure if now's the time to move off NPSP? The free NPSP → Nonprofit Cloud readiness check scores your org in six questions — an honest verdict, no signup.
How NPSP tracks it: the Recurring Donation object
NPSP uses a single Recurring Donation record per commitment, which generates individual Opportunity records for each installment as it comes due. Since March 2021, new NPSP orgs default to Enhanced Recurring Donations (RD2) rather than the older Legacy model — RD2 handles open-ended and fixed-length commitments more cleanly and integrates with Salesforce's Elevate payment tooling. If your org predates that default and never upgraded, you're likely still running Legacy Recurring Donations, which matters below.
How Nonprofit Cloud tracks it: Gift Commitment + Gift Commitment Schedule
Nonprofit Cloud splits the same concept across two objects. Gift Commitment holds the supporter's commitment itself — amount and frequency. Gift Commitment Schedule defines the actual collection intervals against that commitment. Individual collected gifts then land as Gift Transaction records tied back to the commitment. It's a more granular model than NPSP's single-object approach, built to handle payment-processor integrations (Salesforce's own Fundraising integration syncs recurring gifts from external processors as Gift Commitment + Gift Commitment Schedule pairs) as a first-class case rather than an add-on.
What actually migrates, and what needs remapping
- The commitment itself (amount, frequency, donor) migrates conceptually cleanly — a monthly $50 gift is a monthly $50 gift on either side. This is the easy 80%.
- Legacy Recurring Donations need translating twice, not once — first to RD2's model (a step NPSP itself has an official upgrade guide for), then to Nonprofit Cloud's Gift Commitment model. Skipping the RD2 step and trying to map Legacy records directly is where migrations run into the most friction.
- Payment-schedule edge cases are the real risk: paused gifts, mid-cycle amount changes, and failed-payment recovery states don't have a clean 1:1 target field. These need an explicit decision in the migration plan — carry the current state forward, or reset to a clean commitment as of cutover — made before the move, not discovered after it.
- Payment processor integrations need re-pointing. If recurring gifts flow in from a processor today, that integration is talking to NPSP's Recurring Donation object; it needs to be repointed at Gift Commitment on the other side, which is integration work, not a data-migration checkbox.
What this means for planning your migration
Treat recurring donations as their own line item in the migration cost and timeline estimate rather than folding them into "general data migration." The size of the work scales with how many active recurring commitments you have and whether any are still on Legacy Recurring Donations — an org fully on RD2 with a small, clean recurring-donor base has a straightforward mapping; an org with Legacy records, a payment processor integration, and years of paused/modified gifts has real remapping work.
If you're still deciding whether to move at all, NPSP vs Nonprofit Cloud covers the full picture beyond recurring giving, and the readiness checklist is a good place to flag your recurring-donations setup before scoping a project. A consultation is the fastest way to get a straight answer on what your specific recurring-donor base will take to move.
Frequently asked questions
Do NPSP recurring donations migrate automatically to Nonprofit Cloud?
Not as a like-for-like field mapping. NPSP's Recurring Donation object and Nonprofit Cloud's Gift Commitment object represent the same real-world thing — a supporter's commitment to give on a schedule — but with a different data model underneath. A migration has to translate active Recurring Donations into Gift Commitments (plus their associated Gift Commitment Schedules) rather than copy records across, which is exactly the kind of mapping work that needs planning before cutover, not during it.
What is a Gift Commitment in Nonprofit Cloud?
It's the object that represents a supporter's recurring-donation commitment — the amount and frequency they've agreed to give. A related object, the Gift Commitment Schedule, defines the actual intervals the gift is collected on. Together they do the job NPSP's Recurring Donation record does on its own.
Is NPSP's Enhanced Recurring Donations (RD2) the same as the old Legacy Recurring Donations?
No, and it matters for a migration. Enhanced Recurring Donations (often called RD2) replaced Legacy Recurring Donations as NPSP's default in March 2021, with a different underlying model and tighter integration with Salesforce's payment tooling. If your org is still on Legacy Recurring Donations, that's a second migration hiding inside the bigger one — upgrading to RD2 is worth doing on its own timeline before a Nonprofit Cloud move, not folded into it.
What breaks most often in a recurring-donations migration?
Payment schedule edge cases: gifts that were paused, ones with a changed amount mid-cycle, failed-payment recovery states, and anything tied to a payment processor integration. These don't fail loudly — they migrate into a technically valid Gift Commitment that quietly no longer reflects what the donor actually agreed to, which is the kind of error that surfaces in a reconciliation report weeks later, not on migration day.
Yash
Founder & Principal Consultant, Ynexgen
Yash leads Ynexgen, helping small and mid-sized businesses turn technology into a stronger foundation for growth — 7+ years across Salesforce CRM, websites, and AI adoption.
