Moving rows is not the same as moving a business
A CRM import can finish without errors while leaving staff with the wrong customer history. A contact may exist twice. An order may belong to the wrong account. A total may change because a spreadsheet formula was not included in the export.
Approve a migration only when the new records mean the same thing as the old records. That requires checks beyond an importer reporting success.
This checklist covers the controlled move from spreadsheets into a CRM. It is not a design for ongoing email processing. For that separate workflow, see order intake automation and exception handling.
1. Identify the source and its owner
List the spreadsheets, tabs, exports, and related files that staff actually use. Include hidden tabs and separate lists used to correct the main workbook. Ask an operator to show how they find a customer’s current status.
Name an owner for each dataset. Decide which source wins when two files disagree. Preserve a dated, read-only copy of the agreed source before cleaning begins. Keep an access-controlled record of corrections rather than overwriting the only evidence.
Choose what to migrate, archive, or exclude. Old records may still need to remain accessible without becoming active CRM work. Check retention obligations with the responsible owner before deleting source material.
2. Write a field map people can review
For each destination field, record its source column, meaning, required status, transformation, and treatment of blanks. Include date formats, time zones, currencies, units, status values, and leading zeros in identifiers.
A blank balance is not necessarily zero. A spreadsheet’s displayed value may differ from its stored value. Specify whether a calculated amount becomes an imported snapshot or is recalculated by the CRM.
Route invalid records to a visible exception list. Do not invent missing information just to satisfy required fields. A business owner must approve corrections that change meaning.
3. Separate identity from similarity
Use stable source identifiers where available. Preserve the original identifier and a mapping to the new CRM identifier. When several sources reuse the same number, include the source name in the identity.
In Somnio’s food delivery CRM case study, external e-commerce order IDs prevented duplicate records during repeated imports. The same study describes spreadsheet migration with parallel-run reconciliation before cutover. It does not establish that names or email addresses alone are safe matching keys.
That project replaced email and spreadsheets with a custom Laravel CRM. For a packaged CRM, check its import, duplicate-detection, export, and rollback limits before adopting the same plan.
Two similar records can represent different people. One person can also appear under several names or addresses. Define what can be matched automatically, what needs review, and who can approve a merge. Preserve a record of merged source identities so a later import does not recreate the duplicates.
4. Use a migration decision worksheet
Complete this worksheet for one record type before expanding the import.
| Decision | Evidence to record | Stop condition |
|---|---|---|
| Source authority | Workbook, tab, snapshot date, owner | Competing sources remain unresolved |
| Record identity | Stable source key and CRM mapping | Two real records share an unresolved key |
| Field meaning | Approved transformation and blank rules | Required meaning is uncertain |
| Relationships | Customer-to-order and order-to-item links | A required link has no destination |
| Reconciliation | Counts, totals, exclusions, reviewer | Unexplained differences remain |
| Cutover | Write cutoff, approver, recovery path | New work cannot be accounted for |
The worksheet is a release decision aid, not proof by itself. Attach the actual comparison results and exception decisions.
5. Rehearse without sending real-world actions
Run the import in an isolated environment using representative data under appropriate access controls. Include canceled records, shared contacts, incomplete addresses, and unusual amounts, not only clean recent rows.
Disable customer messages, payment actions, dispatch instructions, and other external effects during rehearsal. Loading historical orders must not send them back into fulfillment.
Repeat the import against the same snapshot. Confirm the intended behavior: update known records, skip unchanged records, or replace a test dataset. An operator should not need to guess whether running the import again will duplicate work.
Record the import duration and manual review effort. Use those observations to plan cutover capacity, not to promise a standard migration timeline.
6. Reconcile counts, relationships, and totals
Compare counts by record type, status, and relevant period. Explain exclusions and merges so the expected destination count is clear. Comparing only grand totals can hide offsetting errors.
Verify that each order points to the correct customer and retains its required items, notes, and history. Check for orphaned records. Have staff trace selected customers from the original workbook through to the CRM screen they will use.
Compare relevant quantities and financial totals under identical rules. State whether canceled orders, refunds, taxes, and archived records are included. For a hypothetical example, two customers’ balances could be exchanged while the overall balance stays unchanged. Per-customer checks reveal what a grand total misses.
Maintain an exception register with the difference, cause, correction, and approving owner. Do not approve unexplained differences because the sample screens look reasonable.
7. Control cutover and rollback
Set a source write cutoff or a documented method to capture changes after the snapshot. Tell staff where new work belongs during the transition. Avoid two writable systems with no rule for reconciling them.
Name the person who can pause the import and the person who approves the switch. Define stop conditions before starting. Confirm backups are usable and preserve the import logs and identity map: the table linking each old ID to its new CRM ID.
Rollback must account for work created after cutover. Returning to yesterday’s spreadsheet can lose today’s customer changes. Capture those changes, reconcile completed external actions, and assign an owner to restore the operating record before anyone re-runs the import.
Start with one dataset you can prove
Choose one customer segment and its related orders. Build the field map, rehearse twice, then compare counts, links, and totals. Ask the staff member who uses those records to review the exceptions. This self-service exercise will expose unclear decisions before a full migration.
If the source ownership or recovery plan remains uncertain, Somnio’s architecture consulting can help review the migration boundaries. Bring the worksheet and comparison results, not only the destination CRM’s feature list.
