Migrating from Raiser’s Edge or ThankQ to Salesforce Nonprofit Cloud
Key points
- Start reviewing your data early. Understanding, cleansing and testing charity data can take longer than the initial project plan allows.
- Give particular attention to supporter relationships, recurring donations, soft credits, consent and Gift Aid information.
- Review Raiser’s Edge attributes before mapping them. Overlapping fields, inconsistent values and free text can carry reporting problems into Salesforce.
- Assess ThankQ against its own configuration and exports. A mapping designed for Raiser’s Edge won’t explain how your ThankQ database has been used.
- Involve fundraising, finance, marketing, supporter care and data teams in decisions and testing.
- Reconcile the migrated data against agreed source figures, and check that staff can use it for their everyday work.
George Tye
CEO & Founder
What should a charity consider before moving to Salesforce Nonprofit Cloud?
A charity’s database can hold decades of giving history alongside the details of people who donate, volunteer, attend events or receive support.
When you move from Raiser’s Edge or ThankQ to Salesforce Nonprofit Cloud, those connections need to remain understandable to the people using the new CRM.
A supporter’s name and address may be straightforward to transfer. Understanding how their recurring donations, communication preferences and relationships have been recorded takes more investigation.
A record can arrive in Salesforce successfully and still be incomplete for the work your team needs to do.
At Migrate Data, our charity migration work involves examining the source data in detail and agreeing how it should work in the destination system.
Our Salesforce data migration service covers that process from the initial review through mapping, testing and go-live.
Why charity CRM migrations need careful planning
In our experience, charity migrations often involve larger record counts and more complicated relationship histories than commercial projects. One person may be a donor, a member and a volunteer, with information held in different parts of the database.
Different teams also need different things from the same records. Fundraising may need to understand someone’s involvement in an appeal. Finance needs reliable gift figures.
Supporter care needs to see previous interactions and communication preferences. Each team should have a say in how its information is mapped and checked.
These requirements affect the project schedule. If the only people testing the migration are those responsible for loading the data, problems with supporter searches, campaign selections or financial reporting may go unnoticed until staff start using Salesforce.
Which data needs particular attention?
We typically work with constituent, contact, fundraising and attribute data in Raiser’s Edge. The scope of a ThankQ migration should be established through a separate review of the database and its available exports. In either case, the following areas deserve attention early in the project.
Data area | What to establish before migration | What to check during testing |
Supporter and contact records | Which records represent the same person or organisation, and how relationships are recorded | Gifts and relationships remain attached to the correct supporter after any agreed merges |
Historical donations | How dates, amounts, gift types and fundraising codes are used | Totals reconcile by agreed categories, with differences explained |
Recurring donations | How commitments, payment history and current status are represented | Staff can distinguish payments already received from future expected gifts |
Soft credits | Who receives recognition for a gift and how that recognition is recorded | Recognition is preserved without counting it as additional income |
Consent and communication preferences | Where preferences, restrictions and supporting history are held | The agreed rules produce the expected contact selections and exclusions |
Gift Aid information | Which declarations, dates, links and claim-related records fall within scope | Information remains connected to the relevant supporter and gifts |
Attributes and custom fields | What each field means, who uses it and whether it is still needed | Values support the intended searches, reporting and workflows |
Raiser’s Edge attributes: resolve the meaning before mapping the field
Attributes are a particular area of focus in our Raiser’s Edge projects. Over time, teams can create duplicate or overlapping attributes, use different values for the same thing, or leave old attributes in place after a process changes. Heavy use of free text can make querying and reporting unreliable.
For example, a supporter category might appear as “Volunteer”, “Vol” and a longer note describing the person’s involvement. Those entries need review before they can become a consistent value in the new system.
Equally, two attributes with similar names may serve different purposes and should not automatically be combined.
Ask the people who use these fields to explain them. Agree which values should be standardised, which fields need to remain separate and which information no longer belongs in the live CRM.
Where contact records also need attention, our data cleansing services can help address duplication and outdated details before the move.
“We have seen charities underestimate how long a CRM migration can take, particularly the effort involved in understanding, cleansing, mapping, validating and reconciling the data.”
ThankQ: review the database you actually have
For a ThankQ to Salesforce migration, begin with representative source data and the reports your teams rely on. Establish how supporter records connect to donations, recurring giving and preferences in your particular setup, including any custom fields or local coding conventions.
If you are bringing Raiser’s Edge and ThankQ into the same Salesforce environment, assess them independently before agreeing shared mappings.
Keep source identifiers traceable and define how potential matches across the two systems will be reviewed. The same supporter may exist in both databases with different information attached to each record.
Agree how the data will work in Salesforce Nonprofit Cloud
Before finalising mappings, confirm the destination configuration with the Salesforce implementation team. Nonprofit Cloud and the Nonprofit Success Pack (NPSP) have different data models; guidance or templates written for one should not be assumed to fit the other.
Agree how your charity will represent gifts, recurring commitments, recognition and supporter relationships in its chosen setup. Then map the source information to that structure. The names of the old fields alone won’t tell you where everything belongs.
Recurring giving is a useful example. The team needs to understand both the arrangement to give regularly and the individual payments already received.
Similarly, a soft credit recognises someone’s involvement in a donation and should not increase the income total. These distinctions need to survive the transformation and be tested in the relevant reports.
What we learned from a Raiser’s Edge charity migration
In one charity migration, a substantial part of our work involved understanding the Raiser’s Edge data model, including its tables, fields, attributes and gift structures. Alongside that investigation, we examined how the destination CRM expected the information to be organised.
The challenge was interpreting historic fundraising information correctly. Recurring gifts, soft credits, coding structures and supporter relationships all needed careful mapping so that staff could continue to use them after the move.
We applied our PDM methodology, using a structured approach to landscape analysis, mapping, transformation, validation and reconciliation.
That work helped reduce migration risk, improve data quality and give the charity accurate, usable information in its new platform from day one.
The lesson we return to with charities planning a move is to allow enough time for this work. Understanding an old field or resolving a mismatch may require input from someone who also has a fundraising campaign or month-end reporting to complete.
How to prepare for the migration
Start with data profiling: examining what is in the database, how consistently it has been recorded and where information is missing or duplicated. Do this before committing to detailed field mappings, so decisions reflect the data you actually hold.
The following preparation gives the project team a clearer basis for estimating the work.
Early action | What your team should agree |
|
Identify the data sources | Which databases, exports and supporting files are in scope, and who can explain them |
|
Assign decision owners | Who can approve field meanings, merge rules, exclusions and changes to scope |
|
Review retention and access needs | What belongs in Salesforce, what needs separate retention and who needs access |
|
Define acceptance criteria | Which totals, relationships, records and everyday tasks must pass testing |
|
Reserve staff time | When fundraising, finance, supporter care and data teams can review results and resolve queries |
|
Plan the final transition | How changes made after a test extract will be captured, and who authorises the final move |
|
Avoid moving every field simply because it exists. Some older information may need to remain accessible without appearing in everyday CRM screens. Decide this with the people responsible for the data and the charity’s retention policy. Our data storage services provide an option to discuss where legacy information needs to be retained separately.
How do you know the migration is ready for go-live?
An import completing without errors is only one check. Reconciliation compares the migrated results with agreed source figures, allowing for documented transformations such as approved merges or exclusions. Validation also needs to show that records mean what users expect them to mean.
For example, finance can review donation totals for selected periods and categories. Fundraisers can examine supporters with complex giving histories.
Supporter care can check records with communication restrictions. Include awkward cases as well as straightforward records, and leave time to investigate differences and repeat the test load where needed.
Agree who signs off each area. Unresolved issues should have a recorded explanation and a decision about whether they prevent go-live.
If your charity is planning a move from Raiser’s Edge or ThankQ to Salesforce Nonprofit Cloud, talk to Migrate Data about your source systems, likely scope and deadlines. Starting that conversation early gives you time to investigate the data and build a realistic migration plan.
Frequently Asked Questions
Can Raiser’s Edge or ThankQ data be migrated to Salesforce Nonprofit Cloud?
Yes. The migration needs to account for the source data, the charity’s requirements and the way Salesforce Nonprofit Cloud has been configured. Supporter records, fundraising history and associated information should be assessed and mapped as part of an agreed scope.
How long does a charity CRM migration take?
There isn’t a reliable timescale without reviewing the data and scope. The number of source systems, data quality, gift complexity and availability of staff for decisions and testing all affect the schedule. Allow time for cleansing, trial loads, reconciliation and corrections when setting the go-live date.
Can recurring donations and soft credits be preserved?
Yes, provided their meaning and relationships are understood and mapped correctly. Test recurring arrangements alongside their payment history, and check that soft credits preserve recognition without creating additional income in reports. Any payment collection integrations also need their own transition checks.
What happens to consent and Gift Aid data?
Identify the relevant fields, supporting history and record links during discovery, then agree how they will be represented and checked in the destination. Missing or conflicting information needs a decision from the responsible charity team. Transferring a record does not, by itself, establish permission to contact someone or eligibility for a Gift Aid claim.
Do we need to clean the data before moving it?
Review it early and agree which issues need resolving. Some corrections can be applied through controlled transformation during migration; others require decisions or changes in the source system. Leaving the review until the final import makes it harder to understand and test the consequences.
Who should be involved in the migration?
Include fundraising, finance, marketing, supporter care and data teams, alongside the Salesforce implementation team. Involve whoever is responsible for governance and retention decisions, and bring in volunteer or beneficiary service teams where their information is in scope. Give each area a named decision owner and time to test.
Let Migrate Ensure Your Data Quality With a Full Review
Speak with a Migration Expert
Migrate Data can review a sample of your source data, identify the main migration risks and provide a clearer basis for the project scope, budget and timeline.