Searchlab Data Migration
Migration quietly decides whether people trust the new system. If the first record a rep opens is wrong, adoption stalls and never recovers. We profile, clean, map, load and reconcile, so the org opens on day one with data your team recognises.
Work starts with profiling, not loading. We extract from your current system, count records per object, and look at what is really in the fields: blank phone numbers, five spellings of the same city, owners who left two years ago, deals with no close date. That profile decides how much cleanup happens before the load and how much can wait until later.
Mapping is documented field by field. Source field, target field, transformation, default value, and what should happen when the source is empty. External IDs are created on every object so loads run as upserts and can be rerun safely. Load order follows the relationships: accounts first, then contacts, then opportunities, then activities, cases, notes and attachments.
Loading uses the right tool for the volume. Data Import Wizard for small deduplicated imports, Data Loader or the Bulk API for anything large, and an ETL tool such as Talend, Jitterbit or dataloader.io when transformation is heavy or the migration has to repeat on a schedule. Triggers, flows, validation rules and email alerts are disabled during the load, then re enabled and retested.
Every load is reconciled. Record counts per object, spot checks on your highest value accounts, total open pipeline compared against the source, and a written exception log for anything rejected. Matching and duplicate rules are switched on immediately after the load, so the org starts clean and stays clean instead of being cleaned twice.
Everything in Data Migration
Data profiling report
Record counts, field fill rates, duplicate estimates and quality issues per object, with a recommendation on what to clean, what to merge and what to leave behind.
Field mapping workbook
A row for every field showing source, target, transformation and default value, reviewed with your team so nothing important is silently dropped in transit.
External ID strategy
Unique external identifiers on each object so loads run as upserts, can be rerun without creating duplicates, and can be traced back to the source record.
Trial load in a sandbox
At least one full rehearsal into a Partial Copy or Full sandbox, timed and reviewed, so the production window holds no surprises for anyone.
Historical records and files
Closed deals, past cases, notes, attachments and activity history loaded where they earn their keep, with audit fields preserved wherever Salesforce permits it.
Duplicate and matching rules
Matching rules and duplicate rules configured on leads, accounts and contacts, with block or alert behaviour agreed per object before go live.
Reconciliation report
Counts, totals and exception logs comparing source to target after each load, signed off before the legacy system is switched to read only.
Cutover runbook
A timed plan for the migration window covering data freeze, load sequence, verification checks, the rollback trigger and who makes the go or no go call.
The process
Profile and cleanse
We extract the source data, measure its quality, then run deduplication and standardisation on the extract. Cleaning outside Salesforce is faster and far safer than cleaning inside it afterwards.
Map and rehearse
Fields are mapped in a workbook, then loaded into a sandbox as a full rehearsal. Errors, timings and record counts from that rehearsal shape the production plan.
Production load
Automation is paused, records load in dependency order using Data Loader or the Bulk API, and each object is verified before the next one begins loading.
Reconcile and hand over
Counts and totals are compared against source, exceptions are worked through, automation is switched back on and retested, and the reconciliation pack goes to you for sign off.
Questions about Data Migration
How much history should we bring across?
Bring what people use. All open records, all accounts and contacts, and usually two to three years of closed deals and cases. Older history can stay in an archive or a read only copy of the legacy system. Loading ten years of activity often costs more in storage and cleanup than it ever returns.
Can you keep the original created dates?
Yes, in most cases. Salesforce has a Set Audit Fields upon Record Creation permission that lets us write the original created date, created by, last modified date and record owner during migration. We enable it for the load window and switch it off immediately afterwards.
What happens if a load fails halfway?
Upsert on external IDs means a rerun updates records rather than duplicating them, so a partial load is recoverable. The cutover runbook defines the rollback trigger, and every load produces success and error files. In a properly rehearsed migration a full rollback is rare, but the plan exists before we start.
Will migration break our automation?
It can, if automation runs during the load, which is why triggers, flows, validation rules and email alerts are disabled for the window. Anything that must fire, such as an assignment rule, is run deliberately afterwards. Bulk safe code matters here, because a trigger written for one record fails at fifty thousand.
Ready to talk about Data Migration?
Tell us where you are stuck. We reply within the hour on WhatsApp, usually sooner.
Or email Searchlabtools@gmail.com