Data Migration Deep Dive: How to Move 20+ Years of Donor History Without Losing a Single Record
- Ohana Focus Team
- 11 hours ago
- 12 min read
By Ohana Focus | February 3, 2025 | 18 min read
The email that arrives at 4:47 PM on Friday (right before a three-day weekend, of course) seems innocent enough: "Quick question—can you confirm all our donor data made it into Salesforce?" Your stomach drops. Because you just noticed that the Raiser's Edge export shows 47,892 gift records, but the Salesforce import report shows 47,891.
Where did that one gift go? Was it a $25 annual fund donation from 2003, or the $500,000 pledge from your organization's largest capital campaign? The difference matters enormously—not just for data integrity, but for donor trust, tax compliance, and your ability to sleep that night.
Data migration is where Raiser's Edge to Salesforce projects succeed or fail—not in the vendor demos or the configuration workshops. In the unglamorous, technically demanding work of moving decades of donor relationships, gift history, pledges, soft credits, relationships, and interaction notes from one system to another without losing a single meaningful detail.
Let's take a closer look at exactly how competent migration happens—the technical decisions, the validation strategies, the places where things typically break, and how to ensure that when your team logs into Salesforce on go-live day, every donor record, every gift, and every relationship detail is exactly where it should be.
Understanding What You're Actually Moving
Before any technical migration strategy makes sense, it's essential to understand what "donor data" actually means in Raiser's Edge and how it maps to Salesforce's architecture.
The Core Data Objects:
Raiser's Edge stores donor information across multiple interconnected modules:
Constituent records: The core donor profile—names, addresses, phone numbers, email addresses, constituent codes
Gift records: Every donation—amount, date, campaign, fund, appeal, gift type, payment method
Pledges: Committed future gifts—pledge amount, schedule, balance, linked payments
Relationships: How donors connect—spouse, employer, board member, honorary tribute, etc.
Actions: Interaction history—meetings, calls, events attended, proposals sent
Notes: Freeform text documenting conversations, preferences, restrictions
Attributes: Custom fields storing everything from donor interests to volunteer hours to board terms
Each organization has been using Raiser's Edge for 10, 15, sometimes 25+ years. That constituent record created in 1998 has almost certainly been through seven different database administrators, each with their own data entry habits. The gift record from 2007? It references a campaign code that no longer exists in your current coding structure. And the relationship connecting Mrs. Thompson to the Thompson Family Foundation? It was entered three different ways across different time periods.
This is normal: your data reflects real organizational evolution. Migration isn't about fixing 20 years of data entry decisions in three months; it's about moving that history forward intelligently while establishing cleaner patterns for the future.
How Salesforce Thinks Differently
Salesforce doesn't have "constituents," "gifts," and "attributes." It has Contacts, Accounts, Opportunities, and custom objects. The Nonprofit Cloud (NPC) bridges this conceptual gap, creating nonprofit-friendly structures on top of Salesforce's business-oriented foundation.
The critical architectural differences:
Raiser’s Edge | Salesforce (Nonprofit Cloud) |
The constituent is the center. Everything connects to a single constituent record. | The Contact and Account both matter. Contacts represent individuals; Accounts represent households or organizations. Relationships flow between them. |
Gifts are discrete records directly attached to constituents. | Donations are Opportunities. Each Opportunity links to Contact Roles (crediting donors) and drives automatic rollup summaries. |
Constituent codes categorize donors (Major Donor, Board Member, Monthly Sustainer, etc.). | Picklists, checkboxes, and record types categorize donors—more flexible, but conceptually different. |
Raiser's Edge: Constituent is the center. Everything connects to the constituent record.
Salesforce: Contact (an individual person) AND Account (a household or organization) both matter. Relationships flow between them.
Raiser's Edge: Gifts are discrete records attached to constituents.
Salesforce: Donations are Opportunities. Each Opportunity connects to Contact Roles (who gets credit) and creates automatic rollup summaries.
Raiser's Edge: Constituent codes categorize donors (Major Donor, Board Member, Monthly Sustainer, etc.).
Salesforce: Uses picklist fields, checkbox fields, and record types to categorize—more flexible but conceptually different.
Understanding this architectural shift is essential because migration isn't a straight one-to-one copy. It's translation—converting Raiser's Edge constituent-centric data into Salesforce's relationship-based model while preserving every meaningful detail.
The Four-Phase Migration Strategy That Actually Works
Organizations that successfully migrate donor data without losing records or breaking relationships follow a structured four-phase approach. Each phase builds on the previous one, with validation checkpoints preventing problems from cascading.
Data Assessment and Cleanup (Weeks 1-4)
Goal: Understand exactly what you have, identify data quality issues, and make strategic decisions about what migrates and what doesn't.
Critical Activities:
Generate comprehensive data inventory: Export record counts from every module. How many constituents? How many active vs. inactive? How many gifts over the past 20 years? How many pledges? How many relationships? Organizations are consistently surprised by these numbers.
Identify data quality issues: Run queries finding duplicate constituent records, missing email addresses, invalid phone numbers, orphaned relationships (relationships pointing to non-existent constituents), gifts without campaigns, pledges without schedules.
Make scope decisions: Not everything needs to migrate. Decide cutoff dates for historical data. Define which constituent codes actually matter going forward. Determine which custom attributes contain real business value versus which are legacy fields no one uses anymore.
Execute strategic cleanup: Merge obvious duplicates. Standardize constituent codes. Fix critical data quality issues that would break migration scripts. Note: this isn't about making data perfect—it's about removing showstopper issues.
Common Discovery: Organizations discover they have 3,200 constituents marked "Major Donor," but only 400 gave more than $1,000 in the past five years. Or that they've been tracking "Board Member" as both a constituent code AND a relationship type, creating duplicate tracking. These discoveries inform migration mapping decisions.
Phase 1 Deliverable: Data inventory document showing record counts, identified issues, cleanup completed, and strategic decisions made about what to migrate.
Mapping and Transformation Design (Weeks 5-8)
Goal: Create detailed technical specifications showing exactly how every Raiser's Edge field maps to Salesforce, including transformation rules for data that doesn't map directly.
This phase separates amateur migrations from professional ones. Skipping detailed mapping leads to migration day disasters: "Wait, where did all the soft credits go?" "Why are spouses showing up as separate households?" "The pledge balances don't match!"
The Constituent-to-Contact-Account Mapping:
Every Raiser's Edge constituent becomes a Salesforce Contact. But Salesforce also requires an Account. For individuals, NPC creates a "Household Account." For organizations, you create organizational Accounts.
Mapping decisions:
Individual constituents: Map to Contact, create Household Account, connect them
Organization constituents: Map to Account with "Organization" record type
Married couples: Two Contacts (husband and wife) connected to single Household Account
Constituent codes: Map to Contact fields, Account fields, or Tags depending on usage
The Gift-to-Opportunity Mapping:
Each gift becomes an Opportunity. The complexity emerges in details:
Gift amount: Maps to Opportunity Amount
Gift date: Maps to Close Date
Campaign/Fund/Appeal: Maps to Campaign (requires creating Campaigns in Salesforce first)
Gift type: Maps to Record Type (Cash, Pledge, In-Kind, Planned)
Soft credits: Maps to Opportunity Contact Roles with specific role types
Recurring gifts: Maps to the Recurring Donation object with linked Opportunities for each payment
The Pledge Complexity:
Pledges create migration headaches because Raiser's Edge and Salesforce handle them differently:
Raiser's Edge: Pledge is separate from gifts. Pledge payments are gifts that reference the pledge.
Salesforce: Pledge is an Opportunity. Pledge payments are Payment records linked to the Opportunity.
Migration must:
Create an Opportunity for the pledge
Create Payment records for each payment made against the pledge
Ensure pledge balance calculates correctly
Handle partial payments accurately
Link payment schedules to future expected payments
Remember, getting pledge migration wrong creates major gift tracking disasters.
Phase 2 Deliverable: Complete mapping document showing every source field, target field, transformation rule, and business logic. This document becomes the migration blueprint.
Test Migration and Validation (Weeks 9-14)
Goal: Execute migration to test Salesforce environment, validate results exhaustively, identify and fix issues before final migration.
This phase happens in cycles: migrate, validate, find issues, adjust mapping, migrate again. Plan for 3-5 test migration cycles minimum.
The Test Migration Process:
Extract current data from Raiser's Edge: Run exports based on mapping specifications. Generate CSV files for Contacts, Accounts, Opportunities, Relationships, etc.
Transform data: Apply transformation rules. Handle constituent code mappings. Create household accounts. Process relationship connections. Calculate pledge balances.
Load to test Salesforce environment: Import in proper sequence (Accounts first, then Contacts, then Opportunities, then supporting records). Use data loader or migration tools.
Execute comprehensive validation: This is where migration quality is proven or disproven.
The Critical Validation Checklist:
Record count reconciliation: Total Contacts in Salesforce = Total constituents migrated from Raiser's Edge. Total Opportunities = Total gifts. Document any variances and explain why.
Financial reconciliation: The sum of all Opportunity amounts in Salesforce must equal the sum of all gifts in the Raiser's Edge export. Even a $1 variance requires investigation.
Relationship validation: Spot check 50-100 donor records comparing Raiser's Edge relationships to Salesforce connections. Are spouses connected? Are employer relationships correct?
Pledge accuracy: For every migrated pledge, verify pledge amount, payments made, and outstanding balance match between systems.
Soft credit verification: Soft credits in Raiser's Edge must become Opportunity Contact Roles in Salesforce with accurate amounts.
Data completeness spot checks: Select 25 major donors. Compare their complete records side-by-side between Raiser's Edge and Salesforce. Check giving history, interaction notes, relationships, everything.
Rollup accuracy: Salesforce calculates rollup summaries (lifetime giving, last gift date, total number of gifts). Verify these match Raiser's Edge calculations.
What Validation Typically Uncovers:
500 gifts are missing from migration because the export query excluded certain gift types
Pledge balances are calculating incorrectly due to a payment matching logic error
Spouse relationships are not connecting because the household account creation logic failed for certain name formats
Soft credits on joint gifts are creating duplicate Opportunities instead of a single Opportunity with two Contact Roles
Campaign hierarchies are not being preserved correctly, breaking reporting
Each discovered issue triggers mapping adjustments and another test migration cycle.
Phase 3 Deliverable: Test migration validation report showing perfect record count reconciliation, financial reconciliation, and spot-check verification, plus a documented list of all issues found and resolved across test cycles.
Phase 4: Final Migration and Go-Live (Week 15)
Goal: Execute production migration with confidence based on a proven test migration process.
The Final Migration Weekend:
Production migration happens over a weekend when fundraising activity stops. The timeline:
Friday, 5 PM: Freeze Raiser's Edge. No new entries allowed. Export final production data.
Friday, 6 PM - Saturday, 6 PM: Execute migration using proven scripts from test migrations. Load into the production Salesforce environment.
Saturday, 6 PM - Sunday, 2 PM: Run complete validation checklist. Compare production migration results to test migration results. Investigate any variances.
Sunday, 2 PM - 5 PM: Senior staff spot-check critical donor records. The development director reviews major donors. Finance reviews pledge balances. The executive director reviews board member records.
Monday, 8 AM: Go-live. Team begins working in Salesforce.
The Go/No-Go Decision:
Sunday afternoon requires a formal decision: do we proceed with go-live Monday morning, or roll back and try again next weekend?
Proceed if:
Record counts reconcile perfectly
Financial reconciliation shows zero variance
Spot checks reveal no showstopper issues
Staff testing confirms critical workflows function correctly
Roll back if:
Any unexplained record count variances
Financial totals don't match
Critical data missing or corrupted
Core workflows broken
It's always better to delay go-live than proceed with compromised data integrity.
The Technical Tools and Approaches That Professionals Use
Multiple technical approaches exist for Raiser's Edge to Salesforce data migration. The right choice depends on data volume, complexity, budget, and internal technical capabilities.
Salesforce Data Loader (Manual Process)
How it works: Export CSV files from Raiser's Edge. Use Excel or Python scripts to transform data into Salesforce-compatible format. Import using Salesforce's free Data Loader tool.
Advantages:
Free (Salesforce Data Loader is included)
Complete control over transformation logic
Works for any data volume
Disadvantages:
Labor-intensive—requires manual transformation work
Error-prone without careful validation
Requires technical skills (Excel formulas, data manipulation, or basic Python)
Best for: Organizations with smaller databases (under 10,000 contacts), limited budgets, and internal technical talent comfortable with data transformation.
Common Migration Pitfalls and How to Avoid Them
Even well-planned migrations encounter challenges. Knowing where problems typically emerge helps avoid them.
Trying to Migrate Everything
The mistake: Attempting to migrate every constituent record, every gift from 1985, every action, every attribute, everything in Raiser's Edge.
Why it's a problem: Migrating 40,000 constituent records when only 8,000 gave in the past 10 years creates massive clutter. Migrating 25-year-old action records of meetings with people who are no longer donors adds no value. More data doesn't mean better data—it means harder-to-navigate data.
The solution: Establish clear scope criteria:
Migrate constituents who gave in the past 7-10 years OR have active relationships
Migrate all gifts from those constituents
Migrate actions/notes from the past 5 years
Keep a complete Raiser's Edge backup for historical reference if needed
This creates a clean, focused Salesforce database while preserving complete history in archived Raiser's Edge.
Insufficient Test Migration Cycles
The mistake: Running one test migration, finding it "looks pretty good," and proceeding to production migration.
Why it's a problem: First test migrations always reveal issues. Second test migrations reveal more issues. Third test migrations finally approach correctness. Organizations that skip straight to production discover critical problems after go-live when they're hardest to fix.
The solution: Plan for a minimum of 3-5 test migration cycles. Each cycle includes full migration, complete validation, issue identification, mapping adjustments, and fresh migration. Only proceed to production when two consecutive test migrations show identical perfect results.
Ignoring Data Quality Until Migration Day
The mistake: Planning to "clean up the data in Salesforce after migration."
Why it's a problem: Migrating 500 duplicate constituent records means spending weeks post-migration manually merging them in Salesforce. Migrating inconsistent constituent codes means rebuilding segmentation from scratch. Migrating invalid email addresses triggers bounces immediately.
The solution: Execute strategic cleanup in Raiser's Edge before migration:
Merge obvious duplicate constituents
Standardize constituent codes to align with future Salesforce structure
Fix invalid email formats
Remove or consolidate unused attributes
Verify critical relationship data accuracy
Remember, clean data migrates successfully. Messy data creates post-migration disasters.
Weak Validation Process
The mistake: Checking that "the numbers look about right" rather than rigorous reconciliation.
Why it's a problem: "About right" means 200 missing gifts went unnoticed. That means $50,000 in pledges, calculating incorrect balances. It could also mean major donor relationships are not properly connected.
The solution: Rigorous validation must verify:
Exact record count reconciliation: Raiser's Edge export shows 23,456 constituents → Salesforce must have exactly 23,456 Contacts. Zero variance tolerated.
Exact financial reconciliation: Sum of gifts in Raiser's Edge export = sum of Opportunities in Salesforce. Down to the penny.
Statistically valid spot checks: Randomly select 100 records. Compare every detail between systems. Document any discrepancies.
Critical donor verification: The development director personally reviews the top 50 donors, confirming complete accuracy. Rigorous validation catches problems while they're fixable.
What to Expect After Migration: The First 30 Days
Successful migration doesn't end when data loads into Salesforce. The first month post-migration determines whether migration truly succeeded.
Week 1: Immediate Post-Go-Live Support
What's happening: Staff working in Salesforce for the first time with real data. Questions emerge constantly. Small issues surface.
Support requirements:
Daily check-ins with the team
Quick turnaround on questions
Immediate fixes for any critical data issues discovered
Documentation of common questions for the knowledge base
Common Week 1 discoveries:
Where do I find the donor's preferred contact method?" (Staff learning new field locations)
"This donor's spouse relationship seems wrong" (Edge case requiring correction)
"How do I generate the monthly donor report I used to run?" (New reporting training needed)
Responsive support during Week 1 prevents panic and builds confidence.
Weeks 2-4: Stabilization and Refinement
What's happening: The team is gaining comfort with Salesforce. Patterns are emerging around what works well and what needs adjustment.
Focus areas:
Address systematic issues: If validation revealed that 50 constituents have incorrect household connections, fix them systematically.
Refine workflows: Adjust gift entry processes, reporting, or other workflows based on real usage patterns.
Additional training: Conduct targeted training sessions addressing common questions or challenging areas.
Build on success: Identify what's working better than Raiser's Edge and lean into those improvements.
By Week 4, the team should feel genuinely comfortable working in Salesforce daily. Want a look at the bigger picture? Check out our guide on what to expect during the first 90 days after migration.
Partner with Ohana Focus
Data migration determines whether your Raiser's Edge to Salesforce migration succeeds or struggles. Getting it right requires technical expertise, nonprofit fundraising knowledge, and meticulous attention to detail.
Ohana Focus specializes in complex nonprofit data migrations. We've successfully moved millions of donor records, gift transactions, pledges, and relationships from Raiser's Edge to Salesforce without losing a single meaningful detail. Our migration services include:
• Comprehensive data assessment: We analyze your Raiser's Edge data thoroughly, identifying quality issues and making strategic scope recommendations.
• Detailed mapping development: We create technical specifications showing exactly how every field maps, including complex transformation logic for pledges, soft credits, and relationships.
• Multiple test migrations: We execute 3-5 test migration cycles, rigorously validating results and refining mapping until perfect.
• Production migration support: We manage the final migration weekend, including validation and go/no-go decision support.
• Post-migration stabilization: We provide intensive support during the critical first 30 days, ensuring your team succeeds with migrated data.
We're not just technical consultants—we're fundraising technology experts who understand that donor data represents relationships, not just records. We treat every gift, every pledge, every note with the care it deserves.
About Ohana Focus
Ohana Focus is a certified Salesforce consulting partner specializing in nonprofit technology strategy and implementation. We help organizations navigate complex CRM migrations, bringing together deep Salesforce technical expertise and a genuine understanding of fundraising operations.
Our migration practice has successfully moved donor data for health foundations, educational institutions, social service agencies, and cultural organizations—protecting decades of donor relationships while enabling modern fundraising capabilities.
What distinguishes our approach is the combination of technical rigor and nonprofit fundraising insight. We understand that successful migration isn't just about moving data accurately—it's about preserving organizational memory, maintaining donor trust, and enabling your team to build stronger relationships going forward.
Topics: Salesforce Migration, Raiser's Edge, Data Migration, NPC, Donor Data, CRM Implementation, Nonprofit Technology, Salesforce NPC
Comments