CRM migration: 9 steps to switch systems without the mess

CRM migration is the transfer of company, contact, deal and history records from an old system, or from spreadsheets, into the new CRM, and its outcome is decided before the first load: in the choice of what to migrate, in the cleanup at the source and in the table that says where each field and each funnel stage goes. Whoever moves the whole database as it is carries into the new tool the duplicates, the free-text fields and the open deals nobody has updated in a year. In Bloor Research’s survey of data migration, the most cited reason for running over time or budget was poor data quality, or lack of visibility into it, and among companies that profiled their data before estimating the project, 68% delivered on schedule, against 55% of those that did not (Bloor Research, 2011).

The figures are preliminary results that analyst Philip Howard published without stating the sample, and he later noted that a few values changed slightly in the final version (Bloor Research, 2011). The direction of the finding matches what I see in the migration projects I lead: the schedule slips in the week someone opens the database and finds what nobody had counted. The decisions that prevent that slip are business decisions, and they belong to the board and the department heads.

What are the steps of a CRM migration and how long does it take?

There are nine steps, and the first three weeks concentrate the leadership decisions. The table shows the reference I use for a mid-sized operation with few integrations; an ERP or more than one source system lengthens the mapping and the tests.

Week	Step	Deliverable
1	1. Scope: what to migrate and what to leave	Scope matrix approved by the board
1 and 2	2. Inventory and profiling of the source	Report on the state of the data by object
2 to 4	3. Cleanup at the source	Prepared data, with duplicates resolved
3 and 4	4. Field and stage mapping	Table approved by each team
4	5. Target configuration and load order	New CRM configured and load plan
5	6. Test migration with a sample	Mapping errors fixed
6	7. Dress rehearsal and validation	Reconciled counts and sign-off from each team
8	8. Freeze and cutover	New CRM in production, with integrations switched on
9 to 16	9. Coexistence and shutdown	Old system read-only and contract ended

Weeks 6 and 7 also hold role-based training on the migrated data. A short scope protects the deadline: in a McKinsey study with the University of Oxford of more than 5,400 IT projects, the large ones, with initial budgets above US$ 15 million, ran 45% over budget on average and delivered 56% less value than predicted, and every additional year of project time increased cost overruns by 15% (McKinsey, 2012). The study covers IT in general, and the mechanism applies to migration: each extra month gives the operation time to change underneath the project.

What should you migrate to the new CRM and what should you leave behind?

Before the scope, the board confirms that the tool is the problem, because the habit of recording outside the system migrates too, as I show in CRM project failure; choosing the platform is covered in the best B2B CRMs in 2026. With the switch decided, the question I ask for each type of data is whether someone will use that record to work or to decide in the next twelve months. What fails the test gets out of the way without disappearing: the company exports the complete old database to a reference archive, a read-only repository with controlled access, and whoever needs an attachment from 2019 finds it there.

Type of data	Migrate	Leave in the reference archive	Who decides
Companies and contacts	Customers, accounts in negotiation and active contacts	Contacts with no interaction or purpose for years	Sales and CS, with the data protection officer
Open deals	All of them, with date, amount and stage reviewed by the owner	Stalled deals with no next step, closed as lost beforehand	Sales manager
Won and lost deals	A recent window, with standardized loss reasons	Those older than the window	Sales leadership and marketing
Activities and attachments	Those of active accounts and open deals, plus current contracts	The rest	Department heads and legal
Custom fields	Those in the approved field map	Unused ones, which the project retires	Migration owner
Workflows and reports	None: the team rebuilds them from the question each one answered	Documentation of what existed	Migration owner

The window for won and lost deals usually sparks the longest discussion. Marketing wants the whole list for reactivation, and finance needs the period it uses to calculate renewal and customer lifetime value. I propose 18 to 24 months, with loss reasons standardized during cleanup, because that window serves both teams without loading a decade of records nobody will open.

How do you inventory and clean the data before migrating?

The inventory lists each source object with its volume and fields, and data profiling measures the state of each field: how many records are empty, how many distinct values appear and how many repeat on the identifying key, such as tax ID or email. This is the survey Bloor linked to on-schedule delivery. The result shows where cleanup will be expensive, such as an industry field written dozens of ways or the book of a rep who left two years ago.

Cleanup happens at the source or in a staging area, before the load. In the staging spreadsheet, an error is a line to fix; in the new CRM, it is a record the team is already using. The quality dimensions and the duplicate merge rule are in CRM data quality, and the migration is the moment to apply them once to the whole database.

When the source is a spreadsheet

A spreadsheet usually mixes company, contact and deal on the same row, and someone needs to split that information into three lists and create the key that links each contact and each deal to its company. Each rep also keeps a spreadsheet of their own, with different columns, and consolidating them reveals duplicates across books that leadership resolves before the load, because the answer decides account ownership and commission.

How do you build the field and stage map?

The field map is the table that says, for each field in the old system, which field in the new CRM it goes to and which rule transforms the value on the way. It depends on a designed target: objects, associations and fields come from the CRM data model, and the definition of each field, with format and owner, lives in the data dictionary. Each row needs approval from whoever uses the field.

Source	Target	Transformation rule	Who approves
Industry as free text	Industry as a closed list	Group the variations; with no match, the record goes to “To classify”	Marketing
Deal owner	Record owner	Records of departed users go to the book’s manager	Sales manager
Phases “Proposal sent” and “Awaiting reply”	Stage “Proposal”	Two phases become one, with a written entry criterion	Sales leadership
“Notes” field	Note in the record history	Load as a note, with the original date	Migration owner
Empty close date	Required date	The rep fills it in during cleanup; without a date, the deal stays out	Sales manager

The stage map affects the forecast, the revenue projection the board follows. When two old phases merge, historical conversion changes its base, and the board needs to know that before comparing the first quarter in the new CRM with the previous one. When a phase splits in two, the owning rep decides which one each deal enters, with the manager reviewing. Keep the original phase in a reference field, and historical analysis survives the shutdown of the old system.

In what order do you load data into the new CRM?

The load order follows the associations, the links between records, such as the contact that belongs to a company. A record can only associate with another that already exists in the target, and the sequence is: users, companies, contacts, deals, deal products, activities and notes, and finally attachments and tickets. What holds the links together is the legacy ID, the identifier each record had in the old system, stored in a field in the new CRM. With it, the team associates each contact with the right company and traces any discrepancy back to the source.

Integrations come in after the last load, with the target validated. If the team switches on the website form or the ERP in the middle of the load, the integration creates records the field map did not anticipate, including duplicates in the freshly cleaned system.

Why run a test migration with a sample?

The test migration loads a sample into a sandbox, a copy of the new CRM separate from production, to find the mapping errors while they cost little. The team picks the sample deliberately: the largest accounts, the books of departed reps and the cases cleanup flagged as difficult. Once those errors are fixed, I run a timed dress rehearsal with the full database, which shows whether the load fits in a weekend.

How do you validate the migration by count and by sampling?

The count, or reconciliation, compares the number of records and the value totals between source and target. Sampling checks record by record whether fields, associations, owner and history arrived correctly. The first catches the load that failed halfway, and only the second catches the deal that arrived intact at the wrong company.

In a hypothetical example, the old system has 12,400 companies, cleanup merged 300 duplicates and the scope left 1,100 in the reference archive. The target must show 11,000 companies, and each difference shows up, with its legacy ID, on an explained rejection list. The total of open deals by stage follows the same arithmetic.

In sampling, each department head checks records from their own area, because they recognize the error a technician does not see. The acceptance criterion is written beforehand, and the check below becomes the record the board signs.

Check	How to verify	Acceptance criterion	Who signs
Count by object	Source minus discards and merges, compared with the target	Zero difference, or explained	Migration owner
Pipeline value	Total of open deals by stage in both systems	Equal, with merges documented	Sales leadership
Owners	Records by owner compared with the approved book	No record with a departed user	Team managers
Content and history	Sample per area, field by field, and timeline of the largest accounts	Error within the written limit per field	Department heads

How do you handle the freeze and the cutover?

The freeze is the period in which nobody changes data in the old system, so the final extraction represents the whole database, and the cutover runs from that extraction to releasing the new CRM. I set the freeze for Friday afternoon, load over the weekend and release on Monday morning, with the count checked. If the operation cannot stop, the team loads the database days earlier and, at cutover, only the delta, the records changed after that extraction.

The board approves the cutover the week before, together with a rollback plan: if validation fails, the team goes back to the old system on Monday and the company reschedules. That plan requires the old contract to still be in force on the date.

Should the two systems coexist after the cutover?

They coexist for a short period with different roles: the new CRM receives every record from the cutover onward, and the old one stays read-only, with no editing for anyone. With both open, the team creates two versions of the same customer within days and nobody knows which one counts. I work with 30 to 60 days of coexistence. After that, the migration owner confirms the reference archive is complete, IT shuts off access and finance cancels the contract.

What happens the day after the cutover?

Training happens before the cutover Monday, by role, in the sandbox, with each rep practicing on their own migrated book. In the first weeks, a hypercare desk, the team that answers questions about the newly launched system, responds within hours, because the rep who cannot find a customer’s history on Monday goes back to the spreadsheet on Tuesday. The first pipeline meeting happens with the new CRM on screen, and the four-week plan to lock in usage is in CRM adoption.

Who owns, who executes and who approves in the migration?

In the Bloor survey, business engagement was the most cited critical success factor, and a CRM migration shows why: IT knows how to extract and load, and only the business team knows whether the data arrived correctly.

Role	Owns	Executes	Approves
Executive sponsor	Scope, cutover date and budget	Decisions on deadlocks between teams	Scope matrix, cutover and final sign-off
Migration owner, in RevOps or operations	Plan, consolidated field map and open items	Coordination, inventory and reconciliation	Each test load
Data owners in sales, marketing and CS	Their team’s fields and stages	Cleanup and sample check	Their team’s rows in the field map
IT and data, with the implementation partner	Extraction, sandbox and integrations	Loads and transformation rules	Access security and rollback plan
Legal and data protection officer	Retention and deletion of personal data	Opinion on the reference archive	Discarding contacts

The board puts in writing what the migration owner approves alone. When sales and marketing disagree about what a lead is in the field map, the sponsor decides within days, and the deadlock stays off the schedule.

Common CRM migration mistakes

Migrating everything just in case

Moving the entire history looks prudent and produces the longest project and the dirtiest database. The reference archive solves the fear of losing data.

Leaving cleanup for after the cutover

The phrase “we’ll fix it in the new system” pushes cleanup to a moment when it competes with operations. The week after cutover already has targets, meetings and tickets, and nobody sets aside time to review thousands of records.

Loading without a legacy ID

Without the old identifier, the link between contact and company depends on the company name, which appears with and without “Inc.” and under trade names. An error discovered late forces the team to redo the whole load.

Ignoring record ownership

Books of departed reps and users with different emails in the two systems send records to people who do not know the customer. In the migrations I follow, the question that most delays the field map is who keeps the company two reps both entered, and the manager needs to answer it before the load, because it affects commission.

Keeping both systems open for editing

The two databases diverge every day, the rep picks the more convenient one and, within a few weeks, leadership is reconciling numbers in a spreadsheet again. Read-only mode in the old system, from the first hour on Monday, prevents the divergence.

Training only after the cutover

The screen tour on cutover day teaches navigation to people who have no routine in the system yet. The team needs to reach Monday knowing what to record in its own role.

Team training for the migration

Department heads learn first to read the reconciliation, check their area’s sample and run meetings in the new CRM. Data owners learn the rules of the field map and the dictionary. Reps, SDRs and CS learn their role’s routine on the migrated book, with attention to what changed in the stages, and the CRM administrator learns to import with legacy IDs and duplicate checks. HR and L&D measure usage per person before and after the cutover.

30-day roadmap for leadership

1. Days 1 to 3: name the sponsor and the migration owner. Write down what the owner approves alone.
2. Days 4 to 10: ask for the inventory and the profiling. Accept a schedule estimate only after them.
3. Week 2: approve the scope matrix. Define the history window and the reference archive with the data protection officer.
4. Week 3: approve the field map and the stage map. Each department head signs their area’s rows, and sales leadership signs the stage merges.
5. Week 3: set the cutover date and check the old contract. The cancellation notice goes out only after coexistence.
6. Week 4: write the acceptance and cutover criteria. Record the tolerated error per field and who signs each check.
7. Week 4: schedule role-based training and the first meeting in the new CRM. The sessions end before the cutover.

If your company is about to switch CRMs or move off spreadsheets, that is the work of the in-company CRM adoption training. I run the program with the leadership and with each role, in the new CRM and with the data you migrated. The group leaves with the CRM best practices guide, with the field and stage rules the field map defined, and with the account and database management manual, with the routine that keeps the new system clean after the migration.

Frequently asked questions

What is CRM migration?

It is the transfer of company, contact, deal, activity and attachment records from an old system or from spreadsheets into a new CRM. The project includes deciding what to migrate, cleaning the source, mapping fields and stages, loading in association order, validating and running the cutover.

How long does a CRM migration take?

In the reference I use for a mid-sized operation with few integrations, the cutover happens around week eight, and coexistence with the old system in read-only mode lasts another 30 to 60 days. An ERP, several business units or more than one source system lengthen the mapping and the tests.

Should I migrate the entire history from the old CRM?

Migrate what someone will use to work or decide in the next twelve months, such as active accounts, open deals and a recent window of won and lost deals. The rest goes to a read-only reference archive, exported before the shutdown.

How do I migrate from spreadsheets to a CRM?

Split the spreadsheet into lists of companies, contacts and deals, and create the key that links each contact and each deal to its company. Consolidate the reps’ spreadsheets, resolve duplicates across books with leadership and follow the same mapping, testing and validation as a system-to-system migration.

How do I validate whether the migration worked?

Compare the record count and the pipeline total between source and target, discounting what the scope left behind and what cleanup merged. Then each department head checks a sample of records from their own area, field by field, against an acceptance criterion written beforehand.

How do I prepare the team for the CRM switch?

Train each role before the cutover, in the sandbox and with the migrated data, so each rep practices on their own book. Prepare the department heads first, since they check the sample and run the first meeting in the new system, and keep a support desk open in the first weeks.