Pakistan
USA
Canada
UK
Dubai
Australia
Germany
- Audit and clean before you import; a new CRM full of old duplicates is still a mess.
- Field mapping is the heart of the job, so write it down and get sign-off from users.
- Always run at least one trial import on a sandbox and compare record counts.
- Plan a cutover window, a rollback path and a verification list.
What counts as CRM data
People think of contacts when they think of migration, but the valuable material is wider. Companies and their relationships, deals and pipeline stages, activities such as calls and meetings, notes, email threads, attachments, tags, custom fields, products and quotes, and the users who own all of it. Each type has its own structure and its own risks.
Some of it moves easily with a CSV file. Some does not. Email history and attachments, for example, often need a connector or an API job, and ownership and permissions may have to be rebuilt by hand. Decide early which records must come across, which can be archived, and which can be left behind.
If you are moving because you are switching platforms, our overview of CRM data migration describes how the work is handled by our team. Choosing the destination comes first; see custom CRM versus off-the-shelf CRM if you have not decided.
The migration in eight stages
Follow them in order. Each has a clear output.
- Set scope and ownersAgree what moves, who approves, the deadline and a single person accountable for data quality.
- Audit the sourceExport samples. Count records by type, find fields that are empty or misused and note where data lives outside the CRM.
- Clean the dataMerge duplicates, standardise phone formats and country names, fix obvious errors and archive dead leads.
- Design the target modelCreate custom fields, picklists, pipelines and owner assignments in the new system before importing.
- Map fieldsBuild a table linking each source field to a target field, with transformation rules.
- Run a test importLoad a subset into a sandbox. Compare counts, spot-check records and ask users to review.
- Cut overFreeze changes in the old system, run the final import, switch users over and keep the old system read-only.
- Verify and tuneCheck totals, relationships and reports, fix gaps and collect feedback for the first weeks.
Before touching any file: decisions to make
A migration is mostly decisions, and three of them are worth settling in a meeting before anyone opens a spreadsheet. First, the definition of a record worth keeping. A lead who enquired five years ago and never replied may not belong in the new pipeline. Second, who owns each record after the move. If the old owners were departed staff, someone must be assigned or the records will be invisible to everyone. Third, what the new system does differently, such as stage names, required fields or lead sources, so the mapping can reflect the future process and not just copy the past.
Write the answers in a one-page migration brief and have the sales head, the operations lead and whoever manages the CRM sign it. When arguments appear halfway through the import, this page is the reference.
It also helps to agree acceptance criteria up front: record counts that must match, a list of reports that must give the same totals, and a number of spot checks per team. Without them, nobody can say when the migration is done, and the project drifts for weeks after cutover while small complaints accumulate and the old system lingers in use beside the new one.
A field mapping template
Copy this structure into a spreadsheet and fill one row per field.
Source field | Target field | Transformation | Owner check |
|---|---|---|---|
Full Name | First name, Last name | Split on first space; review double-barrelled names | Sales lead |
Phone | Mobile | Remove spaces, convert to international format | Sales ops |
Stage (old labels) | Pipeline stage | Map each old label to a new stage | Sales manager |
Source | Lead source | Merge spelling variants into one list | Marketing |
Notes (free text) | Notes | Keep as is; attach date and author if available | Account owners |
Owner | Record owner | Match to user IDs in new system | Admin |
Testing and rollback planning
Run the test import on a copy of the target, not the live account, and keep notes of every issue and fix. Repeat until a full run passes without manual correction, because the final run must be reproducible. Ask three or four end users to open records they know well and tell you what looks wrong. They notice missing notes and wrong owners faster than any script.
Define the rollback point before cutover: if verification fails by a set time, users return to the old system and the new load is cleared. Having this agreed beforehand removes pressure and prevents hasty patches on the day.
Data cleaning checks before import
Do these in the source file, where fixes are cheap.
- Remove exact duplicatesSame email or phone in multiple rows. Keep the record with the richest history.
- Resolve near duplicatesSpelling variants of company names and contacts that appear twice with different emails.
- Standardise phone numbersPakistani numbers appear as 03xx, +92 3xx and 0092 3xx. Pick one format. WhatsApp links also need the international form.
- Normalise cities and countriesLahore, lahore and LHR should become one value. Use picklists in the new CRM.
- Check required fieldsFind records with no owner, no stage or no contact method.
- Handle consent and unsubscribed contactsCarry opt-out flags across so you do not message people who asked to stop. Check the rules that apply to your markets.
- Archive stale recordsOld leads with no activity in years may be better in an archive file than in the live system.
Moving between specific platforms
The mechanics differ by destination. HubSpot and Zoho both offer import tools for CSV and spreadsheets, with object-by-object ordering rules, for example companies before contacts so that associations link correctly. Salesforce uses its own data loader and has stricter requirements around record IDs and relationships. Always read the vendor's current import documentation, because limits and field types change.
Our implementation pages for HubSpot CRM implementation and Zoho CRM implementation explain how migration fits into a wider rollout. For larger or more custom structures, Salesforce development describes the extra data modelling that can be needed.
If you are consolidating several spreadsheets, WhatsApp exports and a legacy database, expect to build a staging sheet or small database where everything is merged first. That staging step is where the quality of the migration is usually decided.
Local data habits that complicate a move
In many local businesses, the real CRM is a mix of Excel files, a phone's contact list, and WhatsApp chats. Importing from those sources means deciding what to do with data that lives in individual salespeople's phones. Set a clear policy: before cutover, staff export or enter their active leads, and from the cutover date new leads go only into the CRM. Our piece on WhatsApp and CRM automation shows how conversations can be tied to records afterwards.
Names in Urdu script, mixed Roman Urdu spellings and shared family phone numbers all create duplicate-matching problems. A person called Muhammad Ali may be written four ways. Match on phone or email first and review name matches manually.
Finally, check where the new system stores data. If you hold customer information for clients abroad, their contracts may set expectations on hosting and access. Verify before choosing a region.
Typical problems and how to handle them
These appear in almost every move.
Problem | Cause | Fix |
|---|---|---|
Duplicate contacts after import | No match key used | Match on email or phone; merge before and after |
Deals lose their company link | Companies imported after contacts | Load in dependency order |
Stage history missing | Target does not accept past stages | Store history as a note or custom field |
Garbled Urdu text | Wrong file encoding | Save CSV as UTF-8 and test a sample |
Dates shift or fail | Different date formats | Convert to one ISO format first |
Owners show as unassigned | User names do not match | Create users first and map by email |
Cutover day checklist
Print this and tick it off with the team on the call.
- Backup both systemsTake a full export of the source and a snapshot of the target before the final load.
- Announce the freezeTell users when the old system becomes read-only.
- Run the final importUse the same mapping and scripts as the test, in the same order.
- Compare totalsRecords by type, deals by stage and total pipeline value should match the source.
- Spot-check twenty recordsPick a mix of old, new, large and odd records and inspect every field.
- Confirm integrationsForms, website, email and phone tools should now write to the new CRM.
- Switch users and open supportHave someone available all day to answer questions.
Junaid's take
In my experience, the technical import is the easy ten percent of the work that gets all the attention, and the cleaning and the decisions are the rest. Teams that rush to load data into a shiny new system carry their old problems with them and then blame the new tool.
My advice is to treat the migration as a chance to cut the dead weight. Archive what nobody has touched for years, standardise the fields that drive reporting, and make someone responsible for data quality afterwards, otherwise the mess returns within a year.
If your data is spread across spreadsheets and chats and you want it handled properly, talk to our team. For systems modelled around property sales, the fields to preserve are different, as covered in real estate CRM features every agency needs.
Junaid has worked on CRM for more than 18 years, across SEO, paid media, web development and custom software. He founded SEOnumber1, builds WordPress plugins, CRMs and web applications, has served 500+ clients in 48 countries, and holds Google Ads, Analytics and Google Blue and Green Belt certifications. He is a National Level Award Winner in Digital Marketing. Read his story or ask a question about this article.