The Salesforce migration checklist

Decide what is moving

The instinct is to move everything, so nothing is lost. The result is usually a new system that looks exactly as cluttered as the old one, with a decade of dead leads and test records carried over at real expense.

A more useful split:

• Move: every account and contact you have done business with or are working now, every open deal, closed deals from the last two or three years (enough for win rates and renewal history), and the activity and notes attached to all of those.
• Archive: older closed deals and their history. Export them to files you keep somewhere safe and searchable. Someone will ask about a deal from 2017 exactly once a year.
• Leave behind: leads with no activity in two years, duplicate and test records, and fields nobody has filled in since they were created.

Write the rules down and get the head of sales to agree to them before you start. It is much easier to defend “we agreed in March to leave unworked leads behind” than to argue about one lead at a time.

Clean before you export

Cleaning data in Salesforce, where your team already knows the tools, is easier than cleaning it in a new system nobody knows yet. A week spent here saves a month later.

• Merge duplicates, starting with accounts. A duplicated account splits its contacts and deals in two, and that split will survive the move.
• Reassign records owned by people who have left. If the owner does not exist in the new system, the record ends up with whoever ran the import.
• Tidy picklists. Fifteen spellings of “Inbound” in Lead Source become fifteen values somewhere new. Agree the final list now.
• List your stages and what each one means, so you can decide where each maps. This is a good moment to write proper exit criteria rather than copying stages that stopped meaning anything years ago.

Export and import in order

Records refer to each other. A contact points at an account, a deal at an account and a contact, an activity at whatever it was about. Import them in the wrong order and those links have nothing to point at.

1. Users, so every record can keep its owner.
2. Accounts.
3. Contacts, linked to their accounts.
4. Leads.
5. Opportunities, linked to accounts and contacts.
6. Activities and notes, last, because they can belong to any of the above.

Keep the Salesforce ID

Every Salesforce record has an 18 character ID. Bring it across into a field on the new record. It is how relationships get rebuilt during the import, how you can rerun a failed file without creating duplicates, and how, six months from now, you can answer “where did this record come from?” without guessing.

Make a list of what Salesforce did for you

This is the step teams skip, and it is the one that causes the most trouble. Over the years Salesforce picked up workflow rules, Process Builder processes, Flows, validation rules, assignment rules and scheduled reports. Many of them were built by people who have since left. Nobody remembers they exist until the thing they did stops happening.

Go to Setup and list every active automation, with one line on what it does. Then sort each into rebuild, replace or retire. Expect at least a third to be retired: rules that fired for a product you stopped selling, or alerts nobody reads.

Do the same for reports and dashboards, with one shortcut: only rebuild the ones someone actually opened in the last ninety days. Salesforce can tell you which those are. The rest can be recreated on request, and usually nobody asks.

Cut over on a Monday

Pick a cutover date at the start of a week and not at the end of a quarter. Do the final export on Friday evening, import over the weekend, and have the team start Monday in the new system with Salesforce switched to read only. Keep it read only for a month in case someone needs to check something, then let the licences lapse.

Avoid running both systems as live for weeks. It sounds safe, and in practice reps update whichever is open, and by the end you have two partial truths and a reconciliation project.

Give every rep a short session in their first week with their own data on screen, not a demo account. People adopt a system when they can see their own deals in it.

The checklist

Four weeks before

• Written rules for what moves, what is archived and what is left behind, agreed by sales leadership
• Duplicate accounts and contacts merged
• Records owned by former employees reassigned
• Picklist values agreed and cleaned
• Stage mapping written down, with exit criteria for each new stage
• Every active automation listed and sorted into rebuild, replace or retire
• Reports opened in the last 90 days listed

Two weeks before

• Users created in the new system
• Test import of one team, checked by two reps
• Automations marked rebuild are rebuilt and tested
• Archive export of older records saved somewhere searchable

Cutover weekend

• Final export on Friday evening, including the Salesforce ID on every record
• Import in order: users, accounts, contacts, leads, opportunities, activities and notes
• Record counts compared with Salesforce for each object
• Salesforce switched to read only

First month

• A session with each rep on their own data in week one
• Daily check for import errors and anything reported missing
• Salesforce licences allowed to lapse once nobody has needed it for two weeks

If you are moving to SalesOS

The migration tool in SalesOS (under Settings, “Import and migrate from another CRM”, on Professional and Enterprise) was built around this checklist. It recognises Salesforce exports and suggests the field mapping, imports users, accounts, contacts, leads, opportunities, activities and notes in one batch in the right order, keeps each record’s Salesforce ID and uses it to rebuild links between records, and matches owners by ID, name or email. For duplicates you choose, per object, whether to skip, update or create. Your stage and status values are mapped explicitly, and a whole migration can be rolled back if the result is not what you expected.

The step by step Salesforce migration guide covers the export itself, and SalesOS compared with Salesforce covers whether moving is worth it at all.