The Salesforce Migration Checklist: 47 Items, 6 Phases, Zero Lost Deals
A Salesforce migration is not hard because the data is complex. It is hard because Salesforce hides more than you think: custom objects nobody documented, picklist values that became free text over five years, validation rules that will reject your import, and roll-up fields that mean nothing outside the platform. The teams that lose deals during a switch are the ones that treated the export as the whole job. The export is step one of forty-seven.
This is the checklist version of a migration, built specifically for leaving Salesforce. It is organized into six phases you can run in order, with the exact objects to pull, the field-mapping decisions that trip people up, the dedupe and owner-matching rules that prevent invisible deals, and a reconciliation standard that proves nothing was lost. Print it, assign an owner to each phase, and check the boxes.
Why a Salesforce migration needs its own checklist
Generic CRM migration advice assumes a tidy source system. Salesforce is rarely tidy by the time you want to leave it. It has been customized by admins who have moved on, extended by consultants who documented nothing, and filled with automation that fires on import in ways you will not predict. The specific traps are Salesforce-specific: standard objects like Account, Contact, Lead, and Opportunity are joined to a web of custom objects, record types split the same object into incompatible layouts, and formula and roll-up summary fields compute values that do not exist as stored data and therefore cannot be exported directly.
The other Salesforce-specific reality is the org itself. Your instance has profiles, permission sets, sharing rules, and an Object Manager full of fields that may or may not still be used. Migrating that governance model verbatim is a mistake. You are not moving Salesforce, you are moving the revenue data that lives inside it, and leaving the accumulated complexity behind is most of the value of switching.
So this checklist does two jobs at once. It gets your open pipeline and its history across without loss, and it uses the move as a forcing function to shed the dead fields, stale automations, and orphaned custom objects that made Salesforce feel heavy in the first place.
Items 1 to 9Phase 1: Inventory and freeze
Know exactly what you have before you touch it
- Export a record count per object
Run a report or use the Data Loader to count rows in Lead, Contact, Account, Opportunity, Task, and Event, plus every custom object. These counts are your reconciliation targets.
- List every custom object and its purpose
Open Object Manager and write down each custom object, what it holds, and whether the business still uses it. Orphaned custom objects are the easiest data to leave behind.
- Inventory automations that fire on write
Flows, Process Builder, Apex triggers, and validation rules can reject or mutate imported records. List them. You will disable the destructive ones in the target and never recreate the dead ones.
- List every integration and inbound feed
Web-to-Lead forms, marketing automation, Pardot or HubSpot sync, billing, calendar, dialers, and any API writing to Salesforce. Each is a pipe you re-point at cutover.
- Freeze schema and automation changes
Announce a hard freeze on new fields, flows, and picklist edits in Salesforce. A moving source cannot be mapped. Put a date on it and tell the admin team.
- Snapshot profiles and sharing
Document who owns what and who can see what, so you rebuild only the access model you actually need, not the accumulated one.
- Identify record types
If an object uses record types, each type may have different required fields and picklists. Map them separately or they collide on import.
- Name a single migration owner
One person owns the go or no-go call and the rollback trigger. Write the abort condition down now, not at 2am on cutover night.
- Set the reconciliation standard in writing
Open Opportunity count and total pipeline value must tie to the dollar, and every open deal must resolve to a real owner. Post it where the whole team sees it.
Items 10 to 22Phase 2: Export and map
The export is where Salesforce fights back
Export the six core objects first: Lead, Contact, Account, Opportunity, Task, and Event. Use the Data Loader or a full data export rather than ad hoc reports, because reports silently cap rows and hide fields. Pull the object Ids and the standard external keys alongside every record, because you will need those Ids to rebuild the relationships between objects on the other side. An Opportunity without its Account Id is an orphan, and orphans are how you lose the link between a deal and the company it belongs to.
Now the field map. For every field on every object, make one of three explicit decisions: it maps cleanly to a field in the new system, it needs a transform first, or it gets dropped. Build this as a real spreadsheet with columns for source object, source field, destination field, transform rule, and owner. The Salesforce-specific trap is formula and roll-up summary fields: they are computed, not stored, so they export as their current value but should almost never be mapped as raw data. Recreate them as computed fields in the destination or drop them. Mapping a roll-up as a static number freezes a value that was supposed to be live.
Do not migrate dead fields. The typical Salesforce org has hundreds of custom fields and uses a fraction of them. If a field is null on more than ninety percent of records and no report references it, it is a candidate to retire. Every field you drop is one less thing to reconcile and one less place for the new system to feel as cluttered as the old one.
The mapping checklist
- Export Lead, Contact, Account, Opportunity, Task, Event
Use Data Loader or full export. Include object Ids and relationship keys, not just display fields.
- Export required custom objects
Only the ones the business still uses. Leave orphans behind and note the decision.
- Build the field-mapping spreadsheet
Source object, source field, destination field, transform, owner. Every row gets a decision.
- Flag formula and roll-up fields
Mark them recreate-in-destination or drop. Never carry a computed value across as static data.
- Map record types to destination layouts
Each record type may need its own mapping. Reconcile them separately.
- Decide the field retirement list
Null-heavy, report-unreferenced fields are dropped on purpose, documented, not carried.
- Map every Salesforce owner to a real destination user
Owner names must resolve to active user accounts, or open deals land ownerless and invisible.
Items 23 to 31Phase 3: Clean and dedupe
Normalize picklists and dedupe on stable keys
Salesforce picklists rot. A Stage or Industry field that started as a fixed list becomes a mess of free-text variants once admins add values and users type their own. Before import, normalize each picklist to the fixed set you want in the new system, and build a translation table for the variants: "Closed - Won", "closed won", and "Won" all map to a single canonical value. Do this in the mapping spreadsheet so the transform is repeatable when you re-run it during the dry run and the cutover.
Deduplication is the other half. Old Salesforce orgs accumulate the same Account under three spellings and the same Contact under two email addresses. Dedupe on stable keys, a normalized email or a company domain plus a normalized name, not on display text that varies. Be conservative. A false merge that fuses two genuinely different companies is far harder to unwind after go-live than a leftover duplicate you clean up next week. When a match is ambiguous, do not merge, flag it for a human.
Items 32 to 43Phase 4 and 5: Dry run and cutover
The dry run and weekend cutover runbook
- Load a full copy into a sandbox first
Never let your first real import be into production. Load everything into a fresh workspace and reconcile counts against the Salesforce targets from Phase 1.
- Have reps validate their own deals
Two or three reps open their own Opportunities in the new system and confirm stage, value, next step, and history are intact. They catch what a count cannot.
- Fix the mapping and re-run
Every dry-run error is a mapping fix. Correct it in the spreadsheet and import again. The dry run is the cheapest insurance you will buy.
- Friday evening: freeze Salesforce
Set Salesforce read-only or announce a hard edit stop. From this moment it is a frozen snapshot and any deal activity goes to a holding doc.
- Export the final delta
Pull everything changed since the dry-run export. The delta is small because most data was validated already.
- Import the delta and reconcile one last time
Re-run the count and pipeline-value reconciliation. Open deals and total value must equal frozen Salesforce to the dollar before you proceed.
- Re-point every integration
Switch Web-to-Lead forms, marketing automation, billing, calendar, and API feeds to the new CRM. Send a test record through each and confirm it lands.
- Open the doors and watch the first 48 hours
Let reps in. Watch inbound lead flow and follow-up activity closely, which is when a missed integration shows up as a silent leak.
Items 44 to 47Phase 6: Stabilize and cancel
Do not cancel the renewal until you have proof
- Run Salesforce read-only in parallel for a week
Keep it available so anyone can cross-check a deal. Counts should still tie out at the end of the week.
- Confirm every integration lands in the new system
Re-check each inbound pipe after a few business days. This is the window where a form still posting to Salesforce reveals itself.
- Export a permanent compliance archive
Pull a full final export of Salesforce and store it. This archive is your permanent safety net and often a compliance requirement.
- Cancel the Salesforce renewal
Only after a clean parallel week with counts tied out and integrations verified. Not before. Then turn it off.
What makes the destination easy or hard to migrate into
| Migration factor | Ardovo | Legacy CRM | Spreadsheet |
|---|---|---|---|
| Guided import with mapping preview | Yes | Partial | No |
| Reset or sandbox workspace for a dry run | Yes | Partial | No |
| Built-in dedupe on stable keys | Yes | Partial | No |
| Live and usable on first load | Yes | No | Yes |
| AI operator validates owners and flags dupes on import | Yes | No | No |
| Time from import to working pipeline | Minutes | Weeks | None |
| One flat price during a dual-run overlap | Yes | No | Yes |
Legacy CRM column reflects a typical seat-plus-add-on configuration with migration tooling gated behind higher tiers or paid services.
Salesforce migration effort estimator
Size the job before you commit a cutover date. This models rough hands-on hours and the freeze window your team should plan around. Adjust the inputs on the live page to match your own org.
| Field and object mapping hours | 41 |
|---|---|
| Dedupe and picklist cleanup hours | 5 |
| Integration re-point hours | 11 |
| Estimated hands-on hours | 57 |
| Recommended freeze window (hours) | 10 |
The Salesforce-specific risks, and how to blunt each one
- A frozen Salesforce org means every mistake is recoverable by comparison.
- A full dry run into a sandbox catches validation-rule rejections before cutover.
- Dollar-for-dollar reconciliation proves no open Opportunity was lost.
- A retired-field list keeps the new system from inheriting the old clutter.
- Ownerless deals: unmapped Salesforce owners create invisible pipeline. Fix by hard-failing any record whose owner does not resolve.
- Frozen roll-ups: mapping a computed field as static data breaks live totals. Fix by recreating roll-ups in the destination.
- Validation-rule rejections: target rules reject legacy data. Fix by disabling non-essential rules during import, then re-enabling.
- Dropped integrations: a Web-to-Lead form still posting to Salesforce leaks leads. Fix by testing every pipe end to end at cutover.
- Record-type collisions: different layouts merged carelessly corrupt required fields. Fix by mapping each record type separately.
Why the destination decides how much of this you do by hand
A disciplined checklist protects you no matter what you migrate into, but the destination decides how much of it is manual. A CRM that is alive on first load, with a guided import that previews your mapping and built-in dedupe on stable keys, removes whole categories of work and whole classes of error before they happen. There is no blank-database configuration phase between import and value, so the day the data lands the pipeline is usable.
This is where Ardovo is built for the switch rather than against it. Rook, the built-in AI operator, checks that every open deal resolves to a real owner, flags likely duplicates, and fills obvious gaps as records arrive, so reconciliation becomes a confirmation rather than a scavenger hunt. And because Ardovo is one flat price across every module, the week you run Salesforce in parallel does not trigger a per-seat penalty on the tool you are turning off.
None of that replaces the checklist. You still freeze the source, still reconcile to the dollar, still run in parallel before you cancel the renewal. A good destination just means the safe path is also the fast one.
Frequently asked questions
How long does a Salesforce migration take?
For a small or mid-size org, plan on two to three weeks of calendar time: a few days to inventory and freeze, a week to export, map, and clean, a dry run, then a weekend cutover followed by a week of parallel running. Heavily customized enterprise instances with many custom objects and automations stretch the export and mapping phases, but the six-phase structure stays the same.
What Salesforce objects do I need to export?
Start with the six core objects: Lead, Contact, Account, Opportunity, Task, and Event. Then export only the custom objects the business still uses. Always pull object Ids and relationship keys alongside the display fields, because you need those Ids to rebuild the links between records in the new system.
How do I handle Salesforce formula and roll-up fields?
Do not migrate them as raw data. Formula and roll-up summary fields are computed, not stored, so exporting them freezes a value that was meant to be live. Recreate them as computed fields in the destination, or drop them if the destination rolls up the same total automatically. Mapping a roll-up as a static number is a common and quiet mistake.
How do I make sure I do not lose any deals?
Keep Salesforce frozen and read-only until you have proven the new system holds everything. The proof is reconciliation: the count of open Opportunities and their total pipeline value must equal Salesforce to the dollar, and every open deal must resolve to a real owner, before you turn anything off. Then run both in parallel for about a week.
Should I migrate all of my Salesforce history and fields?
No. Use the move to shed clutter. Leave behind orphaned custom objects, null-heavy custom fields no report references, dead leads past a cutoff, and duplicate junk. Migrating that data just recreates the heaviness you wanted to escape. Bring the open pipeline, active accounts, and the history attached to them.
When can I cancel the Salesforce renewal?
Only after a clean parallel week: counts still tied out, every integration verified landing in the new system, and a permanent compliance archive exported and stored. Cancelling before you have that proof removes your safety net at exactly the moment you might still need it.
Run your revenue on Ardovo
Everything alive on first load. Ask Rook and it does the work.