Nonprofit CRM migrations fail more often than they should. Not because the destination platform is bad, but because organizations underestimate how much work happens before the first record imports.
I've seen migrations that should have taken 6 weeks drag on for 6 months. I've also watched well-prepared organizations complete a migration of 15,000 constituent records in 5 weeks with minimal disruption to fundraising operations.
The difference is almost entirely preparation. This checklist reflects what the successful ones do.
Pre-Migration Phase (Steps 1-5)
Step 1: Complete Data Audit. Export everything from your current system before you do anything else. If you're migrating from spreadsheets, consolidate all spreadsheets into one place. If you're migrating from an existing CRM, run a full export of all records, all gift history, all notes. Know exactly what you have: total constituent count, total gift records, date range of gift history, number of active recurring donations, number of open pledges.
Step 2: Constituent Deduplication. Duplicates are universal. Most databases have 10-20% duplicate rate when properly analyzed. Run your current data through a deduplication tool before migrating. Merging duplicates in the new system is much harder than merging them before import. Look for duplicates by email address, phone number, address, and name variations. 'John Smith' and 'J. Smith' at the same address are almost certainly the same person.
Step 3: Gift History Mapping. Map every field in your current gift records to the corresponding field in your destination system. Gift amount, gift date, appeal code, campaign, fund designation, payment method, batch number. Don't assume field names mean the same thing across systems. 'Campaign' in your old system might be 'Appeal' in the new one. Document every mapping decision.
Step 4: Soft Credits and Tribute Gifts. Soft credits are easily the most commonly botched part of nonprofit migrations. A soft credit is a non-deductible attribution of a gift to someone other than the actual donor—typically a fundraiser who solicited the gift or a tribute honoree. These relationships need to migrate with the gift records, not just the hard credit. Tribute gifts (gifts made in honor or memory of someone) need both the in-honor designation and the notification contact.
Step 5: Recurring Donation Records. Pull a complete list of all active recurring gifts. For each one document: donor record, gift amount, frequency, start date, payment method and last 4 digits of card if applicable, next scheduled date, processor. Recurring gifts require special handling because they represent future expected revenue. Migrating them incorrectly breaks your monthly giving program.
Data Preparation Phase (Steps 6-9)
Step 6: Pledge Balance Verification. Open pledges represent committed future revenue. Every pledge in your system should have: original pledge amount, number of payments, payment schedule, amount paid to date, remaining balance. Verify these numbers before migration. Balance calculation errors are common and create accounting headaches post-migration.
Step 7: Communication Preference Migration (GDPR/CASL Compliance). Every constituent's communication preferences need to migrate with their record. Email opt-in status, mail opt-out status, do-not-call flags, and specific list subscriptions. Under GDPR and CASL, you cannot assume opt-in—you need documented evidence of consent. This is also a good moment to remove constituents who have unsubscribed from all communications and have no relationship beyond the opt-out.
Step 8: Custom Field Mapping. Every organization has custom data that doesn't fit standard fields. Interest categories, board connections, volunteer skills, geographic territories, custom rating systems. Document every custom field you currently use. Decide which ones to carry forward. This is a good moment to cut the dead weight—fields that nobody looks at and nobody maintains. Map surviving custom fields to equivalent fields in the new system, creating new fields where necessary.
Step 9: Test Import Validation. Before importing your full dataset, run a test import of 200-500 records. Include your most complex records: donors with multiple soft credits, tribute gifts, open pledges, recurring gifts, and extensive communication history. Review the imported records manually. Check that gift totals match. Verify that relationships imported correctly. Look for formatting issues with addresses, phone numbers, and dates.
Migration Execution Phase (Steps 10-12)
Step 10: Parallel Running Period. Run both systems simultaneously for 2-4 weeks after you've completed the initial import. This means entering new gifts in both the old system and the new one during the parallel period. It's double work, but it protects you. If something is catastrophically wrong with the migration, you have a clean fallback. Set a clear end date for the parallel period—otherwise it drags on indefinitely.
Step 11: Staff Training Before Go-Live. Training is most effective when it happens close to when staff will actually use the system. Train key users 1-2 weeks before go-live, not 2 months before. Focus on the workflows they'll actually perform: entering a new gift, acknowledging a donation, running a LYBUNT report, updating constituent contact information. Role-specific training beats generic 'here's the whole system' training.
Step 12: Go-Live Cutover. Pick a specific date. On that date, stop entering data in the old system. From that point forward, the new system is the system of record. Communicate this clearly to all staff. Have your most knowledgeable person available all day on go-live day to answer questions. Accept that things will go wrong and plan to address them immediately rather than working around them.
Post-Migration Phase (Steps 13-14)
Step 13: Data Verification and Reconciliation. Within the first week after go-live, run these checks: total constituent count matches (allowing for deduplication), total gift count matches, total gift revenue matches by year, open pledge balances match, active recurring gift count matches. Any discrepancy needs investigation before it becomes a larger problem. Have your finance team verify that the new system's data reconciles with your accounting records.
Step 14: 30-Day Stabilization Period. Treat the first 30 days as a stabilization period, not a business-as-usual period. Hold weekly check-ins with staff to surface problems early. Maintain a running list of data issues discovered during normal use. Prioritize fixes by impact—errors in major donor records are more urgent than formatting inconsistencies in address data. By day 30, you should have a clean system that your team trusts. If you don't, add another 30 days before declaring the migration complete.
Common Migration Failures to Avoid
Rushing the deduplication. Organizations want to start using the new system immediately and defer deduplication to 'later.' Later never comes. Duplicate records multiply in the new system and the problem grows exponentially. Deduplicate before you import.
Not validating gift totals. The most common sign of a bad migration: total giving reported in the new system doesn't match the old system. This creates auditing problems and donor record inaccuracies. Verify totals by year and by fund before going live.
Skipping the parallel running period. The urge to just switch over is strong. Resist it. Two weeks of double entry is far less painful than discovering a major data problem with no fallback.
Inadequate staff training. The system is only as good as the people using it. Invest in training, document your organization-specific workflows, and identify internal power users who become the go-to resources for questions.