Migrating CRM data to a custom CRM takes nine steps: inventory what you hold, decide what to carry over, map old fields and stages to the new data model, clean and de-duplicate, load into a staging environment, reconcile counts and samples, rehearse the cutover, move the final changes and go live with a rollback plan. The biggest risks are duplicates, lost activity history, broken links between records and automations that do not travel.
A CRM migration is mostly a data-quality project with a software project wrapped around it. The code that loads records is the easy part. The hard part is that the existing system holds years of inconsistent entries, and the new system, being custom, has stricter rules. This guide is for teams moving from spreadsheets, or from a hosted CRM such as HubSpot or Zoho, into a custom CRM. Before you start, it helps to have decided what the new system should hold; the custom CRM requirements checklist covers that. And if you are still deciding whether to leave your current CRM, read custom CRM vs Salesforce, HubSpot and Zoho first.
Why move, and what it costs you if you do it badly
Typical reasons for moving: your process no longer fits the product's objects and stages, the CRM must share live data with your ERP or accounting system, per-user fees have grown, or you want to control the data and the roadmap. A poorly executed migration undoes the benefit: reps stop trusting the new system because their contacts are missing, managers cannot reconcile pipeline totals, and old and new systems run in parallel for months. Treat the migration as a project with an owner, a schedule and an acceptance test.
Step 1: inventory what you hold
List every source and measure it.
| Source | What to record |
|---|
| Spreadsheets | Number of files, owners, sheets, rows, columns, where the latest copy lives |
| HubSpot / Zoho / other CRM | Objects used (contacts, companies, deals, tickets, custom objects), record counts, custom fields, pipelines, users |
| Email and calendar | Whether activities are logged in the CRM or live only in inboxes |
| Other systems | Accounting, e-commerce, support, marketing tools holding customer data |
| Attachments | Quotes, contracts and files, with total size |
Counts matter because they become your reconciliation targets later. Write them down on day one, with the date.
Step 2: decide what comes across
Not everything should migrate. Decide per object:
- Migrate fully: active contacts, companies, open deals, open tickets.
- Migrate summarised: closed deals older than a cut-off date, kept as history with key fields.
- Archive, do not migrate: very old leads, bounced emails, test data, records marked as spam.
- Rebuild, do not migrate: automations, workflows, dashboards and reports. These are configured in the old product, rarely export in a usable form, and are best redesigned in the new system from your current requirements.
A shorter, cleaner load is faster and gives users more reason to trust the new CRM.
Step 3: map the old model to the new one
Create a mapping sheet with one row per old field: old name, type, sample values, new object and field, transformation rule, and owner. Pay particular attention to:
- Picklists. Old values such as "Hot", "hot" and "HOT lead" need to map to one new value, and unmapped values need a rule.
- Stages. Map each old deal stage to a new stage, including what happens to deals in obsolete stages.
- Owners. Match old users to new users. Records owned by people who have left need a rule (a manager, a queue).
- Relationships. Contacts to companies, deals to contacts, tickets to accounts. In hosted CRMs these links are held as associations, and exporting an object to a file may not include them; check what your product's export or API provides and plan to extract associations separately.
- Dates and time zones. Date formats differ between systems and spreadsheets; decide one standard and convert on load.
- Currency and numbers. Decimal separators, currency codes and rounding.
- Consent and source. Marketing consent flags and lead source fields should travel with the contact, with a recorded date, because losing them can create legal exposure. We design to support your data-protection obligations; compliance remains your organisation's responsibility.
Step 4: extract, clean and de-duplicate
Extract. From spreadsheets, consolidate the latest versions into one controlled set and stop people editing the old ones in the meantime. From HubSpot or Zoho, use the product's export tools or API to take a full copy; both products provide CSV export and an API, but export size limits, rate limits and which fields are included differ by product and plan, so verify against the current documentation before you plan the timing.
Clean. Standardise phone formats, trim spaces, fix obvious typos, separate first and last names, normalise country and city names, and remove test records.
De-duplicate. Pick match keys in priority order, for example email, then phone number, then company name plus city. Decide merge rules: which record survives, how conflicting values are resolved, and which activities are kept. Automated matching is good at exact and near-exact matches; leave a manual review list for fuzzy matches, and have a sales lead approve it. Records that cannot be matched should be listed for your team to resolve rather than silently dropped.
Step 5: load into staging, not production
The custom CRM should have a staging environment that is a copy of production in structure. Load the cleaned data there first, with the loader scripts the migration will use for real. Keep the original source IDs on every migrated record in a dedicated field. These IDs let you trace any record back to its origin, re-run a partial load, and handle the delta later.
Step 6: reconcile and sample
Compare counts per object between source and staging: contacts, companies, open deals, deal value by stage, tickets. Differences should be explained by your rules (for example, duplicates merged), not by chance. Then sample: pick fifty records across owners, and let their owners check every field, association and note. Ask the sales lead to sign off the counts and the sample in writing. Do not skip this; it is the migration's acceptance test.
Step 7: handle history and attachments
Activity history is what makes a CRM valuable to a rep. Decide whether to migrate calls, notes, emails and tasks, and for how many years. Notes and tasks usually migrate cleanly. Email logging depends on how the old system captured it; if emails are stored as copies in the CRM, they can be carried over, whereas if they were only linked to a mailbox, the new CRM may need to re-link through the mail provider's API. Attachments migrate as files with their parent record IDs; check total size and storage. Where history cannot be carried over, keep a read-only archive of the old system for a defined period so no one loses access to the past.
Step 8: rehearse the cutover
Run the full migration at least twice in staging, timing it. The second run should be boring. Write a cutover plan with a freeze time, the sequence of loads, who checks what, and the criteria for a go decision.
- Freeze. Announce when users must stop entering data in the old system.
- Final extract and load. Take the last copy and load it, using source IDs to handle records that changed since the rehearsal.
- Verify. Re-run the count checks and the sampling.
- Switch. Point web forms, integrations and email logging at the new CRM, and redirect users.
- Hold the old system read-only. Keep it available, not editable, until the new one is accepted.
Step 9: go live with support and a rollback plan
In the first week, have a named person to answer questions and a channel for reporting missing or wrong data. Fix and re-run corrections from the source IDs. Agree in advance what rollback means: if a critical failure occurs in the first hours, you return to the old system and repeat the cutover, which is only possible if the old system stayed intact. Collect feedback after two weeks and update the mapping for anything missed.
The main risks and how to manage them
| Risk | What it looks like | Mitigation |
|---|
| Duplicates | Two records for one customer; split history | Match keys, merge rules, human review list |
| Lost relationships | Contacts without companies, deals without contacts | Extract associations separately; reconcile counts of links |
| Lost history | Notes and emails missing | Decide scope early; keep a read-only archive |
| Owner mismatch | Records belonging to nobody | Mapping rule and a queue for orphaned records |
| Field mismatch | Picklist values missing or wrong | Mapping sheet with unmapped-value rules |
| Consent loss | Marketing flags dropped | Carry consent and source fields with dates |
| Automations missing | Reminders and routing no longer happen | Rebuild and test before cutover |
| Integrations pointing at the old CRM | Web forms and email still feeding the old system | Switch all feeds in the cutover plan |
| API limits | Extraction slower than planned | Check limits early; extract in batches |
| User distrust | Reps keep spreadsheets | Involve reps in sampling; fix reports quickly |
Who does what
The migration needs a business owner (usually the sales manager) who decides mappings and merge rules, a technical lead who writes and runs the loaders, and two or three reps who check samples. Your vendor should provide the loader scripts, the staging environment and the reconciliation reports; you provide data and decisions. Timeline Digital includes migration in the scope of CRM builds and checks counts with your sales lead before go-live. There is no fixed timeframe: the schedule is set from your requirements in the Plan step. The free pilot of 2 to 3 key modules is ready in about 2 days, and with 1,200+ developers we have the capacity to deliver a complete system in as little as 2 weeks. The full project starts after you approve the pilot, and the scope, milestones and terms are agreed after it. Long-term support under a service level agreement (SLA) follows launch.
Timeline Digital is a custom software development company founded in 2013 and headquartered in Islamabad, Pakistan. This guide was written by Usama Asif to describe general CRM migration practice; export and API details of third-party products change, so confirm them against the vendor's current documentation.