To migrate HR and CRM data safely, export everything from your current tools, clean duplicates and outdated records, map each field to the new system, test a small batch, then run the full import and keep the old tools read-only for 30 days. Migrating HR and sales together means you rebuild links between people, accounts and deals only once.
What is the quick 7-step migration plan?
Most failed migrations don't fail at the import. They fail because nobody decided what to bring over, what to leave behind and how to check the result.
- Inventory your sources. List every tool and spreadsheet that holds people, customer or deal data, who owns it and roughly how many records it has.
- Export a full backup. Take a complete export of every source before you touch anything, and store it somewhere access-controlled.
- Clean and de-duplicate. Remove duplicates, fix formats and decide what to archive instead of importing.
- Map every field. Write down where each source field goes in the new system, what type it is and how it needs to be transformed.
- Run a test import. Import 50 to 100 records, including the messy edge cases, and validate them against the source.
- Do the full import at a cut-off date. Freeze changes in the old tools, import everything, then import any changes made after your last export.
- Run side by side, then switch off. Keep the old tools read-only for 30 days, then cancel them and keep the archive export.
A realistic timeline for a company with a few hundred employees and one CRM looks like this:
| Phase | Typical duration | Who is involved |
|---|---|---|
| Inventory and backup | 1 to 2 days | Migration owner, tool admins |
| Cleaning and field mapping | 3 to 5 days | Sales ops, HR, finance |
| Test import and fixes | 2 to 3 days | Migration owner, one tester per team |
| Full import and go-live | 1 to 2 days | Migration owner, team leads |
| Read-only parallel period | 30 days | Everyone, with one place to report issues |
Treat these as planning ranges. Data quality affects the timeline far more than volume does.
What should you export from HubSpot, Salesforce, BambooHR and spreadsheets?
Export more than you think you need: an unused column costs nothing, while missing deal notes or pay history found three months later costs a lot. Always include each record's unique ID from the source system, because you will need it to rebuild relationships between records.
| Source | What to export | Watch out for |
|---|---|---|
| HubSpot | Contacts, companies, deals, pipelines and stages, owners, custom properties, notes and logged activities | Associations between contacts, companies and deals; activity and email history may need a separate export or a dedicated importer |
| Salesforce | Accounts, contacts, leads, opportunities, users, tasks and events, custom objects, picklist values | Record IDs are what link opportunities to accounts; the built-in Data Export service or Data Loader gives you CSV files per object |
| BambooHR | Employee profiles, job information history, compensation history, time-off balances and history, documents | History tables are effective-dated, so export the full history, not only current values; documents are files and need separate handling |
| Rippling or other HR tools | Employee records, departments, managers, leave balances | Manager relationships and custom fields often export in a different shape than they appear on screen |
| Notion and spreadsheets | Leave trackers, deal lists, project lists, vendor lists, payroll workings | Merged cells, several versions of the same sheet, mixed date formats, notes typed into number columns |
Export from each tool's admin account so you are not limited by one user's visibility, and treat every export file as sensitive. HR exports usually contain salaries, bank details, PAN numbers and home addresses, so keep them in a restricted folder, not in a shared chat.
How do you clean and de-duplicate data before importing?
Cleaning is where most of a migration's value comes from. Once sales and HR data share one data layer, duplicates and inconsistent formats show up everywhere. Work through this list for each source:
- Contacts: de-duplicate by email address. Where two records share an email, keep the one with the most recent activity and merge the notes.
- Companies and accounts: de-duplicate by website domain, not by name. "Acme Pvt Ltd", "Acme Private Limited" and "ACME" are usually one company.
- Employees: match on employee ID or work email. Check that every active employee has a manager, department, date of joining and work location.
- Formats: standardise phone numbers with country codes (+91), dates in one format, state names spelled one way and currency stated explicitly.
- Picklists: collapse near-identical values, such as five spellings of "Referral" in a lead source field.
- Stale records: decide what to archive. Leads with no activity in two or more years are good candidates for the archive file rather than the new CRM.
Be careful with one category: exited employees. Do not delete them to "start clean". You will need their records for full and final settlements, experience letters, audits and statutory record-keeping. Retention requirements vary by law and by document type, so check the current rules with your CA or legal adviser before archiving anything.
What does a field mapping template look like?
A field mapping sheet has one row per source field. It forces decisions before import day and becomes your documentation afterwards. Here is a template with example rows:
| Source | Source field | Target field | Type | Transformation | Required |
|---|---|---|---|---|---|
| HubSpot | Lifecycle stage | Contact status | Picklist | Map values: "Subscriber" and "Lead" to "Lead"; "Customer" to "Customer" | Yes |
| HubSpot | Deal amount | Deal value | Currency | Confirm currency is INR; convert or flag others | Yes |
| Salesforce | Opportunity stage | Pipeline stage | Picklist | Map old stages to the new pipeline; note any you are merging | Yes |
| Salesforce | Account ID | Legacy ID (custom) | Text | Keep as-is to rebuild links and trace issues later | Yes |
| BambooHR | Hire date | Date of joining | Date | Convert to the target date format | Yes |
| BambooHR | Reports to | Manager | Lookup | Match on employee ID after all employees are imported | Yes |
| Spreadsheet | CL balance | Casual leave balance | Number | Take the value as of the cut-off date | Yes |
Two habits make mapping go smoothly. Keep a "legacy ID" field on every imported record so you can always trace it back to the source. And import in dependency order, because a record can only link to something that already exists:
- Users and employees (including managers)
- Companies and accounts
- Contacts
- Deals and opportunities
- Activities, notes, leave history and documents
This is also where migrating HR and CRM together pays off. Deal owners are employees, account managers are employees, and project staff are employees. If the people records already exist in the same system, every deal and project links to a real person record from day one, instead of to a text field that drifts out of date.
How do you run a test import, validate it and go live?
Pick 50 to 100 records for the test, and choose them on purpose. Include a contact with two companies, a deal with a missing owner, an employee who changed department, someone on notice period and a record with non-English characters in the name. If these import correctly, the clean records will too.
Then validate against the source with a checklist:
- Counts match: number of contacts, companies, deals and active employees in the target equals the source, minus anything you deliberately archived.
- Totals match: sum of open pipeline value, sum of leave balances by leave type and headcount by department.
- Relationships hold: contacts link to the right companies, deals to the right owners and employees to the right managers.
- Spot checks pass: open 20 random records side by side with the source and compare every field.
- Permissions are right: salary and personal fields are visible only to the roles that should see them.
For go-live, set a cut-off date and tell everyone. Take the final export at the cut-off, run the full import, then do a "delta" import of anything that changed in the old tools after the export. For HR, time the switch to the start of a payroll month rather than the middle, and run the first payroll in the new system alongside the old process. Compare net pay employee by employee before you release salaries.
If you are moving to Kiko, the built-in importers handle HubSpot, Salesforce, BambooHR, Rippling, Notion and CSV or Excel files. The steps are in the guide to importing your data into Kiko, and the same test-then-validate approach above applies.
How long should you run old and new systems side by side?
Keep the old tools for 30 days after go-live, but switch them to read-only so people can check old notes and confirm nothing went missing. What you must avoid is dual entry: if a rep logs a call in the old CRM, it never reaches the new one, and trust in the migration drops quickly.
During the parallel period:
- Remove edit rights in the old tools, or ask the vendor how to make the account read-only.
- Give people one channel to report "something is missing" and fix issues daily.
- Re-run your validation counts at the end of week one and week four.
- Before cancelling, take one final full export of every tool and store it as your archive.
Moving several tools at once is very doable when the plan is clear. Lumina Tech, a 240-person SaaS company, replaced BambooHR, HubSpot, Monday.com, Notion and Zapier with Kiko in a 14-day rollout; the Lumina Tech case study covers how they approached it.
Frequently asked questions
How long does a CRM migration take?
It depends mostly on how clean your data is and how many tools you are combining. A small team moving one tidy CRM can finish in days, while several tools with years of custom fields can take a few weeks. Plan for cleaning and validation to take longer than the import itself.
Will I lose email history when switching CRM?
Not if you plan for it. Emails logged as activities in your CRM can usually be exported or moved by an importer, but check what your current tool's export includes before you cancel it. Emails in your own inbox stay in Gmail or Outlook; you reconnect Google Workspace or Microsoft 365 to the new system for future email.
Can I migrate in phases?
Yes. A common approach is to move the CRM first and HR at the start of the next payroll month. The trade-off is that you have to temporarily link deal owners and account managers to people records that are still in the old HR tool, so keep the phases close together.
Who should own the migration?
One named person should own the overall plan, usually someone in operations or revenue operations. Each data area needs its own owner: sales ops for CRM data, HR for people data and finance for payroll. The overall owner signs off validation; the area owners confirm their data is correct.
Plan your migration with someone who has done it before
A good migration is mostly preparation: a full backup, clean data, a field map and a tested import. If you want a second pair of eyes on your plan, book a demo and get help planning your migration with the Kiko team.
