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.
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.