Who this is for
This CRM migration checklist is for teams replacing a legacy CRM, a spreadsheet, or a shared inbox as the sales system of record. The owner is usually an operations lead, IT manager, finance lead, or sales manager who must keep deals moving during the switch. The work mixes project management, data plumbing, and change management.
It fits a company with live deals, quotes, and handoffs into delivery or finance. If you are moving only contacts with no open pipeline, you can shorten the activity and integration steps. If you are also changing sales process, split the two efforts. Move the current model first.
This guide does not cover pipeline stage design, lead routing, duplicate clean up, forecasts, or field trimming. Other guides cover those. This one covers extraction, mapping, test loads, cutover, reconciliation, and the first week of live support.
Before you begin
Write the scope on one page. Name the old system, every source that feeds it, and the new system. List objects in scope: accounts, contacts, deals, activities, notes, attachments, quotes, and products. Add every integration that reads or writes CRM data, including email, calendar, phone, support desk, marketing, billing, and e signature. Name one accountable owner and one technical lead.
Export a full backup before anyone edits the old system. Use the native export, a reporting export, or a read only API pull. Save raw files and a record count per object where the migration team can reach them. Check that attachments and notes are included, not just main records. If the old vendor restricts exports, raise it on day one.
Define acceptance tests in plain language. Every open deal must appear with the same owner, amount, stage, and close date. Linked contacts must stay linked. A sample quote must generate, and a signed deal must hand off to delivery or finance. A sample report must match the old report within an agreed tolerance. Write the tests before the field map.
Set a change freeze on the old system for the cutover window. Tell sales, finance, and support what stops and when. Pick a time away from month end and quarter end if you can. Agree on a rollback point: the backup and a decision time to restore rather than keep fixing live.
The checklist
Run the checklist in order. The first pass is discovery, the second is a sandbox rehearsal, and the third is live cutover. Do not combine the data move with a redesign of stages, fields, or routing. That makes reconciliation impossible because you cannot tell a migration error from a design choice.
Use a migration ID on every record. Build a stable key from the old record ID plus object type, and store it in a text or external ID field. The key lets you reload without creating a second copy, match activities to the right deal, and trace a bad row back to the source. Never match on company name or email alone.
Test with a full copy, not ten rows. A small sample hides picklist errors, owner gaps, attachment failures, and time zone problems. Load into a sandbox, run the acceptance tests, fix the map, then wipe and reload. The live cutover should repeat a process you have already run end to end.
- Inventory every source system and export each object to a raw file before you change anything.
- Record row counts for accounts, contacts, open deals, activities, notes, attachments, and quote records.
- Build a field map naming the old field, new field, data type, owner, and rule for blank values.
- Create a migration ID for each record and store it before you load related records.
- Map owners by user ID, not display name, and list every user who cannot be matched.
- Convert picklists and stages with an explicit value table, and decide what happens to unmatched values.
- Decide which historical activities and notes move, then document the cutoff date in the plan.
- Test attachments and notes with large files and unusual types, and confirm storage limits.
- Load in order: accounts, contacts, deals, activities, notes, attachments, then quotes.
- Run acceptance tests in a sandbox and compare sample records side by side in both systems.
- Freeze the old system, take a final delta export, and load only records changed since rehearsal.
- Switch email sync and integrations after the data load, then watch error logs for one business day.
- Train users on the new layout, stages, quote steps, and handoff steps.
What good looks like
A good migration is boring to audit. Row counts reconcile, or every difference has a written reason. Every open deal has an owner, stage, amount, and next step. Linked contacts stay linked. Activities that matter to the current sales cycle sit on the record, not in an export.
Acceptance tests pass in the live system, not just the sandbox. A salesperson can create a quote, send it for approval, and see the result. A signed deal creates the delivery or finance handoff. Email and calendar sync work for a test group. Leadership reports match the old numbers or the agreed tolerance.
Users know what changed and where to ask for help. There is a named owner for the first two weeks, a short list of known gaps, and a review date. The old system is read only, not deleted. The backup is stored and tested. A missing deal can be traced by migration ID and fixed without a full reload.
What to do next
Start with the backup and the inventory. You cannot plan a cutover until you know which objects, attachments, and integrations exist. Assign the owner and technical lead, then write the acceptance tests. That gives you a scope you can estimate.
If you run the migration yourself, book a sandbox and two rehearsal loads before the live window. If you use a vendor, ask for a written field map, test plan, rollback plan, and fixed cutover window. Do not accept a plan that starts with a live load.
You can also use a package. Cloudverg's Sales CRM implementation is a fixed price package at $9,500 that runs 3 to 4 weeks and starts within 10 business days, covering stages, contact and deal model, quote templates, follow up sequences, handoff workflow, reporting, training, and an admin guide. It fits teams moving from spreadsheets or inboxes, but it is one option among others. Compare it with your own build or another vendor against the same acceptance tests.
Frequently asked questions
How long does a CRM migration take?
It depends on data volume, attachments, integrations, and how many rehearsals you need. A small move from spreadsheets can be planned in days and cut over in a weekend. A legacy CRM with custom objects and several integrations needs weeks of mapping and at least two test loads. The cutover itself is usually a short window, but the preparation is the long part.
Can we migrate from spreadsheets to a CRM without losing history?
Yes, if you export each sheet to a clean file and map columns to CRM fields before loading. Keep the raw files as the backup and use a migration ID so you can reload or correct rows. Decide in advance which tabs and notes are worth carrying forward, because not every cell belongs in the new system.
How do we avoid duplicate records during a CRM migration?
Use a stable migration ID from the old system and match on that key during every load. Do not match only on company name, email, or phone, because those change and collide. Load parent records first, then children, and check counts after each pass. If you must merge, do it after the migration in a controlled step, not during the live load.