AI-generated editorial illustration; not a product screenshot or a pictured company endorsement.
Treat migration as a data-quality project. Keep an untouched original, agree on field meanings, and verify a test import before moving the complete dataset.
Keep a source you can return to
Begin by collecting the files that actually drive the business. The newest filename is not always the authoritative version, particularly when several teams maintain overlapping spreadsheets. Ask the person responsible for each file to identify its purpose, owner, and last meaningful update. Record which system wins when two sources disagree.
Save an unchanged copy in an access-controlled location before cleaning anything. Work on a separate copy and maintain a short change log. If a transformation unexpectedly removes a field or merges two customers, you need a way to reconstruct what happened without relying on memory.
Agree on the scope. Contacts, companies, opportunities, activities, and attachments are different data objects, and they may require different import steps. A first rollout can focus on active customers and open opportunities while older records remain in a documented archive. Decide what employees need on launch day rather than moving everything automatically.
Write a field map
Create a table linking every source column to a destination field. Include the meaning of the field, its expected format, whether it is required, and what happens when the value is missing. This exposes disagreements early. One spreadsheet's 'owner' might mean account manager, while another uses it for the person who last edited the row.
Check dates, country codes, phone-number formatting, currencies, and pick-list values. A value that looks correct in a spreadsheet may import incorrectly if the destination interprets it differently. Ask the vendor for its current import specification and build the mapping against that document.
Do not fill unknown values with guesses just to satisfy validation. Decide whether the record should be corrected, held aside, or imported with an appropriate missing-value state. Preserve the reason for rejected rows so the cleanup work can be assigned to someone.
Resolve duplicates with context
An email address can help identify possible duplicates, but not every apparent match is the same customer. A shared mailbox may represent several people. A contact may change companies, and two offices may share a business name. Choose matching rules with the team that understands the accounts.
Start with a report of suspected duplicates rather than deleting rows in place. Review the relationship between contact, company, deal, and activity records. When you consolidate records, decide which values survive and where historical notes belong. Keeping a traceable mapping from old identifiers to new identifiers will help with later reconciliation.
Use a stable source identifier for each object wherever the destination supports it. Row numbers change when spreadsheets are sorted, so they are a fragile reference. Your goal is to be able to explain which destination record came from which source record after the migration finishes.
Illustrative image generated for TeamStack Journal.
Import a deliberately awkward sample
A useful test set includes normal records and difficult cases: missing phone numbers, accented names, multiple deals at one company, a closed opportunity, a contact with several activities, and an account whose owner is leaving the team. Use fictional or appropriately protected records while validating the process.
Check more than the number of rows imported. Open individual contacts, follow their company relationships, read notes, inspect dates, and confirm ownership. Run the reports the team expects to use on launch day. A successful import message does not prove the data is usable.
Keep a list of acceptance checks and a record of the results. If you adjust the field map, re-run the test with the updated rules. Confirm whether imports create duplicates when repeated and whether the tool supports updating existing objects by identifier.
Control the cutover
Choose a short period when source records stop changing or define how changes made during migration will be captured. Otherwise, employees can unknowingly update a file after it has already been imported. Publish the point at which the new CRM becomes the source of truth.
Assign a person to reconcile counts, a person to review business relationships, and a person to answer users' questions. After the initial import, compare a sample of important accounts with the original source and confirm that users can perform their normal work. Keep the old data protected and read-only while issues are resolved.
A migration is complete when the team can use the records correctly and the process for correcting errors is clear. Document the mapping, exceptions, export locations, and any remaining archive so future changes do not require another round of detective work.
Sources and editorial note
This is an editorial planning guide, not a hands-on product review. Vendor documentation is linked for relevant product background; check current terms before buying.
