By Luiz Otávio Gonçalves Published 2026-09-09

How to migrate from another CRM (or spreadsheet) to Kommo without losing data or history

How to migrate from another CRM (or spreadsheet) to Kommo without losing data or history it's a 4-step process: clean and standardize the database first, map fields, deduplicate by phone/email, import in batches and validate by sample. The trick (and the reason many give up) is that the problem is almost never “uploading the CSV”: it's the mess that comes with it — duplicate contacts, phone numbers missing the 9th digit, swapped fields, incompatible pipeline, and history that doesn't come as you expect.

I've migrated a “dirty” database with operations running. And I'll be honest: migration is the moment when most people lose data and give up. And you know what's worse? The pain shows up disguised in searches for “implementation,” “reset Kommo,” “reset funnel”… because the CRM becomes dirty on day 1, the team loses trust and the company goes back to spreadsheets/WhatsApp.

In this guide, I'll give you the real step-by-step to migrate from Spreadsheet, RD Station CRM or HubSpot to Kommo — with the mistakes I've made (like cross-delivery due to badly formatted numbers). Method > improvisation. Data > guesswork.

The thesis (and warning): migrating incorrectly dirties Kommo on day 1

If you just “export from the old system and import into Kommo,” you will inherit:

• Duplicates (same person with 2 emails, 3 phone numbers, and 4 name spellings)
• Phone numbers without standard format (with/without area code, with/without 9th digit, with spaces, parentheses, +55…)
• Swapped fields (company in the name field, CPF in notes, source in a “free field”)
• Messy deals (a lead with 5 deals, or a deal with 10 contacts)
• Broken history (activities and notes that don't migrate, or migrate as loose text)

The ROI of Kommo doesn't come from import. It comes when you can trust the data and run automation without fear. If you want a broader view of how I structure Kommo “from lead to closing,” I detailed it here: How Kommo CRM works in practice: from lead to closing.

Who this guide is for (and who it is NOT for)

It’s for you if:

• You have a database in a spreadsheet, RD Station CRM, HubSpot (or another CRM) and want to migrate to Kommo safely.
• You have an active operation (WhatsApp, inbound, outbound) and can't “stop sales” for 2 weeks.
• You accept doing the boring work: standardize, clean, deduplicate, and validate.

It’s NOT for you if:

• You want to “migrate everything anyway” and fix it later. Later becomes never.
• Your team is not willing to follow standards (e.g., everyone registers phone numbers differently).
• You are switching CRM to avoid process problems (CRM doesn't fix bad management).

Migration checklist for Kommo (project overview)

I conduct migration as a project with checkpoints. Here's the map:

• Phase 0 — Strategy: what goes into Kommo now, what becomes archive, what stays in the old system for history
• Phase 1 — Cleaning: standardize columns, phones, emails, names, UTM/source
• Phase 2 — Modeling: create fields in Kommo, pipeline(s), stages, responsible parties
• Phase 3 — Deduplication: rule by phone/email + exceptions
• Phase 4 — Import and validation: batch + sample + correction + final batch
• Phase 5 — Cutover: freeze old database, keep adjustment window, and train team

If you're still deciding if Kommo makes sense and which plan, I break it down with numbers here: How much does Kommo CRM cost? Prices and plans in 2026 and here: Kommo CRM licenses: Which is the best for your company?.

Real step-by-step: migrate from spreadsheet / RD Station / HubSpot to Kommo

1) Define the scope: what is “live data” and what is “dead archive”

The first mistake is trying to migrate 100% of everything out of fear of “losing history.” This becomes a huge, slow, expensive import with little daily usefulness.

I separate it like this:

• Live data (migrates): active leads and clients, ongoing opportunities, portfolio, tags, source, responsible, qualification status.
• Useful history (partial migration): last relevant interactions (e.g., last contact date, last message, last proposal).
• Dead archive (does not migrate): lost negotiations from 3 years ago without learning, old lists without consent, loose notes no one reads.

Practical goal: migrate enough for the team to sell better in week 1. The rest can remain accessible as backup (export/file) if really needed.

2) Normalize phone numbers (this alone saves your migration)

If you use WhatsApp in Kommo, phone number is your golden “key.” This is where a lot of migration rots.

My standard for Brazil:

• Store in E.164 format when possible: +55DDDNÚMERO (e.g.: +5547999998888)
• Remove mask: no parentheses, spaces, or hyphens
• Ensure area code (DDD) (without area code it becomes an invisible duplicate)
• Handle 9th digit: mobile numbers may have 8 or 9 digits depending on the source database

Mistake I’ve made: migrating a database with some mobile numbers missing the 9th digit and others with it. Result: the same contact became two. Worse: automation and customer service triggered for “different contacts” and I saw cases of cross-delivery because the team trusted the wrong record. If you want ROI, you can’t allow this.

3) Standardize emails and names (deduplication depends on this)

• Email: lowercase, no spaces, validate format (there are many like “gmail.con”).
• Name: remove obvious duplicates (e.g.: “José da Silva” vs “Jose Silva”), without leaving the field empty.
• Company: separate individual vs legal entity (don’t mix “name” with “corporate name”).

4) Freeze the data dictionary (columns) BEFORE creating fields in Kommo

If you create a field in Kommo “on the fly,” you’ll end up with 3 fields meaning the same thing.

I create a simple dictionary (can be a spreadsheet) with:

• Field name (human-readable)
• type (text, number, list, date, checkbox)
• Entity (Lead/Deal, Contact, Company)
• Source (column in CSV / property in HubSpot / field in RD)
• Rule (mandatory? format? allowed values?)

This is applied “digital engineering”: you define a standard and then execute. If you like this methodical and structured thinking, it aligns directly with what I call MMV (Sales Engine): MMV — Sales Machine: what the method is and why structure beats effort.

5) Model pipelines in Kommo with the minimum necessary

Migration is a terrible time to invent 18 stages and 9 pipelines “because now it will work.” You want operational continuity.

• Create 1 main pipeline (or 2 at most) to avoid confusing the team.
• Ensure stages reflect real decisions (pass/fail), not “feelings.”
• Define clearly: what is a lead? what is an opportunity? what is a customer?

6) Deduplication: rule by phone and email (with exceptions)

My general rule:

• Contact: primary deduplication by phone (normalized) and secondary by email.
• Company: deduplication by CNPJ (when it exists) and name.
• Deals: deduplication is more delicate: the same contact can have multiple legitimate deals.

Exceptions you need to map:

• Shared phones (clinic, reception, family): blind deduplication can merge wrong people.
• Generic emails (contato@, financeiro@): do not serve as unique keys.

7) Migration of the “history”: accept reality and choose the format

Now the part nobody likes to hear: history rarely migrates 1:1 between CRMs. Mainly:

• tasks/activities with specific structure from the old system
• email marketing timeline
• automation events

What I do in practice to not lose context:

• I bring into Kommo “last interaction” fields (date) and Summary (short text) when it makes a commercial difference.
• The complete history stays in exported backup (CSV/PDF) with governance and access.
• If having logs and audit is essential, I prefer to keep the old system “read-only” for a period.

8) Batch import in Kommo: first pilot, then scale

The flow that avoids disaster:

• Pilot batch: 50 to 200 varied records (complete: with phone, without phone, with company, etc.).
• Sample validation: check 10% manually (or at least 20 records), including duplicates.
• Adjustment: correct spreadsheet/dictionary/fields.
• Final batch: import the rest.

If you skip the pilot, you’re choosing to discover the error when it’s already too late.

9) Post-migration check: what I review in 30–60 minutes (and everyone ignores)

• Percentage with empty phone number (this kills WhatsApp and deduplication).
• Distribution by owner (import may assign everything to the account owner).
• Leads in wrong stages (e.g.: all in “New”).
• Critical fields (source, product, city) filled correctly.
• Apparent duplicates (search for 5 random phones and 5 random emails).

10) Cutover (go-live) without trauma: freeze window and rollback plan

If you have an active operation, I recommend:

• Freeze window: stop registering in the old CRM/spreadsheet for a few hours (or 1 day), migrate and start using Kommo.
• Rollback plan: if something breaks, you know exactly how to revert (and for how long).
• Short and direct training: 60–90 minutes with the team, focused on “how to use from today.”

If your project is stuck or you want to see a step-by-step implementation (beyond migration), I detailed the complete map here: Kommo CRM implementation: real step-by-step (and the 5 errors that make the project stall).

Table: classic migration errors to Kommo (and practical fixes)

The real data that matters: license cost vs rework cost

I won’t make up a price here because license changes (and depends on the plan and number of users). What is “real data” and constant: migrating wrong costs more than the license in most operations, because you pay in:

• team hours fixing contact
• loss of useful history (follow-up disappears)
• conversion drop because the team doesn’t trust the CRM
• wrong customer service (the worst case)

If you want to see updated values transparently (and what usually “nobody adds up”), I break it down on specific pages: How much does Kommo really cost per month? Value per user + what no one adds to the bill.

When I recommend migrating with help (and when it can be done internally)

Can be done internally if you have:

• database up to ~5 thousand contacts, with relatively clean data
• 1 person “data owner” with autonomy to define standard
• simple operations (1 pipeline, little integration)

I recommend doing with help if you have:

• large and old database (10k, 50k, 200k) with multiple sources
• WhatsApp as critical channel (any error becomes a fire)
• multiple funnels, multiple units, multiple products
• need to maintain traceability (source/UTM, SLA, stages)

Conclusion: good migration is invisible; bad migration becomes an eternal project

If you remember one phrase: the problem is never “importing the CSV” — it’s the mess that comes with it. Migration is when most people lose data and give up. And I’m not here to sell miracles: I’m here to build process, optimize data and unlock ROI.

If you want to migrate to Kommo without dirtying the CRM on day 1 (and with operation running), I can help you implement it the right way, with standards, validation and governance. request a project.