Moving to Salesforce gives a charity an opportunity to improve how it manages supporters, fundraising, volunteering and services. But the success of the project depends heavily on what happens before any records are transferred.
Many charities have spent years building up information across fundraising databases, spreadsheets, website forms and other systems. Some of that information is valuable. Some may be duplicated, incomplete or no longer relevant.
Moving everything into Salesforce without reviewing it first can leave the organisation with a new CRM containing the same problems as the old one.
At Sweet Potato Tec, we approach data migration as part of a wider organisational improvement project. The objective is not simply to transfer records. It is to create a reliable foundation for the processes, reporting and supporter relationships the charity needs to manage.
How should a charity prepare for a Salesforce data migration?
A charity should prepare for a Salesforce data migration by identifying its existing data sources, deciding which information is genuinely needed, removing obsolete and duplicate records, and mapping the remaining data to the new Salesforce structure. It should also agree data ownership, review consent and retention requirements, plan integrations, test the migration, validate the results and train users before go-live.
What data should a charity migrate into Salesforce?
A charity should migrate information that is accurate, relevant and necessary for its future operations, rather than automatically transferring every record from its existing systems.
This is one of the most important decisions in the migration process.
A charity may have accumulated years of information about donors, volunteers, members, events, beneficiaries and organisations. Some records will remain essential. Others may relate to processes that are no longer used.
Before deciding what to move, the organisation needs to understand where its information currently exists.
That might include:
- A legacy fundraising CRM
- Membership databases
- Volunteer-management systems
- Programme or service-delivery records
- Event platforms
- Website enquiries and registration forms
- Donation and payment platforms
- Finance systems
- Departmental spreadsheets
The next step is to establish what each source contains and whether the information is still required.
For example, a charity might have several spreadsheets recording event attendance. If the information is needed for current supporter engagement or reporting, it may be relevant to the new Salesforce environment.
If it relates to an obsolete process and has no continuing operational or retention requirement, it may not need to be migrated.
This distinction matters because migration is an opportunity to simplify.
At Sweet Potato Tec, our Salesforce implementation approach begins with understanding how an organisation works, where its frustrations lie and which improvements will make the greatest difference.
For charities, that means asking what information is needed to support future operations before deciding how it should be moved.
How can charities decide which historical records to keep?
Historical information should be assessed according to its ongoing purpose, quality and applicable retention requirements.
A donor’s giving history may be important for fundraising analysis, stewardship and financial record keeping.
A volunteer’s previous involvement may provide useful context for future engagement.
Other information may no longer be needed.
Charities should agree clear criteria for what will be migrated, archived appropriately or disposed of in accordance with their retention policies.
The aim is not to delete historical information indiscriminately.
It is to avoid carrying unnecessary data into Salesforce simply because it exists.
How should charities clean and prepare their existing data?
Data cleansing should happen before migration wherever practical, so that Salesforce receives reliable information rather than inheriting known problems.
Poor data quality is one of the most common sources of complexity in CRM projects.
A charity might discover that the same supporter appears several times, with donations attached to different records.
Contact details may be outdated.
Important fields may be empty.
Organisation names may be inconsistent.
Records may use different categories to describe the same relationship.
These problems need to be understood before the data is imported.
Removing duplicate records
Duplicate supporter and organisational records can make it difficult to understand relationships accurately.
However, removing duplicates requires more than matching names.
Two supporters might share an email address, while the same person may appear under different names or contact details.
Charities should define matching criteria and establish how uncertain matches will be reviewed.
They also need to consider associated information.
If two supporter records are merged, what happens to their donations, event attendance, volunteering history and communication preferences?
A successful clean-up should preserve the relationships the charity needs.
Correcting incomplete and inconsistent information
The organisation should identify which fields are genuinely required and agree how information should be recorded.
That may involve standardising dates, addresses, categories, campaign names and other relevant values.
But charities should avoid filling missing information with assumptions simply to make records appear complete.
If information is unknown, it should be handled appropriately rather than invented.
Sweet Potato Tec’s published Salesforce data-quality guidance explains why data standards, ownership and regular monitoring are essential.
The principle applies equally to migration.
Cleaning data before it moves is important. Establishing processes that keep it clean afterwards is just as important.
What can charities learn from Sweet Potato Tec’s data-quality work?
Our work with Battersea Cats and Dogs Home demonstrates the value of improving the way information is prepared and processed before it reaches Salesforce.
The charity was receiving fundraising information from more than 50 agencies and channels, creating substantial manual administration and duplicate records.
Sweet Potato Tec developed an automated process to collect, standardise, validate and match supporter information before bringing it into Salesforce.
The published project results include an 80% reduction in manual data effort and approximately 75% fewer duplicate and error records.
This was a supporter-data integration and quality improvement project, rather than a published example of replacing an entire legacy CRM.
Nevertheless, it demonstrates a principle that is directly relevant to migration: the quality of information entering Salesforce has a major influence on how useful the platform becomes.
How should charity data be mapped to the new Salesforce structure?
Data mapping should define where each relevant piece of information belongs in Salesforce and how relationships between records will be preserved.
This is not simply a matter of copying columns from one database into another.
A legacy system may organise information very differently from Salesforce.
For example, a fundraising database might hold supporter details, donations and campaign information in one structure.
Salesforce may represent those relationships through several connected records.
A charity therefore needs to understand how its existing information should be translated into the new model.
That includes identifying:
- The original data source
- The information being migrated
- The corresponding Salesforce object and field
- Any transformation or standardisation required
- Relationships with other records
- Mandatory information
- The rules for handling missing or invalid values
Particular care is needed with relationships.
A donation must remain associated with the correct supporter.
A volunteer activity should remain connected to the appropriate person.
An organisational relationship should not be lost because two systems represent it differently.
Salesforce’s official migration guidance recommends preserving identifiers and importing related records in the correct sequence so that those relationships can be maintained.
Why should charities avoid copying the old database structure exactly?
Because the existing structure may be part of the problem the charity is trying to solve.
A legacy CRM may contain fields that were created years ago for processes that no longer exist.
Departments may have developed separate ways of recording the same information.
A migration gives the organisation an opportunity to agree a clearer and more consistent approach.
That does not mean redesigning everything unnecessarily.
It means distinguishing between information that remains valuable and structures that have become difficult to maintain.
At Sweet Potato Tec, we believe Salesforce should fit the organisation rather than forcing people to work around the technology.
Our Salesforce consulting and implementation services begin with discovery and process design so the resulting environment reflects how teams need to work.
Who should own the data migration and how should charities handle GDPR?
A charity should assign clear responsibility for migration decisions and review data-protection requirements before transferring personal information.
Migration is not solely an IT responsibility.
Fundraising teams understand donor records.
Volunteer coordinators understand volunteering information.
Finance teams understand transaction and reconciliation requirements.
Service-delivery teams understand programme or beneficiary information.
Technical specialists can manage the migration process, but they need input from the people responsible for the data.
The charity should establish who can approve decisions about:
- Which records are migrated
- How information is mapped
- Which duplicates are merged
- How incomplete records are handled
- Who can access sensitive information
- Which historical information is retained
- How the migrated data will be validated
Clear ownership prevents important decisions from being made by default during the technical import.
What should happen to consent and communication preferences?
Consent and communication-preference information should be reviewed and migrated accurately where it remains relevant and appropriate.
A charity may hold information about email communications, postal contact, telephone fundraising and other supporter preferences.
Those details can be distributed across several systems.
The migration needs to establish which records are authoritative and how relevant preferences should be represented in Salesforce.
Charities should not assume that a historic marketing preference remains valid for every future purpose.
Nor should missing information automatically be treated as permission to contact someone.
The organisation must follow applicable UK data-protection and electronic-marketing requirements, including relevant ICO guidance.
A migration should preserve reliable information about supporter preferences without creating misleading records.
How should sensitive information be protected?
Sensitive beneficiary, safeguarding or service information requires particular care.
The charity should review whether that information needs to be migrated, who should have access to it and how it will be protected during and after the transfer.
That may involve appropriate permissions, secure transfer methods, restricted access to migration files and defined retention arrangements.
A technically successful migration is not enough if the new system exposes information to people who should not see it.
Data protection needs to be part of the design from the beginning.
How should charities test and validate a Salesforce data migration?
Charities should test the migration using representative data before go-live, then validate the complete results after the final transfer.
Testing should not be left until the end.
A small test migration can reveal problems that are difficult to identify in a spreadsheet.
Fields may not map correctly.
Some records may fail validation.
Relationships may be missing.
Automations may behave unexpectedly when imported information is created or updated.
Users may find that essential information is difficult to locate.
These issues are easier to correct before the charity begins relying on the new environment.
Salesforce’s official migration guidance recommends testing imports, checking record counts, reviewing error logs and comparing samples of migrated information against the source.
For charities, testing should also reflect the way teams actually use the data.
Can fundraising staff see the correct donation history?
Are volunteers associated with the right activities?
Can finance identify the transactions it needs?
Are reporting categories consistent?
Do communication preferences appear correctly?
Can authorised users access the information they require without exposing restricted records?
What should be checked after migration?
Post-migration validation should confirm both technical completeness and practical usability.
The charity should compare source and destination records, investigate failed imports and verify important relationships.
It should also test everyday workflows and reporting.
A database containing the expected number of records is not necessarily accurate.
The records need to be correctly connected and useful to the people working with them.
A migration plan should therefore include a clear validation process, named reviewers and an agreed way of resolving issues before the system is accepted.
How should charities prepare integrations and employees before go-live?
Integrations and user training should be planned before the migration is completed, not treated as separate tasks after launch.
A charity may move its core supporter information into Salesforce while continuing to use other platforms.
Its website might still collect enquiries.
A donation platform may continue processing payments.
Events may be managed through a specialist system.
Finance may use separate accounting software.
The migration needs to consider how those systems will operate once Salesforce becomes part of the new environment.
Why should integrations be planned early?
Because connected systems can affect data quality and the migration itself.
If an existing website integration continues creating records in the old database while information is being transferred, the organisation may need to reconcile changes made during the migration period.
If the new integration uses different supporter-matching rules, duplicates may appear immediately after go-live.
If donation information arrives without the expected identifiers, records may not connect correctly.
These risks need to be considered during planning.
Sweet Potato Tec’s Boomi and Integration services help organisations connect Salesforce with the systems they depend on.
However, not every charity requires a complex integration platform.
The appropriate solution depends on the systems involved and the information that needs to move between them.
Our work with the Charity Retail Association provides a relevant nonprofit example.
Its website and Salesforce previously operated separately, while events and reporting involved manual processes.
Sweet Potato Tec introduced real-time website synchronisation and Eventbrite integration, helping teams work with more consistent, up-to-date information.
Although this was not presented as a complete legacy CRM migration, it demonstrates why integrations need to support the wider operating model.
Why should employees receive training before launch?
Because a new CRM can change how people complete everyday tasks.
Employees may need to understand where information is stored, how records are updated and which processes have changed.
Training should be relevant to each role.
A fundraiser needs different guidance from a volunteer coordinator or finance user.
The charity should also explain why certain changes have been made.
If people do not understand the new process, they may return to familiar spreadsheets or create workarounds that undermine the migration.
At Sweet Potato Tec, user adoption is a central part of our implementation approach.
We want teams to feel confident using Salesforce long after the project has finished.
That means involving the people who will use the system, gathering feedback and ensuring they have the support needed to work effectively from go-live.
What should a charity include in its Salesforce migration plan?
A practical migration plan should cover the decisions, responsibilities and checks needed before, during and after the transfer.
The following stages provide a useful starting point.
1. Define the purpose of the migration
Agree what the charity wants to improve, such as supporter visibility, fundraising administration, reporting or service coordination.
2. Identify every relevant data source
Create an inventory of existing databases, spreadsheets, platforms and operational systems.
3. Decide what needs to move
Agree which information remains relevant, which records should be archived and which information should not be transferred.
4. Assess and clean the data
Identify duplicates, incomplete records, inconsistent values and outdated information.
5. Agree ownership and governance
Assign responsibility for decisions about data quality, mapping, retention and validation.
6. Design the Salesforce data structure
Map the information and relationships into the new environment without unnecessarily reproducing the old system.
7. Review data protection
Consider consent, communication preferences, access controls, retention and secure transfer arrangements.
8. Plan connected systems
Identify which integrations need to be introduced, changed or maintained.
9. Test the migration
Use representative records to identify mapping, validation and relationship problems.
10. Prepare employees
Provide role-specific training and explain how the new processes will work.
11. Complete the transfer and validate the results
Check record counts, relationships, failed imports, workflows, permissions and reporting.
12. Establish ongoing ownership
Make sure the charity has a clear plan for data quality, administration and support after go-live.
The final stage is particularly important.
Data migration should create a better starting point for Salesforce, but the organisation still needs to maintain the information after the project ends.
Sweet Potato Tec’s Managed Services can support organisations with ongoing Salesforce administration, data governance, reporting and optimisation.
The objective is to ensure the improvements made during migration continue delivering value.
FAQs
How long does a charity Salesforce data migration take?
The timescale depends on the amount and condition of the data, the number of systems involved, the complexity of record relationships and the testing required. A relatively straightforward migration from one clean database may be considerably simpler than consolidating several legacy systems and spreadsheets. The charity should agree realistic timescales after discovery rather than assuming the transfer itself represents the entire project.
Can a charity migrate data from several systems into Salesforce?
Yes. Information from different databases, spreadsheets and applications can be prepared and brought into Salesforce, provided the organisation has agreed how records will be mapped, matched and connected. Consolidating several sources requires particular attention to duplicate records, conflicting information and data ownership.
Should charities migrate every historical donation?
Not automatically. The organisation should decide which historical donation records are required for fundraising, financial reporting, supporter relationships and applicable retention obligations. The migration plan should preserve necessary history and relationships without assuming that every available record must move into the new operational system.
Can Salesforce automatically clean data during migration?
Some tools and configured processes can support validation, standardisation and duplicate detection. However, technology cannot independently determine every correct relationship or resolve all conflicting information. Charities still need agreed rules, knowledgeable reviewers and appropriate quality checks.
What happens if records are missing after migration?
The migration team should investigate the discrepancy using source records, import logs, error reports and validation checks. A properly planned migration should retain appropriate backups and reconciliation information so missing or failed records can be identified and addressed. The organisation should not accept the migration solely because the import process has completed.
Does a charity need ongoing support after migrating to Salesforce?
Not necessarily from an external provider, but it does need clear ongoing responsibility. Users will need assistance, information will change and new requirements may emerge. Some charities manage Salesforce internally, while others use managed services or a combination of internal and external expertise. The important point is to plan for ownership after go-live.
Make the migration an opportunity to improve
A Salesforce data migration should not be treated as an exercise in moving as much information as possible from one system into another.
It is an opportunity to decide what the charity genuinely needs, remove unnecessary complexity and create more reliable information for the people using it.
That means reviewing existing records, agreeing data standards, preserving important relationships, addressing consent and retention requirements, testing carefully and preparing employees before launch.
At Sweet Potato Tec, our Salesforce implementation and consulting work begins with understanding the organisation rather than immediately configuring technology.
For charities, that approach helps ensure the new system supports fundraising, supporter engagement, volunteering, service delivery and reporting in a way that reflects how the organisation actually works.
If your charity is planning to replace a legacy database or bring disconnected information into Salesforce, speak to Sweet Potato Tec about your existing systems, data and objectives.
The right starting point is not deciding how quickly everything can be moved.
It is deciding what information your organisation needs, how it should be managed and what Salesforce should help you achieve.