CRM migration
Migrate to Salesforce Cloudfor customer experience excellence
A Salesforce move means reshaping your data around its objects, loading it in the right order and stopping your own automation from firing on every imported record.
Salesforce is a data model, not a server
Nothing about a Salesforce move resembles a cloud rehosting project, even though it sits in the same menu on this site. You aren't moving machines. You are reshaping customer data into objects, fields, record types and sharing rules that someone has to design first. Two customisations in the old CRM that look alike might need different treatment here: a custom field, a custom object, or a process that should be retired.
Choose the import tool by object and volume
- Data Import Wizard runs in the browser and handles up to 50,000 records at a time for most record types. Salesforce says it can't import assets, cases, campaigns, contracts, documents, opportunities or products, so most CRM migrations outgrow it quickly.
- Data Loader is a client application that handles larger volumes and those objects, from the interface or the command line. Salesforce recommends configuring it to use the Bulk API for large jobs.
- A scripted load through the Bulk API suits a migration you will rehearse repeatedly, because the same steps run the same way each time.
Load order and relationships
Parents load before children: users first, then accounts, contacts, opportunities and activities. Records in the new org get new Salesforce IDs, so a relationship can't rely on the old system's keys. The usual answer is a custom external ID field on each object holding the source ID. Later loads can then attach a contact to its account by that value, and a re-run can update what is already there rather than creating duplicates.
That same field is your audit trail. If someone asks where a record came from, you can trace it back to the source row for as long as the field exists.
History and dates
By default Salesforce sets created dates to the moment of import, which ruins reports on customer age and pipeline history. The Set Audit Fields upon Record Creation permission, also called Create Audit Fields, allows setting those values during a migration. It has limits: values can be written on insert only, not on update, so records must be correct the first time. Salesforce advises enabling it only for as long as the data operation needs it, then turning it off.
What fires during a load
Validation rules, triggers and flows all treat an import like any other change. A welcome-email flow can email every migrated contact. A validation rule added last year can reject records created five years ago. We list every automation on each object and decide, per load, what is bypassed and how, then confirm it is back on afterwards. We test all of this in a sandbox, with a sample that includes your oldest and messiest records.
What we can show you
We have no published Salesforce migration. Our CRM evidence is on the integration side: enquiries, customer data and orders sent from websites and a WooCommerce store into Microsoft Dynamics, with mapping, validation and retry on failure. If you need Salesforce configuration and licensing advice, you will want a Salesforce partner for that. We can handle the extraction, cleaning and reconciliation alongside them.
Salesforce migration questions
Can we keep the original created dates?
Yes, with the Set Audit Fields upon Record Creation permission, on insert only. Existing records can't be updated this way; they would have to be deleted and re-imported, so get it right during the first load.
Why can't we use the Data Import Wizard?
You can for smaller jobs on supported objects. It is capped at 50,000 records at a time for most types and doesn't handle opportunities, cases or products, which most CRM moves include.
What is in your current CRM?
Tell us the system, roughly how many records, and which history must survive. We will tell you what the load would involve and which part suits us.
We reply within one business day (IST).