How to Migrate from Salesforce to Open Source CRM

Step 1: Audit Your Salesforce Data

Before exporting anything, build a complete picture of what you are migrating. This audit prevents surprises during the import phase and ensures nothing critical is left behind.

Catalog your objects. Start with Salesforce's standard objects: Accounts, Contacts, Leads, Opportunities, Cases, Tasks, Events, Notes, and Campaign Members. Then document every custom object your organization has created. For each object, record the number of records, the fields in use (including custom fields), and the relationships to other objects. Salesforce's Setup menu under Object Manager shows all objects and their field configurations.

Document your customizations. List all custom fields with their data types, picklist values, validation rules, and formula fields. Record your opportunity stages and their probability values. Document your lead conversion mapping (which lead fields map to which contact and account fields). Note any record types, page layouts, and business processes that differ by team or division.

Map your automations. Salesforce Process Builder flows, Apex triggers, validation rules, and workflow rules represent business logic that needs to be recreated in your new CRM. Export or screenshot each automation and describe what it does in plain language. Prioritize the automations by impact: which ones affect daily operations and which are rarely triggered? Focus on recreating the high-impact automations first and deferring the rest.

Inventory your integrations. List every external system connected to Salesforce: email providers (Gmail, Outlook), marketing platforms (Pardot, Marketo, Mailchimp), accounting software (QuickBooks, Xero), phone systems, data enrichment services, and custom API integrations. For each integration, note what data flows in which direction and how frequently. Some integrations will have direct equivalents in your open source CRM; others may need custom API work.

This audit typically takes a few days for a small Salesforce org and up to two weeks for complex enterprise implementations. The time invested here directly reduces problems during the import phase.

Step 2: Set Up and Configure the Target CRM

Install your chosen open source CRM and configure it to match the structure you documented in the audit before importing any data. Importing into an unconfigured CRM creates more cleanup work than configuring first.

Create custom fields. For each custom field in Salesforce, create the equivalent field in your open source CRM. Pay attention to data types: a Salesforce picklist becomes a dropdown/enum field, a lookup field becomes a relationship/link field, a formula field may need to be recreated as a calculated field or workflow. SuiteCRM handles this through Studio, EspoCRM through the Entity Manager, and Twenty through its field configuration interface.

Configure pipelines. Recreate your Salesforce opportunity stages in the new CRM's pipeline configuration. If you used multiple record types with different stage sets in Salesforce, set up multiple pipelines in EspoCRM (which supports this natively) or create the equivalent structure in SuiteCRM or Twenty. Map probability values to each stage to preserve your forecasting methodology.

Set up user accounts and roles. Create user accounts for your team members in the new CRM. Configure role-based access control to match (or improve upon) your Salesforce profile and permission set structure. This is also a good opportunity to simplify overly complex permission schemes that may have accumulated in Salesforce over the years.

Build essential automations. Recreate the high-priority automations you identified in the audit. SuiteCRM's workflow module handles most Salesforce Process Builder equivalents. EspoCRM's formula engine and Advanced Pack BPM cover complex automation scenarios. Focus on automations that affect data integrity and daily workflows first; convenience automations can be added after migration.

Step 3: Export Data from Salesforce

Salesforce provides several tools for bulk data extraction, and the right choice depends on your data volume and technical comfort.

Data Export Service is the simplest option. Navigate to Setup > Data Export > Export Now. Salesforce generates a set of CSV files for all standard and custom objects and sends a download link by email. The export includes all fields for each object. This method works well for organizations with moderate data volumes and is available on all Salesforce editions. The limitation is that you cannot filter or customize the export, so you get everything including records you may not need.

Data Loader provides more control. This standalone application (available as a desktop app or CLI tool) lets you export specific objects with SOQL queries, so you can filter records by date range, owner, record type, or any other criteria. Data Loader handles larger datasets more reliably than the web-based export and supports scheduled exports for incremental migration scenarios. Use Data Loader if you need to export objects selectively, filter records, or handle datasets exceeding 200,000 records per object.

Salesforce API enables the most precise extraction for organizations with development resources. The Bulk API 2.0 efficiently handles millions of records. Python libraries like simple-salesforce make it straightforward to write extraction scripts that pull exactly the data you need in exactly the format you want. This approach is best for complex migrations where data needs to be transformed during extraction.

Regardless of the method, export all object types even if you are unsure whether you need them. Having the data available and choosing not to import it is better than discovering a gap after the migration is complete. Store the exported CSV files in a secure location with a clear directory structure: one file per object, named consistently.

Step 4: Map and Transform the Data

This is the most labor-intensive step and the one that determines whether your migration produces clean, usable data in the new system.

Create a field mapping spreadsheet. For each object type, create a mapping that shows the Salesforce field name, data type, and sample values alongside the corresponding field in the target CRM. Common mappings are straightforward: Account Name maps to Account Name, Contact Email maps to Email Address. Tricky mappings include Salesforce lookup fields (which store an 18-character record ID that needs to be resolved to the corresponding record in the new CRM), multi-select picklists (which may be stored differently), and formula fields (which need to be recreated as native calculations in the target system).

Handle Salesforce IDs and relationships. Salesforce uses globally unique 15 or 18 character IDs to link records together. An opportunity's AccountId field contains the ID of the related account record. During migration, you need to translate these Salesforce IDs into the new CRM's record IDs. The standard approach is to import parent records first (accounts), store a mapping of old Salesforce IDs to new CRM IDs, then use that mapping to resolve the relationship fields in child records (contacts, opportunities) before importing them. A simple spreadsheet or script that maintains this ID mapping is essential.

Clean the data. Migration is the ideal time to clean up data quality issues that have accumulated in Salesforce. Deduplicate contacts and accounts. Standardize company names, phone number formats, and address fields. Remove test records, inactive contacts, and orphaned records. Fix obvious data errors. This cleanup effort makes the new CRM more useful from day one and is far easier to do during the transformation phase than after import.

Transform formats. Date formats may need conversion (Salesforce uses YYYY-MM-DD, but your import tool may expect a different format). Currency values should be standardized to a consistent decimal format. Picklist values need to match exactly the values configured in the new CRM (including capitalization and spacing). Multi-select values often need to be converted from Salesforce's semicolon-separated format to whatever delimiter the target CRM expects.

Step 5: Import Data into the Open Source CRM

Import records in dependency order so that relationships can be established correctly. The standard sequence is: users, accounts/companies, contacts, leads, opportunities/deals, activities (tasks and events), notes, and then any custom objects.

Use the CRM's built-in import tool for standard objects. SuiteCRM, EspoCRM, and Twenty all provide CSV import functionality through the admin panel. Upload the CSV file, map source columns to CRM fields, configure duplicate handling rules, and run the import. Most CRM import tools provide a preview of the first few records so you can verify the mapping before committing.

Run test imports first. Before importing the full dataset, import a small subset (50 to 100 records) for each object type. Verify that fields map correctly, relationships link properly, dates and currencies display as expected, and no data is truncated or corrupted. Fix any mapping issues and re-run the test until the results are clean. Only then proceed with the full import.

For large datasets or complex relationships, use the CRM's API for import instead of the CSV upload tool. API-based import gives you programmatic control over error handling, relationship linking, and progress tracking. Python scripts using the requests library can iterate through CSV rows, create records via the REST API, and log the old-to-new ID mapping for relationship resolution. This approach is more work to set up but handles edge cases more gracefully than bulk CSV import.

Preserve historical data. Import closed opportunities with their original close dates and amounts to maintain historical reporting. Import completed activities with original timestamps. If the CRM supports it, set the created date on imported records to match the original Salesforce creation date so that timelines and reports reflect actual history rather than the import date.

Step 6: Validate and Reconcile

After importing all data, perform a systematic validation to confirm the migration is complete and accurate.

Compare record counts. For each object type, compare the number of records in Salesforce against the number successfully imported into the new CRM. Account for any records intentionally excluded during the cleaning phase. Any unexplained discrepancy indicates dropped records that need investigation.

Verify relationships. Spot-check at least 20 records per object type. Open an account and verify its contacts, opportunities, and activities are linked correctly. Open an opportunity and confirm the associated account, contacts, and activity timeline match Salesforce. Check that contact-to-account associations survived the migration.

Test key workflows. Walk through your core business processes in the new CRM. Create a new lead and convert it. Move an opportunity through all pipeline stages. Log a call and schedule a follow-up task. Send an email from within the CRM. Generate a pipeline report. Each of these workflows should work correctly with the migrated data.

Run comparison reports. Generate pipeline value reports, contact counts by account, and activity summaries in both Salesforce and the new CRM. The numbers should match (within the margin of any intentional data exclusions). Pay special attention to currency totals, which are sensitive to rounding differences and currency conversion discrepancies.

Plan the cutover. Once validation is complete, plan the final switch. Options include a hard cutover (everyone switches on a specific date), a parallel run period (both systems active for two to four weeks), or a phased migration (teams switch sequentially). The parallel run approach is safest because it provides a fallback, but it creates the burden of maintaining data in two systems. Most organizations find that a hard cutover with thorough pre-migration validation is the most practical approach.