We move accounts, contacts, opportunities, cases and history into Salesforce with profiling, deduplication, reconciliation gates and a rehearsed cutover, so day one looks like the plan.
Data migration is where Salesforce projects quietly fail. The build is fine, the training is done, and then sales opens the org and finds three copies of every customer. We run the data stream as its own workstream, with its own gates.
Everything below lives in your repository and your org when we leave. Nothing depends on a tool licence we hold.
Every source field mapped to a Salesforce field with type, transformation rule and business owner. Signed off before the first load.
Re-runnable Python or Node.js loaders on Bulk API 2.0, versioned in Git and logged by load id. The same script runs rehearsal and production.
Match keys and survivorship rules per object, tested on your real data, then kept alive as platform duplicate and matching rules.
Record counts, field-level reconciliation and sample audits, produced for every rehearsal and again for the production run.
Freeze window, load sequence, owners, go/no-go criteria and the communication plan. Rehearsed twice before it matters.
Backup before load, delete-by-load-id scripts, and a decision rule agreed in advance so nobody argues at two in the morning.
Seven steps and three sign-off gates. Nothing reaches production until the sandbox load reconciles and business users have audited real samples.
Pull a full snapshot from each source by API or export, with a repeatable delta query for changed records.
Measure nulls, formats, orphans, duplicates and outliers per field. The profile report decides scope and gets signed off.
Source to target field mapping in a workbook, including picklist translations, record types and ownership rules.
Scripts apply the mapping: dates, currencies, phone formats, lookups resolved by external id, exclusions applied.
Match rules group records; survivorship rules pick the winning values. Merges are logged so they can be reviewed.
Objects load in dependency order, automation bypassed where agreed, every batch tagged with a load id.
Counts, field-level reconciliation and business sample audits. Rehearsed in a sandbox, then repeated in production.
Dedupe is two decisions, not one. Match rules decide which records are the same entity. Survivorship rules decide which values win when sources disagree. Both are tested on profiled data and reviewed with the people who own the records.
| Object | Match keys (starting point) | Survivorship rule |
|---|---|---|
| Accounts | Normalised name + website domain + country; registration number where held | Record with the most recent closed-won opportunity wins; longest complete address kept |
| Contacts | Email; fallback name + account + phone | CRM record beats marketing list; non-null values fill gaps; most recent consent status wins |
| Leads | Email + company | Converted leads are dropped; newest open lead wins; older ones become activity history |
| Opportunities | Source id only, never matched by name | System of record for revenue wins outright; the other source is archived as notes |
| Cases | Source case number; thread id for email-to-case | Status and owner from the live system; description from the richest source |
A "duplicate" in a marketing list is often two real people at the same company. Merging them loses a contact and a consent record. We review every rule against the profile report before it touches a record.
Source rows minus agreed exclusions must equal Salesforce rows, per object and per load id. Any difference is listed in the exceptions log with a reason.
For the fields that matter (amount, stage, close date, status, owner) we compare every record, not a sample. Pipeline by stage and cases by status must match to the unit.
Business users check 30–50 records per object against the old system during UAT: addresses, notes, attachments, history. Their written sign-off is gate three.
The production run is the third time the scripts execute, not the first. Here is the shape of a typical cutover for a single-source migration.
Full load into a production-like sandbox with the final mapping. The mapping is locked. The freeze window and user communications are agreed with sales and support leads.
We extract records changed since the rehearsal and dry-run the delta. Inbound integrations are scheduled to pause so nothing writes during the load.
Backup, then full or delta load in object order. Gate two counts, gate three sample audit, go/no-go call. Users return to a clean org, or the rollback runs by load id.
Exceptions queue worked daily, duplicate rules switched on, integrations resumed in sequence, ownership and sharing spot-checked with each team.
Ten things to settle before the first load. Each one has cost a project a week when it was left to the day.
Scanned contracts, order forms and PDFs sitting in the old system are a separate problem. Our document processing work turns them into fields and files before they are loaded, rather than migrating a pile of attachments nobody can search.
Migration as one phase of a full build, from discovery through hypercare.
ReadKeep ERP, telephony and warehouse data flowing after the move.
ReadPipelines and warehouses that feed clean CRM data into AI systems.
ReadWhy a clean CRM is the first AI project, and how to measure readiness.
ReadAudit the target org before you load years of data into it.
ReadImplementation, clouds, AI, development, integrations and support.
BrowseThree to eight weeks for a single-source migration of accounts, contacts, opportunities and cases with a few years of history. Multi-org consolidations and heavy activity history run longer. The profiling step in week one tells us which end of the range you are at.
Bulk API 2.0 through scripted loaders (Python or Node.js) for anything repeatable, Data Loader for small one-off sets, and the platform's duplicate rules for ongoing protection. We avoid point-and-click ETL for the production run because every load must be re-runnable and logged.
Yes. We run a full load into a sandbox and then production while the old system keeps working, then apply a delta load during a short freeze window. The freeze is typically 4–24 hours, agreed with sales and support leads in advance.
Every production load is tagged with a load id and preceded by a backup. If a gate fails we stop, then either fix forward or roll back by deleting that load id. The decision rule is agreed in the cutover runbook before the day, not during it.
Usually yes, but we scope them separately because volume drives time. Files move to Salesforce Files with ownership preserved; emails and tasks are loaded as activities with their original timestamps. Very large archives often belong in a searchable knowledge base rather than the CRM.
Tell us about your systems, your data and your constraints. We reply within one business day with a straight answer and a suggested next step.