Last updated: March 2026 | Reading time: ~12 minutes

Whether you are moving off a legacy platform like Blackbaud Raiser’s Edge, Salesforce NPSP, or a homegrown Access database, the data migration is the single highest-risk phase of any CRM transition. Get it right, and your team hits the ground running with clean, complete records. Get it wrong, and you spend months reconciling mismatched gift histories, duplicate constituents, and broken campaign attributions.

This guide breaks the entire migration into six phases with specific, actionable checklist items for each. We built it from real-world experience migrating hundreds of nonprofit organizations — from small community foundations to enterprise United Way chapters managing millions of constituent records.

Use this as your working checklist. Print it. Share it with your implementation partner. Tape it to the wall in your data team’s office. Every item on this list exists because we have seen an organization skip it and pay the price.

Phase 1: Discovery and Data Audit (Weeks 1–2)

Before you move a single record, you need to understand exactly what you have. This phase is about creating a complete inventory of your current data landscape — not just what is in your CRM, but every spreadsheet, shadow database, and email marketing list that touches constituent data.

1.1 Inventory All Data Sources

Most nonprofits dramatically underestimate how many places their data lives. The CRM is just the beginning.

• ☐ Primary CRM database — constituent records, gift history, pledges, campaigns, funds
• ☐ Email marketing platform — Mailchimp, Constant Contact, Emma (subscriber lists, engagement data, segments)
• ☐ Online giving platform — Classy, GiveLively, Network for Good (transaction records, recurring gift data)
• ☐ Event management system — Eventbrite, GiveSmart, OneCause (attendee records, auction data, table assignments)
• ☐ Volunteer management system — VolunteerHub, Galaxy Digital (volunteer records, hours logged, skills)
• ☐ Grant management system — Fluxx, Submittable (funder records, applications, awards, reporting data)
• ☐ Financial system / ERP — Sage Intacct, QuickBooks, Financial Edge (GL transactions, fund accounting)
• ☐ Spreadsheets and local files — board member lists, major donor portfolios, event planning sheets, staff-maintained contact lists
• ☐ Legacy databases — previous CRM exports, Access databases, FileMaker systems, archived Raiser’s Edge backups

1.2 Document Current Data Structure

• ☐ Export a complete schema from your current CRM — every table, field, and relationship
• ☐ Map custom fields — document every custom field your team created, what it stores, and who uses it
• ☐ Identify critical relationships — household/organization links, soft credits, matching gifts, tribute/memorial connections
• ☐ Document business rules — how are gift types classified? What triggers a pledge reminder? How are lapsed donors defined?
• ☐ Catalog reports and queries — list every report your team runs regularly; these define your data requirements

1.3 Assess Data Quality

Run these diagnostics on your current database before deciding what to migrate:

Phase 2: Data Cleanup (Weeks 3–5)

This is the phase that separates successful migrations from disasters. Every hour you invest in cleanup before migration saves five hours of troubleshooting after. Do not skip this phase. Do not rush it.

2.1 Deduplicate Records

• ☐ Run automated duplicate detection using name + address, name + email, and name + phone combinations
• ☐ Manually review potential duplicates — automated tools will flag false positives (e.g., family members at the same address)
• ☐ Merge duplicates in your current system — not the new one. Merging in the source system preserves gift history continuity
• ☐ Document merge decisions — keep a log of which records were merged and why, in case you need to audit later
• ☐ Check for household/organization duplicates — not just individual records

2.2 Standardize Data Formats

• ☐ Phone numbers — standardize to a consistent format (e.g., (555) 123-4567)
• ☐ Addresses — use USPS standard formatting; abbreviate St, Ave, Blvd consistently
• ☐ State/province — use two-letter abbreviations consistently
• ☐ Prefix/suffix — standardize Mr./Mrs./Ms./Dr. and Jr./Sr./III/IV
• ☐ Gift amounts — ensure consistent decimal formatting; no currency symbols in numeric fields
• ☐ Date formats — confirm consistent format (MM/DD/YYYY vs. YYYY-MM-DD); resolve any ambiguous dates
• ☐ Fund/campaign/appeal codes — reconcile naming conventions; map old codes to new taxonomy

2.3 Archive vs. Migrate Decisions

Not everything needs to come over. Migrating garbage data into a clean system defeats the purpose.

Phase 3: Field Mapping and Transformation (Weeks 4–6)

Field mapping is where the technical work begins. Every field in your source system needs a destination in your new CRM, a transformation rule, and a validation check. This is tedious, detail-oriented work — and it is the single biggest determinant of migration quality.

3.1 Create Your Field Mapping Document

Build a spreadsheet with one row per field. At minimum, include these columns:

• ☐ Source System — which system the field comes from
• ☐ Source Field Name — exact field name in the source system
• ☐ Source Data Type — text, number, date, picklist, boolean, etc.
• ☐ Source Sample Values — 3–5 real examples showing the range of data in this field
• ☐ Target Field Name — where this field maps to in the new CRM
• ☐ Target Data Type — data type in the new system (may require conversion)
• ☐ Transformation Rule — any logic needed to convert the data
• ☐ Required / Optional — is this field mandatory in the target system?
• ☐ Validation Rule — how will you verify this field migrated correctly?
• ☐ Notes — edge cases, known data quality issues, stakeholder decisions

3.2 Handle Complex Mappings

These are the mappings that trip up every migration. Plan for them explicitly:

• ☐ Gift soft credits — how do you handle matching gift credits, spousal credits, solicitor credits?
• ☐ Tribute/memorial gifts — mapping the honoree, the donor, and the notification recipient
• ☐ Recurring gifts — migrating the active schedule, not just past transactions
• ☐ Pledge payment schedules — open pledges need both the commitment and remaining payment schedule
• ☐ Campaign/fund/appeal hierarchy — most systems structure these differently; build a crosswalk document
• ☐ Activity/interaction history — calls, meetings, emails, notes; decide which types to migrate
• ☐ Relationships — employer/employee, household members, board affiliations, donor-advised fund connections
• ☐ Custom attributes — constituent codes, solicit codes, communication preferences, interest tags
• ☐ Attachments and documents — proposal letters, signed gift agreements, photos; determine storage approach

Phase 4: Test Migration and Validation (Weeks 5–8)

Never run a production migration without at least two test runs. Test migrations reveal mapping errors, transformation bugs, and performance issues before they affect your real data.

4.1 Prepare Test Environment

• ☐ Set up a dedicated sandbox/test instance of your new CRM
• ☐ Create a representative test dataset — not just 10 records; include 500–1,000 records covering every data type and edge case
• ☐ Include your hardest records — constituents with complex relationships, unusual gift types, special characters in names, international addresses
• ☐ Document your test plan — specific checks for each data type, expected results, pass/fail criteria

4.2 Run Test Migration #1 (Structure Validation)

• ☐ Execute migration scripts against the test dataset
• ☐ Verify record counts — do the numbers match source counts for each entity type?
• ☐ Spot-check 50 constituent records — compare field-by-field against source system
• ☐ Validate gift totals — do lifetime giving amounts match? Do annual totals match? Do fund allocations balance?
• ☐ Check relationship links — are household members still connected? Are organizational affiliations intact?
• ☐ Test special characters — accents (Renée), apostrophes (O’Brien), hyphens (Smith-Jones), ampersands (Johnson & Associates)
• ☐ Verify date accuracy — gift dates, pledge start/end dates, birth dates, deceased dates
• ☐ Run standard reports — can you reproduce your key reports from the new system with migrated data?

4.3 Run Test Migration #2 (Full Volume)

• ☐ Migrate the complete dataset (not just the test sample)
• ☐ Measure migration time — how long does the full run take? Plan production window accordingly
• ☐ Verify performance — does the new system run acceptably with full data volume?
• ☐ Run reconciliation reports comparing source and target totals for every entity type
• ☐ Have end users validate — gift officers check their portfolios; data entry staff check recent transactions; report builders verify output
• ☐ Document every issue found and confirm resolution before proceeding

Phase 5: Production Cutover (Weeks 8–10)

The cutover window is the most stressful 48–72 hours of the entire project. Every decision should be made before you start. There is no room for improvisation during a production migration.

5.1 Pre-Cutover Checklist

• ☐ Set a firm cutover date — avoid month-end close, fiscal year-end, year-end fundraising season, and Giving Tuesday week
• ☐ Communicate the data freeze — notify all staff: no changes to the old system after [date/time]
• ☐ Process all pending transactions — batch all unposted gifts, complete all pending data entry
• ☐ Take a final backup of the source system (full database, not just an export)
• ☐ Confirm rollback plan — if the migration fails, how do you revert? Who makes the call? What is the deadline?
• ☐ Assign a migration commander — one person with authority to make real-time decisions during the cutover window
• ☐ Prepare your communication plan — draft emails to staff announcing read-only, then announcing go-live

5.2 Cutover Execution

• ☐ Freeze the source system — set all users to read-only access
• ☐ Capture delta records — export any transactions entered since the last full extract
• ☐ Run the production migration using the exact scripts validated in testing
• ☐ Load delta records into the new system
• ☐ Execute reconciliation checks — same checks from test migration, but against production data
• ☐ Run critical reports — verify key totals (total giving YTD, total pledges receivable, total active constituents)
• ☐ Activate user accounts in the new system
• ☐ Send the go-live notification to all staff

Phase 6: Post-Migration Validation and Adoption (Weeks 10–14)

The migration is not done when the data lands in the new system. It is done when your team trusts the data and can do their jobs effectively. This phase is about building confidence and catching anything the automated checks missed.

6.1 Parallel Run Period (2–4 Weeks)

• ☐ Keep the old system accessible in read-only mode for at least 30 days
• ☐ Assign data champions in each department to compare records between old and new systems
• ☐ Run month-end reports from both systems and compare results
• ☐ Track data discrepancy tickets — create a shared log where staff can report mismatches
• ☐ Establish a triage cadence — daily standup during week 1, then twice-weekly through week 4
• ☐ Monitor system performance — page load times, search speed, report generation time

6.2 User Acceptance Testing

• ☐ Gift officers verify their portfolios — top 25 donors, recent interactions, pending proposals
• ☐ Data entry staff process test transactions — one-time gift, recurring gift, pledge payment, in-kind gift, matching gift
• ☐ Report builders recreate critical reports — board dashboard, campaign progress, fund balance summary
• ☐ Email marketing team verifies segments — do the subscriber lists and segments match the old system?
• ☐ Finance team reconciles GL entries — do gift batches post correctly to the general ledger?
• ☐ Executive team reviews dashboards — do KPIs and summary metrics match expectations?

6.3 Training and Adoption

• ☐ Conduct role-based training sessions — gift officers, data entry, report builders, and executives each need different training
• ☐ Create quick-reference guides for the 10 most common tasks in the new system
• ☐ Establish a help desk channel — Slack channel, Teams group, or shared inbox for migration-related questions
• ☐ Schedule 30-day and 60-day check-ins to address ongoing issues and gather feedback
• ☐ Celebrate the milestone — a successful migration is a major organizational achievement; acknowledge the team’s effort

The 10 Most Common Migration Mistakes (and How to Avoid Them)

1. Skipping the data cleanup phase. “We will clean it up in the new system.” You will not. Dirty data in the old system becomes dirty data in the new system, except now it is harder to identify because everything looks unfamiliar.

2. Migrating everything. More data is not better data. Migrating 15-year-old records for constituents who have never given and have no current address just clutters your new system and slows down searches and reports.

3. Underestimating internal staff time. The implementation partner handles the technical migration, but your team makes hundreds of decisions — field mappings, data retention rules, report requirements, testing. Budget 200–500 hours of internal staff time.

4. Not testing with real users. IT signs off on the technical migration, but the gift officer discovers that soft credits did not migrate correctly three weeks after go-live. Include end users in every test cycle.

5. Cutting over during year-end. October through December is not the time to learn a new system. Your fundraising team needs to be focused on donor cultivation and year-end appeals, not troubleshooting data issues.

6. No rollback plan. If the production migration fails at 2 AM on Saturday, who makes the call to revert? What is the process? What is the deadline? Document this before cutover starts.

7. Forgetting about integrations. Your CRM does not exist in isolation. Email marketing, online giving, accounting, and event platforms all connect to it. Map every integration and test data flow in both directions.

8. One-size-fits-all training. Your gift officers, data entry staff, and executive team each interact with the CRM differently. Role-based training takes more effort but drives dramatically higher adoption.

9. Decommissioning the old system too early. Keep read-only access to the legacy system for at least 30 days — ideally 90 days. Your team will need to reference it for edge cases, historical lookups, and reconciliation.

10. Not celebrating. A successful CRM migration is a massive organizational achievement. It is months of tedious, high-stakes work. Acknowledge the effort, thank the team, and mark the milestone.

Frequently Asked Questions

How long does a typical nonprofit CRM migration take?

For a mid-size organization (50,000–200,000 records), plan for 12–16 weeks from kickoff to go-live. Enterprise migrations with multiple data sources and complex integrations can take 20–30 weeks. The cleanup and testing phases always take longer than expected — build buffer into your timeline.

Should we migrate all of our historical data?

No. Migrate the data you actively use and report on. For most organizations, that means full gift history for the last 7 years (IRS retention requirements), summary data for older periods, and full constituent records for anyone active in the last 3–5 years. Archive the rest.

Can we do the data migration ourselves, or do we need a partner?

It depends on your technical capacity. If you have a database administrator or strong data analyst on staff, you can handle simpler migrations (single source, <50,000 records) internally. For complex migrations (multiple sources, custom objects, integrations), an experienced implementation partner significantly reduces risk and timeline.

What if we find data quality issues during migration?

Stop and fix them before proceeding. It is always cheaper and faster to resolve data issues in the source system than in the target system. Common mid-migration discoveries include duplicate records, inconsistent coding, and orphaned transactions. Add buffer time to your project plan specifically for this.

How do we handle data that is entered during the migration window?

Implement a data freeze before cutover — a period where no new records are entered into the old system. Any transactions that come in during the freeze (like online donations) should be captured in a holding file and loaded as a delta batch after the main migration completes.

What is the biggest risk in a nonprofit CRM migration?

Loss of gift history accuracy. If lifetime giving totals, campaign attributions, or fund allocations are wrong after migration, your fundraising team cannot do their jobs. Gift history is the foundation of donor stewardship, prospect research, and moves management. Validate it obsessively.

 

Need Help Planning Your Migration?

StratusLIVE has migrated hundreds of nonprofit organizations to Dynamics 365 — from 10,000-record community foundations to 5-million-record national federations. Our data migration methodology is built on the framework in this guide, with proprietary tools that automate validation and reconciliation. Request a free migration assessment to get a customized timeline, budget estimate, and risk analysis for your organization.