Decide what you are actually moving
The instinct is to move everything, and it is the single most expensive decision in the project. A database that has been running for six years contains a large number of records that were never worth having: duplicate entries from a lead source, people who bounced twice and have not been touched since 2021, and a long tail of names nobody in the office can identify.
Moving them costs you twice. Once in the effort of getting them across, and again every day afterwards, because a list you do not trust is a list you stop working. The useful question is not "what can we bring?" but "what would we re-enter by hand if it vanished tonight?" — and the honest answer is usually past clients, live pipeline, and the people who have referred you business.
Write that answer down before you export anything. It is the difference between a migration and a copy.
Get a clean export while you still have access
Do this first, and do it even if you have not finally decided to switch. An export is free, reversible and takes ten minutes; regaining access to a cancelled account to fetch one is none of those things. If your current vendor bills annually, the day you decide is the day to export, not the day the term ends.
Take the widest export the system offers — contacts, deals or transactions, notes, and activity history as separate files if that is how it comes. Then open them. An export that turns out to be missing notes is a discovery you want on day one rather than after you have cancelled.
Keep the raw files somewhere that is not the old CRM and not one person's laptop. They are the only complete copy of the relationship history your business has, for as long as the move takes.
Fix the data before it moves, not after
Duplicates, dead addresses and inconsistent stage names are much easier to fix in a spreadsheet than in a CRM, because a spreadsheet lets you sort by a column and see the whole problem at once. Sort by email, sort by phone, sort by last name — the duplicates announce themselves.
Agree the stage names before you move as well. Two people calling the same thing "Active" and "Under contract" is survivable in an old system everyone has learned to read around; it is corrosive in a new one, because it makes the pipeline report wrong on day one and the report is what convinces people the new system is worth using.
This is also the moment to decide what a contact means. If the old system filed everything under transactions, you will have people who exist twice — once as a buyer in 2022 and once as a seller in 2025 — and they need to become one person before they arrive.
Move in an order that keeps you working
Live pipeline first. Anything under contract or in active conversation goes across immediately, because that is the work that cannot wait for the project to finish. It is also a small enough set that entering it carefully is realistic.
Past clients second. They are the highest-value records you own and the ones most likely to be mangled by a bulk move, so they deserve the attention that the third group does not.
Everything else last, or never. If the long tail has not moved after a month, that is information: it was not worth moving.
Set one date and actually stop
The failure mode is the double-run — a fortnight where both systems are half-true, follow-ups get logged in whichever one happened to be open, and neither can be trusted. Two weeks of that will do more damage to a database than the migration itself.
Pick a date, tell everyone, and after it the old system is read-only. Keep the export and the old login for a quarter so you can go back for something you missed, but stop writing to it on the day you said you would.
What this looks like moving to ProspectKeeper
Worth being straight about the current state: contacts come across from a spreadsheet, while deals and follow-ups are entered in the app. For a live pipeline and a past-client list that is a focused session or two rather than a migration project.
So if your list is large, write to hello@prospectkeeper.com before you commit and we will tell you where import stands rather than letting you find out in week two. That is a worse answer than "upload your file", and it is the true one.
What you get in exchange is a database organised around the client rather than the transaction — a person can exist with no deal at all, a closed sale leaves the file open, and a second transaction on the same person takes the next filing letter beside the first. Which means the thing you were most afraid of losing in the move is the thing the system is actually built to keep.