Leaving Salesforce? The costliest mistake is moving everything.
Salesforce implementations accumulate over the years. What needs to move is not the history but the part still in use today. This guide is written from the perspective of a team that has run 200+ Salesforce projects.
Timing first: the right moment to move is your renewal date
We put this first because it is where most companies lose money: moving in the middle of a live Salesforce contract means paying for two systems at once.
So plan the migration around your renewal date and start early. We do not commit to a duration before discovery; after the discovery call we give you a date, not a range — but if you only start that conversation a few weeks before renewal, you will either rush it or pay for another year.
How do you plan a Salesforce migration?
-
1
1. Work out what is actually being used
List your standard and custom objects, fields and reports, and note against each whether it has been used in the last 90 days. Over the years some of those fields stop being filled in; only this list shows which ones. The decision about what moves follows from that list.
-
2
2. Inventory the automations
Write down what your automations actually do. These don't migrate — they get rebuilt — but you need to know what they do first. This is usually where you discover some of them are no longer needed.
-
3
3. Map the integrations
Every system connected to your current CRM — ERP, accounting, marketing tool, phone system — is its own line item. Which ones are still needed in the new system, and which are no longer used at all?
-
4
4. Export the data
Accounts, contacts, leads, opportunities, activities and attachments. Don't forget files and attachments; you need to export them while your account is still open, because what access you have after the contract closes is set by your own contract — and we have not measured it.
-
5
5. Define a parallel-running period
Rather than running two systems side by side indefinitely, it works better to set a cut-over date and leave the old system read-only: when data goes into two places at once, it becomes unclear which record is current. We have seen this in our own projects.
What you won't move
A migration is the best opportunity you'll get to drop accumulated weight. What usually shouldn't move:
- Unused custom fields. A field carried over “in case we need it” stays empty in the new system too.
- Reports nobody opens. You don't migrate a report, you migrate a need. Asking “what question are we trying to answer” and rebuilding it is faster.
- Old campaigns and duplicate records. Migrating the cleanup is the same as postponing the cleanup.
- Automations that stopped working. Don't rebuild flows that were set up years ago and have since broken.
For historical data you want to keep, exporting and archiving it is usually better than migrating it — it stays out of daily use.
About the Salesforce migration
Can Salesforce data be fully exported?
What happens to our custom development (Apex, Lightning)?
Our team is used to Salesforce — won't they struggle?
Does selling stop during the migration?
How long does it take?
Let's look at your implementation together.
We'll work out which objects and automations you actually use. If a migration isn't right for you, we'll say so.
30 minutes · No obligation · The call is held in Turkish
