The Data Migration Checklist I Use on Every CRM Project

Every failed CRM project I have been called in to rescue failed at the same place: the data. Not the software, not the licenses, not even the training — the migration. After years of moving business data between spreadsheets, legacy CRMs, Zoho, and everything in between, I run the same data migration checklist on every project. This is that checklist, written out in full, including the steps people skip because they seem boring. Why Migrations Fail Before They Start The root cause of most migration disasters is a wrong assumption: that migration means moving data. It does not. Migration means moving trust. If salespeople open the new CRM on day one and find duplicated contacts, dead deals marked active, and phone numbers in the email field, they conclude the system is broken and quietly return to their spreadsheets. You rarely get a second first impression with a sales team. So the checklist begins with a mindset rule: budget as much time for data work as for system configuration. On a typical SME project, that means two to four weeks of data effort for a six-to-eight-week implementation. Clients sometimes push back on that ratio until I show them what their own data actually looks like — which brings us to the audit. A note on tooling expectations: no migration tool fixes bad decisions. Zoho's import wizards, third-party ETL platforms, and custom scripts are all fine executors, and I use all three depending on volume and complexity. But they execute whatever mapping and cleaning you feed them. The checklist below is deliberately tool-agnostic because the failures it prevents are human ones — undocumented fields, unowned records, untested assumptions — that no software catches for you. Step One: Audit the Source Data Before touching anything, I inventory every place data lives. The official CRM or spreadsheet is never the whole story — there are personal spreadsheets, email address books, an accounting system, a marketing tool, sometimes a drawer of business cards someone insists matters. For each source I record the owner, the record count, the last update date, and whether it will migrate, archive, or die. That single spreadsheet prevents the week-three surprise of a critical dataset nobody mentioned. Then I profile the data itself: how many records, how many duplicates by email and by fuzzy name match, which fields are actually populated versus theoretically present, and which pick-list fields have gone feral with free-text entries. A distribution client of mine believed they had eighteen thousand customers; profiling found roughly seven thousand real companies once duplicates and long-dead prospects were separated out. Every planning number changed after that, including their license count. The audit ends with a decision the team must make explicitly: the cutoff line. Records untouched for three or more years usually archive rather than migrate — moving dead data into a new system costs money, slows every search, and poisons reports with ghosts. The line itself matters less than making it a deliberate, written decision rather than a default. Archive the excluded records somewhere queryable, tell the team where that archive lives, and move on without guilt. Step Two: Clean Before You Move CRM data cleaning happens in the source or in a staging spreadsheet — never after import, whatever anyone promises. The cleaning pass covers duplicates first: merge by email, then by normalized company name, and define the survivorship rule in writing, meaning which record wins when two conflict. Most tools can automate the easy eighty percent; the remaining fraction needs a human who knows the accounts, so I book actual hours with a senior salesperson for exactly this. Next comes standardization. Phone numbers into one format, countries and states into consistent values, job titles mapped to a manageable set, dates checked for the classic day-month inversions that plague data crossing between regional formats. None of this is glamorous. All of it determines whether your future reports mean anything, because a report that splits Tokyo and Tokyo-to into separate regions is worse than no report. Finally, validate ownership. Every account and deal needs a living owner in the new system. Departed employees' records get reassigned deliberately, not defaulted to an admin account where they vanish from everyone's follow-up lists. I have seen six figures of pipeline evaporate from view because it was owned by someone who left eight months earlier. Step Three: The Field Mapping Spreadsheet Data mapping is where migrations are truly won. I build one spreadsheet with a row per source field and columns for the target field, the transformation rule, the default for blanks, and an owner for every open question. Nothing migrates unless it has a row. This document sounds bureaucratic and is the single highest-value artifact of the project — it is also the first thing I ask to see when rescuing someone else's migration, and it almost never exists. The hard mapping decisions are structural, not cosmetic. Does the legacy system's single contact record split into account plus contact in the new one? Do seven legacy pipeline stages compress into five? What happens to custom fields only one manager ever used? Each answer changes automation and reporting downstream, so I make these calls in a workshop with the people who own the process, never alone at a keyboard. A mapping decision made silently by a consultant is a support ticket waiting to happen. Two mapping rules I refuse to break. First, never map two source fields into one target field without a written concatenation rule and a sample review — that is how notes fields become garbage. Second, migrate identifiers from the old system into a dedicated legacy-ID field in the new one. That single field makes every future reconciliation, dispute, and delta load possible, and it costs nothing to include. Skipping it is the most common regret I see in migrations done without a checklist. Step Four: The Test Migration Never migrate once. I run at least one full test load into a sandbox or scratch environment with the complete dataset — not a sample, because problems hide in the weird records: the company with three parent accounts, the contact with a two-hundred-character job title, the deal from 2014 with a currency that no longer exists. A sample migration is a rehearsal without the difficult scenes. Verification is quantitative, then human. Quantitative means record counts per module matching the source within explained differences, spot-checked field values, and reports in the new system reproducing known numbers from the old one — if last quarter's revenue report disagrees, something is mismapped. Human means three or four future users spending an hour finding their own accounts and confirming the data feels right. They will find things no query finds, and involving them early converts skeptics into co-owners of the result. Step Five: Cutover and the Two Weeks After Cutover gets a written runbook: the freeze moment when the old system becomes read-only, the delta migration that carries records changed since the test load, the final validation checks, and the rollback criteria agreed in advance. I schedule cutover for a Friday evening on quiet businesses, never before a major sales push, and I keep the legacy system alive in read-only mode for at least a quarter as the reference of record for disputes. The checklist does not end at go-live. For two weeks I watch three signals: duplicate creation rates, which reveal broken search habits or a missed merge rule; fields users overwrite immediately, which reveal mapping mistakes; and who has not logged in at all, which reveals an adoption problem while it is still small enough to fix with a conversation. Migration is finished when the team trusts the data, not when the import job says complete. Those are different days, usually weeks apart. Budget as much time for data work as for system configuration — migration failures are trust failures, and first impressions with dirty data are unrecoverable. Profile and clean data before import, never after: dedupe with written survivorship rules, standardize formats, and reassign orphaned records deliberately. Maintain one field-mapping spreadsheet where every source field has a target, a transformation rule, and an owner — nothing migrates without a row. Run a full-dataset test migration, verify counts and reproduce known reports, and keep the legacy system read-only for a quarter after cutover. This checklist looks like overkill until the first time it saves a project — after that, clients never let me skip a step. If you are planning to migrate business data into Zoho or any CRM and want a second pair of eyes on your source data, your mapping, or just your realistic timeline, that pre-migration review is something I do often, and it is far cheaper than the rescue version. Get in touch before you press import.

The Data Migration Checklist I Use on Every CRM Project

Digital Transformation on an SME Budget: A Real Playbook

Shipping Software for the Indian Army Changed How I Write Code

The GIGW Compliance Rabbit Hole I Was Not Prepared For

Related articles

Digital Transformation on an SME Budget: A Real Playbook

Shipping Software for the Indian Army Changed How I Write Code

The GIGW Compliance Rabbit Hole I Was Not Prepared For