Explore Gratona by fundraising goal
Plan a nonprofit CRM migration you can actually verify.
A migration is complete when the relationships, money, work, permissions, and reports your organization depends on reconcile in the new system—not when a file finishes uploading.
Reviewed and updated 2026-08-16
Set the acceptance test before the timeline
Do not accept a fixed migration promise before the source data is inspected. First agree on the records, totals, relationships, recurring-payment continuity, permissions, workflows, and reports that must pass. Then build a dated plan around the actual work.
Make every migration decision visible
Each step ends with an artifact your team and vendor can inspect. If a decision is not written down, it will reappear as a cutover-day exception.
Step 1
Define success and name the decision owners
Write down what must be true at acceptance: which records moved, which workflows work, which reports reconcile, and who can approve mapping, finance, permissions, and go-live decisions.
Deliverable
A one-page migration charter with scope, owners, acceptance tests, and explicit exclusions.
Step 2
Inventory every source before exporting anything
List the CRM, donation processor, accounting system, email platform, event tools, spreadsheets, shared drives, and retired databases that still hold relationship or transaction history.
Deliverable
A source register showing the owner, record types, date range, export format, and current system of record.
Step 3
Decide what to migrate, archive, rebuild, or leave behind
A newer CRM does not make abandoned fields or duplicate records useful. Classify each dataset and document the retention, reporting, and relationship reason for bringing it forward.
Deliverable
A signed data disposition list for active records, history, attachments, custom fields, and obsolete data.
Step 4
Map relationships and identifiers, not only columns
Preserve the identifiers that connect people, households, organizations, gifts, soft credits, recurring commitments, notes, assignments, campaigns, and sponsorship relationships.
Deliverable
A field-and-relationship map with source keys, destination fields, transformations, defaults, and unresolved decisions.
Step 5
Separate transaction history from payment continuity
Historical gifts can be imported as records. Active recurring charges, tokens, settlement, refunds, receipts, and reconciliation depend on the current processor and must have a separate continuity plan.
Deliverable
A payment cutover plan naming the processor owner, token path, next charge, exception queue, and reconciliation test.
Step 6
Run a sample, inspect errors, and reconcile the result
Use representative records before the full import. Include clean and messy donors, households, organizations, gifts, relationships, notes, custom fields, and recurring cases.
Deliverable
A dry-run report with row outcomes, unresolved errors, record counts, financial totals, and approved mapping changes.
Step 7
Cut over with acceptance checks and a recovery path
Set the final export window, freeze rules, responsible operators, validation sequence, communication plan, and the conditions for pausing or rolling back. Do not improvise ownership on go-live day.
Deliverable
A dated cutover runbook and acceptance record signed by the data, finance, and fundraising owners.
Define export, mapping, and duplicate rules by record type
“Full export” is too vague for a migration or exit plan. Name the records, files, configuration, history, and relationships you expect to receive.
| Area | Current public scope | Put this in writing |
|---|---|---|
| Export coverage | Gratona provides standard reports and exports, including supported donor and fundraising detail. A full portability request should use a record-by-record matrix rather than assume one export contains every record, attachment, configuration, permission, and audit event. | List every required object, field, identifier, relationship, file, historical state, and configuration artifact. Mark its format and export path in the agreement. |
| Field mapping | Current import paths support column mapping and validation for supported record types. Defaults, transformations, identifiers, required fields, and update behavior vary by importer and workspace configuration. | Approve the source-to-destination map, transformation rule, default, owner, and exception handling for each field before the full run. |
| Duplicate handling | Duplicate and conflict handling depends on the record type and import path. Gratona supports dry-run and conflict review in current migration workflows; no universal automated match should be assumed for every object. | Define match keys, normalization, precedence, merge authority, review thresholds, skipped-row handling, and proof that a repeated import does not create duplicates. |
Current Gratona export paths
Gratona does not currently publish a one-click full-workspace export. Current self-service exports are record- or module-specific; relationship graphs and administrative artifacts need a written portability scope.
| Record family | Current path | Coverage and limit |
|---|---|---|
| Donors and organizations | Self-service CSV export | Selected configured fields, identifiers, contact data, and available giving and engagement columns in the donor worksheet. |
| Gifts and soft credits | Self-service CSV exports | Donation detail and soft-credit detail are exported as distinct datasets so the original gift, credited donor, amount, type, and related fields can be reconciled. |
| Sponsorships and recipients | Self-service program export | Program-scoped sponsorship and recipient data using the fields available to the current worksheet and export definition. |
| Events and mission trips | Self-service module exports | Event attendee and order CSVs; trip donation, participant, and task exports. Each export is scoped to the selected event or trip. |
| Reports, interactions, and work items | Self-service scoped exports | Saved-report rows, fundraising interactions, work-item lists, notes, and other supported operational views. These are separate exports, not one workspace archive. |
| Household and relationship graph | Support-assisted portability scope | Household membership, primary-contact assignments, related-contact roles, and stable source identifiers must be named explicitly. A flat donor CSV should not be treated as proof that the relationship graph is complete. |
| Files, configuration, permissions, and audit history | Support-assisted portability scope | There is no published one-click package for every attachment, configuration object, permission, and audit event. Required artifacts, formats, metadata, and delivery method belong in the agreement. |
Reconcile more than a row count
A record can exist and still be wrong. Validate structure, totals, links, access, and the daily work staff must perform.
| Area | Acceptance checks |
|---|---|
| People and organizations | Counts by record type; unique identifiers; names, contact details, households, organizations, ownership, and duplicate exceptions. |
| Giving history | Gift counts and totals by fiscal period, campaign, designation, payment method, result, refund, and soft credit where applicable. |
| Recurring support | Active commitments, frequency, amount basis, next charge, processor ownership, failed-payment handling, and cancellation status. |
| Relationships and sponsorships | Household and organization links, sponsor-recipient relationships, active commitments, program assignment, and historical changes. |
| Work and context | Notes, interactions, documents, tasks, assignments, dates, authors, permissions, and the timeline visible to staff. |
| Reports and access | Board and finance totals, operational lists, role access, exports, audit history, and the first reports the team must run after launch. |
Start from the import paths that exist today
Gratona has current mapping and validation workflows for core nonprofit records. Your written scope still controls which files, fields, transformations, payment steps, support, and recovery paths are included.
Donor and recipient records
Current CSV workflows support field mapping for donor and recipient records, including supported update and identifier choices. Exact fields and defaults depend on your workspace configuration.
Relationships
Dedicated relationship import paths support mapping and dry-run review for supported donor, recipient, commitment, and program relationships.
Historical transactions
The payment import workflow supports column mapping, date and amount review, dry-run validation, batch summaries, row errors, and supported conflict handling.
Interactions and documents
Supported migration scopes can include historical interactions and document mappings. File shape, ownership, permissions, and storage requirements are reviewed before commitment.
Your organization owns the acceptance decision
Gratona can prepare mappings, imports, error review, and a scoped cutover with your team. Your data, finance, fundraising, and program owners confirm the source files, transformation choices, reconciled result, and go-live.
Put the migration scope in writing
Which record types, date ranges, relationships, and attachments are included?
Who owns source extraction, cleanup, field mapping, transformations, and validation?
How are duplicates, ambiguous matches, skipped rows, and unresolved errors reported?
What is the plan for payment tokens, recurring schedules, next charges, and failed payments?
Which totals and sample records must reconcile before acceptance?
What configuration, integrations, training, and staff work are outside the migration fee?
What changes during the freeze window, and which system is authoritative?
What can be reversed, restored, or rerun if an acceptance check fails?
Resolve the hard questions before cutover
How long does a nonprofit CRM migration take?+
There is no responsible universal timeline. Timing depends on source systems, record volume, data quality, relationships, recurring-payment continuity, custom fields, integrations, validation ownership, training, and cutover scope. Require a written plan after the vendor reviews representative exports.
What data should a nonprofit migrate first?+
Start with the records required to preserve relationships, financial history, current commitments, operational continuity, and reporting. That commonly includes people and organizations, gifts, recurring support, key relationships, active tasks, material notes, and the custom fields your team still uses. Archive or omit data only through an explicit retention decision.
Can recurring payment information move to a new CRM?+
Historical payment records and active billing credentials are different problems. Processor tokens and recurring schedules may be controlled by the payment provider and cannot be treated like ordinary CSV columns. Confirm token portability, processor ownership, consent, next-charge timing, exception handling, and reconciliation before choosing a cutover date.
Should a nonprofit run both CRMs during migration?+
A short, controlled verification period can help, but two writable systems can create divergence. Define which system is authoritative for each record and transaction, limit parallel entry, record the freeze window, and reconcile changes before final acceptance.
What can Gratona import today?+
Gratona has current import workflows for supported donor and recipient records, relationships, historical transactions, interactions, and document mappings, with field mapping and validation paths that vary by import type. Managed migration scope, pricing, payment continuity, custom transformations, and recovery controls are confirmed after representative files are reviewed.
Bring representative files, not a perfect spreadsheet
We will walk through the records, relationships, payment continuity, validation owners, and reports your organization needs, then define the scope that can be supported in writing.
Moving from Bloomerang? Use the Bloomerang export-specific plan.
Evaluating Salesforce NPSP? Compare remediation, Nonprofit Cloud, and a Salesforce exit.
Leaving Raiser's Edge NXT? Reconcile both Blackbaud views before cutover.