Explore Gratona by fundraising goal
Stay on NPSP, move within Salesforce, or choose a different CRM.
Salesforce publishes a path from NPSP into Nonprofit Cloud. An exit to Gratona is a different decision. Compare all three paths against the same data, workflows, operating burden, and acceptance evidence before your organization commits.
Reviewed and updated 2026-08-16
Do not confuse record export with org portability
Salesforce can export selected object data and files. The working org also contains relationships, derived logic, automation, permissions, packages, integrations, and staff process. A responsible decision accounts for both before comparing destinations or timelines.
Choose the operating model before the migration vendor
NPSP remediation, Nonprofit Cloud, and Gratona are different architecture decisions. Each can be right when its required proof matches your organization.
Path 1
Remediate the current NPSP org
The existing data model still fits, the organization can govern its customizations, and the main problem is data quality, documentation, or administration rather than platform fit.
Require this proof
Inventory packages, objects, fields, automations, integrations, permissions, reports, technical debt, release ownership, and the people required to maintain them.
Path 2
Move from NPSP into Nonprofit Cloud
The Salesforce ecosystem, extensibility, data platform, and operating model remain strategic, and the organization is prepared for a new data model and an implementation project.
Require this proof
Use Salesforce current migration and implementation guidance to map features, fundraising processes, permissions, automations, integrations, data, testing, training, and ongoing administration.
Path 3
Exit Salesforce for Gratona
The development team wants a purpose-built nonprofit CRM, connected fundraising work, specialist sponsorship depth, and a smaller configuration and governance surface.
Require this proof
Run a representative export through the agreed Gratona mapping, reconcile history and relationships, separately plan active payments, and demonstrate the daily workflows before cutover.
Preserve the system, not only its rows
Use the official data export as one source. Inventory the configuration and operating dependencies it does not recreate in the destination.
| Workstream | Inspect | Acceptance boundary |
|---|---|---|
| Record data | Accounts, contacts, affiliations, relationships, opportunities or gifts, payments, recurring records, campaigns, tasks, activities, notes, files, and every material custom object. | Preserve source IDs and relationship keys. A set of object CSVs does not reconnect itself in a different data model. |
| Derived logic | Formula fields, roll-up summaries, matching rules, calculated values, validation rules, duplicate rules, and downstream reports that depend on them. | Salesforce says formula and roll-up summary fields are excluded from full data exports. Document the logic and decide whether to rebuild, replace, or retire it. |
| Automation and access | Flows, Apex, scheduled jobs, approvals, permission sets, profiles, sharing rules, queues, ownership, and release processes. | Treat configuration and security as separate migration work. Record exports prove data availability, not equivalent behavior or access. |
| Connected systems | Donation forms, payment processors, accounting, email, websites, Experience Cloud, AppExchange packages, APIs, middleware, analytics, and local spreadsheets. | Name the authoritative system, integration owner, credential path, reconciliation test, and retirement decision for each dependency. |
| Files and retained evidence | Salesforce Files, CRM Content, documents, attachments, enhanced notes, consent evidence, receipts, and any records retained outside the CRM. | Select the documented file options during export and test permissions and links. Data Loader metadata alone is not the physical file archive. |
Make the architecture and acceptance evidence explicit
Step 1
Map the Salesforce org before choosing the destination
List standard and custom objects, NPSP packages, fields, relationships, record types, formulas, automations, permissions, reports, integrations, portals, files, and named owners. Include unused-looking structures until their dependencies are understood.
Acceptance evidence
An org dependency map showing what is data, configuration, code, integration, access, or operating process—and who can approve its disposition.
Step 2
Choose among remediation, Nonprofit Cloud, and exit
Compare the three paths against the same fundraising scenarios, total operating responsibility, implementation risk, ecosystem needs, staff capacity, specialist workflows, and five-year architecture. Do not treat a product name change as a migration decision.
Acceptance evidence
A decision record with tested workflows, assumptions, cost scope, dependencies, exclusions, risks, and accountable approval owners for every path.
Step 3
Create and preserve the complete exit package
Run the appropriate Salesforce export, select all required objects and the documented file and attachment options, download every archive within the availability window, and preserve an immutable source copy. Export additional reports or API extracts when the full export cannot answer a required reconciliation question.
Acceptance evidence
A source register with archive names, checksums, export date, requesting admin, objects, date range, row counts, files, supplemental extracts, and known omissions.
Step 4
Translate objects, relationships, and derived behavior
Map households, organizations, people, gifts, recurring commitments, payments, soft credits, campaigns, interactions, tasks, ownership, and custom objects into the destination model. Reconstruct required formula or roll-up results from governed source logic rather than assuming those values were exported.
Acceptance evidence
A field, relationship, and behavior map with source keys, destination fields, transformations, defaults, merge rules, calculated logic, and unresolved decisions.
Step 5
Run representative Gratona mappings and dry runs
Start with clean and messy people, households, organizations, historical gifts, refunds, recurring cases, relationships, interactions, files, and material custom fields. Gratona mapping and validation paths vary by import type, and the written scope governs what can be supported.
Acceptance evidence
A reviewed dry-run result with row outcomes, mapping changes, duplicate decisions, unresolved records, record counts, relationship checks, and financial totals.
Step 6
Protect active payments and connected operations separately
Historical transactions are not active billing credentials. Confirm processor ownership, token or reauthorization path, recurring schedules, next charges, settlements, refunds, receipts, forms, accounting, email, APIs, and exception owners before changing a live workflow.
Acceptance evidence
A continuity register for active payment series and every connected system, with test evidence, cutover order, donor communication, reconciliation, and recovery decisions.
Step 7
Accept the new operating record before retiring Salesforce
Reconcile records and money, verify permissions and reports, run the daily development workflows, train responsible staff, freeze changes, capture the final delta, and keep a recovery path. Retain source access or archives according to the approved legal and operational policy.
Acceptance evidence
A signed acceptance matrix, final-delta reconciliation, cutover runbook, exception queue, recovery criteria, and documented source-retention decision.
Treat the export window as an operational constraint
Salesforce currently documents edition-dependent export cadence, individual ZIP downloads, a 60-second wait between downloads, and limited file availability. A new export can also remove the prior files. Assign an administrator to download, verify, checksum, and preserve every archive before the window closes.
Keep payment continuity outside the CSV assumption
Opportunities, gifts, payments, or recurring records can describe history. They do not by themselves move stored payment credentials or authorize future charges. Scope the processor, tokens, next bill dates, forms, receipts, settlements, refunds, donor communication, and exceptions as a separate cutover workstream.
Verify the source system before setting scope
These Salesforce sources define the current migration and export boundaries used in this guide. Confirm them again when your organization begins planning.
Questions to answer before a Salesforce decision
Is moving from NPSP to Nonprofit Cloud a simple upgrade?+
Salesforce publishes a migration guide for assessing a move from NPSP into Nonprofit Cloud and says the material is intended for experienced Salesforce admins and consultants. Treat the work as a data-model and implementation decision: map features, objects, permissions, automations, integrations, fundraising processes, testing, training, and administration before approving it.
Can a nonprofit export all of its Salesforce data?+
Salesforce provides a full data export that produces ZIP archives containing CSV files for selected objects, with optional images, documents, attachments, Salesforce Files, and CRM Content versions. The current documentation also identifies important boundaries: formula and roll-up summary fields are excluded, recycle-bin data is excluded, export availability is time-limited, and newly created objects may require reselection for a scheduled include-all export.
Does a Salesforce data export include flows and configuration?+
A record export should not be treated as a portable copy of the org. Inventory flows, Apex, validation and duplicate rules, formulas, roll-ups, packages, permissions, sharing, reports, integrations, portals, and release processes separately. Decide what must be rebuilt, replaced, documented, archived, or retired in the destination architecture.
Should our organization stay on NPSP?+
Stay can be a responsible choice when the current data model and ecosystem fit, the org is governable, and the organization has clear administration and release ownership. Compare remediation with both migration paths using the same real fundraising workflows, cost scope, risks, and staffing assumptions rather than choosing from platform reputation alone.
Can recurring gifts move from Salesforce to Gratona?+
Historical gift and recurring-schedule records can be mapped when supported by the agreed import scope. Active billing credentials, processor tokens, future charges, settlements, refunds, and donor communications require a separate processor-specific continuity plan. Confirm the exact path before promising a transfer or cutover date.
What can Gratona import from Salesforce today?+
Gratona has current supported workflows for donor and recipient records, relationships, historical transactions, interactions, and document mappings, with field mapping, dry-run validation, batch progress, and error review that vary by import type. Exact Salesforce objects, custom transformations, derived logic, active-payment continuity, managed support, and recovery controls are confirmed after representative exports are reviewed.
Bring the org map, a representative export, and one real fundraising workflow
Gratona can review the source structure, test the supported mappings, surface exceptions, and define acceptance evidence before your organization approves a Salesforce exit.