Contents
- Separate the CRM decision from the migration decision
- Inventory what the teams actually use
- Decide how to recognize the same customer
- Write a field dictionary
- Repeat before switching
- Prepare the switch and late changes
- Support the first weeks of use
- Example of mapping: from spreadsheet to new CRM
- Sources and method
A migration to a custom CRM is successful when teams can find the right data, the right relationships, and the next actions when resuming their work. Importing all rows without technical error is not enough: a business opportunity linked to the wrong client can be more harmful than a rejected row visible in a log.
In brief
- Define the data to import and the reference for each field.
- Repeat the migration on a copy and have the processes validated by sales.
- Prepare the switch-over, last-minute changes, and rollback.
Separate the CRM decision from the migration decision
The choice to build, configure, or integrate a CRM must precede the details of the handover. Our CRM cost and architecture guide addresses this decision. Once the scope is chosen, the migration becomes a standalone project, with its own responsible persons, tests, and acceptance criteria.
Do not wait until the end of development to review the data. A real, anonymized, and representative export can reveal inconsistent columns, missing identifiers, or implicit relationships. These discoveries influence the new CRM model and the time needed to organize the data.
Inventory what the teams actually use
List the accounts, contacts, opportunities, activities, documents, consents, and tasks. Add the fields that are not visible in the main table but that trigger a rule: territory, payment status, customer category, or next follow-up date. Ask the teams what they are looking for during a real call.
Assign a destination to each category: active migration, searchable archive, or justified exclusion. Keeping all old fields in the new interface can reproduce confusion. Conversely, deleting a history without reviewing its use can deprive a representative of essential information.
TableInventory what the teams actually use · shareable block
| Risk of reuse | Business control | |
|---|---|---|
| Customer account | Duplicates and similar names | Stable identifier and list of proposed merges |
| Contact | Lost relationship with the company | Verification of account-contact links |
| Opportunity | Stage or amount modified | Comparison by manager, stage, and currency |
| Activity | Author or date misinterpreted | Control of time zones, owners, and order |
| Document | Link became inaccessible | Opening test with the intended user role |
| Preferences | Old or ambiguous value | Preservation of origin and review by the manager |
This grid is a starting point. Retention, privacy, and consent rules must be confirmed with the competent people in your organization; a CRM change does not, by itself, authorize expanding the use of data.
Decide how to recognize the same customer
The trade name is not always a reliable key. It can change, contain an error, or refer to multiple establishments. Define durable identifiers and a correspondence between old and new numbers. Keep this table to explain a migration and avoid repeated creations during a second pass.
Microsoft documents, for Dataverse imports, the need to define uniqueness with keys and to map data to the expected fields. The principle is useful beyond this tool: each new row must be able to be associated with an identity and explicit update rule.
For duplicates, separate automatic decisions from cases to be reviewed. Two accounts sharing a generic email address are not necessarily identical. A reconciliation report must show the conflicting values, the proposed rule, and the person authorized to confirm a merge.
Write a field dictionary
For each field, note its definition, type, source, destination, and transformation rule. An empty date may mean "unknown"; replacing it with the migration date would invent information. An amount may be before tax, after tax, or associated with a currency: the new CRM must not resolve this ambiguity randomly.
Document the allowed values and their correspondence. If the old stages are "sent," "followed up," and "won," explain how they map to the new pipeline. Check records that do not match any stage. An import that classifies everything as "new" may seem technically clean, but destroys sales tracking.
A custom CRM can reflect your specific rules. This flexibility, however, requires naming the data managers and keeping the rules readable so that the team understands what has been transformed.
Repeat before switching
Run a trial recovery on an isolated copy. Compare quantities by category, relationships, amounts, and incomplete records. Total numbers are necessary but insufficient: a hundred imported opportunities can be attached to a hundred wrong accounts.
Prepare a representative sample: new client, old record, active opportunity, inactive contact, company with multiple locations, and activity with document. Have users perform their usual actions. Can they find the last exchange, the next follow-up, and the right person to contact?
Fictitious illustration: a representative must take over an opportunity with two contacts and an attached proposal. The test covers searching for the client, opening the document, reading the history, and updating the stage. The fact that the four records exist does not prove that this process works.
Prepare the switch and late changes
Define the switch window and what remains allowed in the old tool. If sales continue entering data during the migration, you must capture the changes made since the initial extraction. Name the reference system for each phase to avoid maintaining two conflicting truths.
Plan the stop and rollback conditions before starting. Which failures prevent opening? Who makes the decision? Where are new entries stored if the switch must be canceled? A backup is only useful if restoration and work resumption have been verified.
Permissions must also be tested. A manager can see multiple teams; a representative only their records. OWASP describes the risks of application authorization that make these controls essential, especially when the CRM exposes APIs or exports.
Support the first weeks of use
Provide a short procedure for frequent tasks, a channel for reporting anomalies, and a responsible person capable of distinguishing incorrect data from new business rules. Quickly correcting a misunderstood value list can prevent reverting to parallel spreadsheets.
Track remaining anomalies, processing times, and the quality of new entries. Evaluate adoption based on completed processes, not just logins. A team that opens the CRM and then works elsewhere has not yet adopted the system.
Example of mapping: from spreadsheet to new CRM
Mapping is the document that links the old field to the new one, with a transformation rule and a rejection rule. Here is a fictitious example for an SME migrating its account records, contacts, and opportunities. The field names are illustrative; they do not describe any particular software.
TableExample of mapping: from spreadsheet to new CRM · shareable block
| Target field and transformation | Exception to process | |
|---|---|---|
| No client | account.external_id; retain as text | Identifier missing or used by two accounts |
| Company | account.name; remove unnecessary spaces | Name missing; do not merge based on name alone |
| Contact email | contact.email; spaces removed | Invalid address; retain rejection for correction |
| Sales manager | opportunity.owner_id via mapping table | Former employee: assignment approved by director |
| Stage | opportunity.stage via validated value list | Unknown value; do not automatically convert to won |
| Amount CAD | opportunity.amount; interpret decimal separator | Ambiguous value or unspecified currency |
| Last exchange | activity.occurred_at with known timezone | Ambiguous date; return to source record |
A precise mapping for stage can be “quote sent” to “proposal,” “signed” to “won,” and “abandoned” to “lost.” These rules belong to this fictitious case and must be approved by the sales team. The same email address alone is not enough to decide that two companies are identical. Uncertain groupings go into a review queue with original identifiers.
Receiving list before switch
- Reconcile source accounts: imported, rejected, merged, and excluded lines with reason; no unexplained discrepancies.
- Compare open opportunities by stage and amounts in the same currency; examine each divergence.
- Open a sample of records chosen by sales, including an account with multiple contacts and a manager who left.
- Retrieve activities, their dates, and linked attachments; check permissions with multiple roles.
- Replay an interrupted import; check that a resume does not duplicate already integrated records.
- Validate a timed dress rehearsal, the freeze period, and the entries to reconcile since the last export.
- Appoint the person who accepts each remaining discrepancy and the team that handles anomalies after launch.
As an illustration, 1,000 lines may become 920 accounts, 50 rejections, and 30 lines merged in the retained accounts. The total reconciles, but this alone does not prove that the merges are correct. Check the rule and the records concerned. Any tolerance must be explicit: an unexplained commercial amount deserves a different decision than a space in a phone number.
Returning to the old CRM also requires a plan for new entries. After the switch, reverting to an older backup may lose entries recorded in the meantime. Define before the launch how to export, reconcile, or re-enter these changes. The decision to revert must take into account this operation and its responsible party.
Frequently Asked Questions
Should all history be migrated?+
Not necessarily. Define what must remain active, what can be archived, and what must be kept according to your obligations. An accessible archive may be sufficient for some old records, but the decision must be validated by business and data managers.
Can duplicates be cleaned up after launch?+
Some cases can be handled later, but duplicates that affect relationships, amounts, or automation must be reviewed beforehand. Otherwise, the new CRM may propagate incorrect information to other systems.
How to avoid losing changes during the migration?+
Define a freeze period or a resumption of changes from the initial extraction. Test this procedure. Each phase must have a reference system and a responsible party so that users know where to enter the information.
How to prove that the migration is complete?+
Combine accounts by category, relationship verification, amount checks, and user journeys. Keep discrepancies, exclusions, and decisions. The number of imported lines alone does not prove the quality of the transfer.
Sources and method
Microsoft Learn — Import data from Excel and export data to CSV · OWASP — API Security Top 10, 2023 edition. Sources consulted on October 1, 2026; the grids and decision examples are an editorial analysis by Daillac.
Evaluate your data recovery before the switch
Share the structure of your data, the systems involved, and the priority processes. We will be able to scope the tests, controls, and migration responsibilities.
D
