Start with an agreed source of customer data, map it to the new CRM, test a representative sample and reconcile the results. Switch the team only when records, relationships, permissions and follow-up tasks work correctly. Keep a protected original export and a clear recovery plan.
Put this guidance into practice
Explore our custom CRM and ERP development, software development, application launch, premium website development and business automation services. We scope the work around your existing tools, team and goals.
Decide what needs to move
A migration is not simply uploading a spreadsheet. It is a handover of responsibility: someone must still know who owns each customer, what was agreed and what happens next. A successful import can still leave a sales team without its next follow-up dates.
List every source before choosing a launch date. Shared sheets, individual sales trackers and exports from older tools may contain different versions of the same customer. Nominate a business owner to resolve conflicts. Keep the untouched originals separately from the files being cleaned.
- Move active customers, open opportunities and the history needed to serve them.
- Decide how old or inactive records will be archived and who can access them.
- Record the source, responsible person and intended destination for each dataset.
- Avoid copying unrelated personal information just because it is in an old file.
Agree on a matching rule before removing duplicates
Two rows with the same company name are not necessarily duplicates. They may represent separate branches or different people at the same business. Conversely, a spelling variation can hide a duplicate. Decide which fields establish identity and which cases need a human review.
HubSpot's import documentation explains how identifiers such as record IDs, email addresses and company domains help update and associate records. The applicable identifier depends on the object and platform. For a custom CRM, agree an equivalent stable key with your developer; a customer's display name is rarely a safe key on its own.
- Preserve source IDs so you can trace a migrated record back to its original row.
- Review shared email addresses, missing identifiers and conflicting owners separately.
- Keep a merge log showing the surviving record and the decision made.
Make the field mapping explicit
Write down how each source column becomes a CRM field. Include its type, permitted values, transformation rule and treatment of blanks. A field called Status may mean lead stage in one sheet and payment status in another. Those meanings should not be combined.
For example, a sheet might use New, Called and Sent quote. Your team could map these to New enquiry, Contacted and Proposal sent. This is an illustrative mapping, not a universal sales process. Agree the meaning of each stage with the people who will use it.
Treat relationships as part of the migration, not a later tidy-up. A contact should belong to the correct company, an opportunity to the right customer and a follow-up task to an active owner. Verify date formats, time zones, currency and leading zeros in identifiers before import.
Run a trial that includes difficult records
Salesforce's migration guidance recommends cleaning and mapping data, then testing incrementally with sample data. A useful trial should include awkward cases as well as neat rows: missing phone numbers, several contacts at one company, reassigned opportunities and long notes.
Use a separate test environment or an agreed isolated import batch where possible. Ask a sales user to find a customer, read the history and complete the next action. Ask a manager to check ownership and reporting. Count checks alone will not reveal a broken working process.
- Reconcile source rows against created, updated, deliberately excluded and rejected records.
- Check sample relationships and compare relevant totals, such as open opportunity value by currency.
- Review the error log and retry only corrected failures using the agreed matching rule.
- Confirm whether the import triggers emails, task creation or integrations before allowing it to run.
Plan the switch and the recovery route
Choose when the spreadsheet stops being the team's working system. If people continue changing both systems, define which one is authoritative and how late changes will be captured. A short, agreed editing pause may be simpler than a complicated two-way handover.
Assign a named person to approve the final import, another to check the business results and someone to support the team. Decide in advance which failure would delay launch. Missing customer relationships or incorrect access should not be dismissed as cosmetic issues.
Do not assume deleting an import batch will undo everything. Updates to existing records and actions triggered by automation may require separate recovery steps. Have your implementer explain how the original state would be restored and test the relevant procedure before the final switch.
Use a short acceptance checklist
The migration is ready when the team can work confidently, not merely when the progress bar finishes. Record the acceptance checks and who signed them off. Keep rejected records visible in a follow-up list rather than quietly dropping them.
During the first working days, review missing owners, unassigned tasks, duplicate reports and integration errors. Give users one route to report problems. Retire editable copies of the old tracker only after agreeing retention, access and recovery arrangements.
If you are planning a custom CRM, bring a redacted sample sheet and one real workflow to an initial discussion. DigiStartup India can help define the data structure and migration scope alongside the software, rather than treating customer data as an afterthought.
- Customer and opportunity counts reconcile with documented exceptions.
- Owners, permissions and next-action dates are correct.
- Users can find records and perform their everyday workflow.
- Key reports and integrations have been tested.
- A recovery owner and support process are documented.
Further reading
Frequently asked questions
Should every spreadsheet column be imported?+
No. Import fields that support an agreed business purpose and preserve the history your team needs. Review unclear, obsolete or sensitive columns before copying them. Archive excluded material only under an agreed retention and access policy.
Can we keep using spreadsheets during migration?+
Yes, during preparation, but agree a cutover point. Record changes made after the trial export and decide how they enter the final import. Avoid leaving both systems open for uncontrolled editing after launch.
How do we avoid duplicate customers in a CRM?+
Define a stable matching identifier for each record type, review ambiguous matches and test imports before the full transfer. Reuse the matching rule when retrying failures instead of importing the same rows as new records.
How long does a spreadsheet-to-CRM migration take?+
It depends on data quality, relationships, record volume, integrations and the review work needed. Ask for a plan that includes cleaning, a trial, reconciliation and handover rather than a promise based only on the number of rows.