Nobody stays on expensive software because they love it. They stay because the alternative involves moving fifteen years of records, retraining everyone, and being personally responsible if something goes wrong in the middle of a quarter.
That fear is rational. It is also manageable, and the way you manage it is by never being in a position where a switch has to work first time.
The principle: no cutover on faith
The single thing that makes a migration safe is running both systems at once. Your old CRM stays live and authoritative while the new one is loaded, tested, and used in parallel. You switch when your team says the new one is right — not on a date someone picked in a kickoff meeting.
Everything below serves that principle.
Phase 1 — Map what you actually use
Before anything is built, the current system gets inventoried: every object, field, automation, integration, report, and permission set. Then each one gets checked against usage in the last 90 days.
This is consistently the most surprising part of the project. Orgs that have been running for a decade routinely find that:
- A third or more of custom fields have not been written to in a year
- Several automations fire but nothing downstream consumes the result
- Whole objects exist for a process that ended two reorgs ago
- Two reports are used daily and forty exist
You are not migrating your Salesforce org. You are migrating the part of it that is alive. Knowing which part that is turns an intimidating project into a defined one.
Phase 2 — Build against real data
The replacement gets built and loaded with an actual copy of your records, not sample data. This matters more than it sounds. Real data brings real problems — the duplicate accounts, the free-text field that has eleven spellings of the same status, the contacts whose owner left in 2019. You want those surfacing during the build, not during cutover.
Historical records move too. Not just open pipeline — closed deals, activity history, attachments, and audit trail. If a salesperson cannot look up what happened on an account three years ago, they will keep the old system open and you have not actually migrated.
Phase 3 — Run both, and keep them in sync
Your team starts working in the new system while the old one stays live behind it. Records created in one appear in the other, so nothing is stranded on the wrong side.
This is where the fear actually gets resolved. People stop asking whether the new system will work and start noticing that they have not opened the old one in two weeks. That is the signal you are looking for — not a green tick on a test plan.
Run it for a few weeks at minimum. A full month is better, and if your business has a monthly or quarterly cycle, run through at least one complete one.
Phase 4 — Cut over on your renewal date
Work backwards from the renewal, not forwards from today. Two things matter:
Notice periods. Most enterprise agreements require written non-renewal notice 30 to 60 days before the term ends. Miss it and you auto-renew for another year — an expensive administrative mistake. Find that date first.
Never pay twice. Time the cutover so the old contract expires shortly after you stop needing it. A short overlap is sensible insurance. Six months of overlap is money set on fire.
What you should insist on, whoever does the work
Regardless of who you hire, these are reasonable things to require:
- A full export of your original data in open formats, kept by you, independent of the new system.
- Reconciliation counts. Record counts by object, before and after, with discrepancies explained rather than rounded away.
- A rollback plan for the cutover window, however unlikely you expect to need it.
- Documentation of what was built, so you are not dependent on one person's memory.
- Training before cutover, not after. People should already know the new system on the day it becomes the only system.
If a vendor is reluctant about any of those, that tells you something useful about the arrangement you are entering.
How long it takes
For a mid-sized team with a moderately customized org, expect four to six weeks to reach parallel running and a full quarter to complete cutover. Heavy custom code, multiple orgs, or regulated data extend that, and anyone who tells you otherwise before looking at your system is guessing.
The part people underestimate
The technical migration is the predictable half. The other half is that people have muscle memory, private workarounds, and spreadsheets they never told anyone about. Surface those early by watching how work actually gets done rather than reading the process documentation, which is usually aspirational.
A migration that handles the data perfectly and ignores the habits will get quietly rejected by the people expected to use it.
If you are weighing a move, a consultation is free. Bring your seat count, your edition, and — most importantly — your renewal date, because that is the constraint everything else schedules around.