From Pipedrive to Kommo: what migrates, what does not — and how to do a full migration

From Pipedrive to Kommo: what migrates, what does not — and how to do a full migration

Migrating from Pipedrive to Kommo using the built-in CSV export transfers contacts and deals, but not call history, notes, files, or activity records. This is a consequence of how both systems store data: Pipedrive keeps activities as separate objects with their own API, while Kommo only accepts them via REST API — CSV import does not support them. The result is a “clean” database with no context of your previous client interactions.

If communication history matters, a standard CSV migration will not be sufficient. Below we break down exactly what gets lost, and how to run a complete migration that preserves your data.

Why companies migrate from Pipedrive to Kommo

Pipedrive is a strong tool for simple pipelines. It is fast, intuitive, and works well for teams of up to 15 people with one manager per deal. Kommo wins in specific scenarios:

  • Messengers as the primary channel. Kommo natively connects WhatsApp, Telegram, Instagram, and Facebook Messenger. In Pipedrive these are only available through third-party integrations or Zapier.
  • Digital Pipeline. Automations in Kommo are tied to deal movement through stages — bot replies, tasks, and emails fire without additional tooling.
  • CIS market and Russian-speaking users. Kommo (formerly amoCRM) is deeply integrated with local services: telephony platforms, domestic banks, and payment systems.
  • Pricing. For a team of 5–10 people, Kommo is cheaper than Pipedrive for comparable functionality.

The main risk during migration is losing history: calls, conversations, and deal notes.

What gets lost in a CSV migration from Pipedrive

Pipedrive allows you to export data as CSV through Settings -> Data management -> Export data. The following is included in the export:

Exported:
— Contacts (persons) — name, phone numbers, email, organisation, custom fields
— Organisations — name, address, custom fields
— Deals — name, value, pipeline stage, close date, owner
— Some custom fields (depends on type)

Not exported via CSV:
— Activities — calls, meetings, tasks
— Notes — text comments on deals and contacts
— Files — attachments on deals
— Email thread history
— Relationships between objects (one contact -> multiple deals)
— Pipelines and stages (must be recreated manually in Kommo)

Full mapping table:

Pipedrive objectCSVAPI
Persons (contacts)Yes (partial)Yes (full)
Organizations (companies)Yes (partial)Yes (full)
DealsYes (partial)Yes (full)
Activities (calls, tasks, meetings)NoYes
NotesNoYes
FilesNoPartial
Email threadsNoNo
Custom fieldsPartialYes (with mapping)
Object associationsNoYes

Architectural differences: how data is stored in Pipedrive vs Kommo

Pipedrive builds a graph of relationships around the deal: contacts (participants), an organisation, activities, and notes are all attached to the deal. Each of these objects exists independently and is associated via ID.

Pipedrive API: GET /activities?deal_id=123 returns all activities for a deal. GET /notes?deal_id=123 returns all notes. Everything is accessible — CSV simply does not export it.

Kommo is built around the deal (lead) as the primary object. Notes, calls, and tasks are stored as events and tasks attached to a deal or contact.

Kommo API: notes are created via POST /api/v4/leads/{id}/notes or /api/v4/contacts/{id}/notes. Tasks are created via POST /api/v4/tasks linked to an entity. Calls from external systems are stored as notes with type call.

The key implication: to migrate activities you must:

  1. Read activities from the Pipedrive API
  2. Map each one to the corresponding type in Kommo (note/task)
  3. Create them in Kommo via API, linked to the correct object

Step-by-step process for a proper migration

Step 1 — Inventory the Pipedrive database

Before migrating: get real counts from the Pipedrive API.

GET /persons?limit=500             # number of contacts
GET /organizations?limit=500       # companies
GET /deals?status=all_not_deleted  # deals (all statuses)
GET /activities?type=call          # calls
GET /activities?type=task          # tasks
GET /notes                         # notes

For each entity: total count, list of custom fields (GET /dealFields, GET /personFields), date range. This is the basis for estimating volume and migration timeline.

Step 2 — Create the structure in Kommo

Before transferring any data:
— Create pipelines and stages in Kommo that match Pipedrive
— Create custom fields in Kommo via POST /api/v4/leads/custom_fields and POST /api/v4/contacts/custom_fields
— Add users and configure permissions

Stage mapping: in Pipedrive, stages are named freely and belong to a specific pipeline. In Kommo it is the same — a one-to-one relationship. Pipedrive “Won” and “Lost” statuses correspond to the “Successfully closed” and “Closed and not realised” stages in Kommo.

Step 3 — Migrate base objects

Order is critical: contacts and companies first, deals second.

Contacts:

GET /persons (Pipedrive)
-> POST /api/v4/contacts (Kommo)
   { name, first_name, last_name, custom_fields_values: [...] }

Save the mapping: pipedrive_person_id -> kommo_contact_id — this is needed to link deals and activities.

Companies:

GET /organizations (Pipedrive)
-> POST /api/v4/companies (Kommo)

Deals:

GET /deals (Pipedrive)
-> POST /api/v4/leads (Kommo)
   { name, price, status_id (stage), _embedded: { contacts: [...], companies: [...] } }

When creating a deal, include the linked contacts immediately via _embedded.contacts — this migrates the associations.

Step 4 — Migrate activities and notes

Notes from Pipedrive -> notes in Kommo:

GET /notes?deal_id=X (Pipedrive)
-> POST /api/v4/leads/{kommo_deal_id}/notes (Kommo)
   { note_type: "common", params: { text: "[date] [author]\n[note text]" } }

Activities (calls) -> calls/notes in Kommo:

GET /activities?type=call&deal_id=X (Pipedrive)
-> POST /api/v4/leads/{id}/notes
   { note_type: "call_in" or "call_out",
     params: { text: "[date] Call [direction] - [description]" } }

Tasks -> tasks in Kommo:

GET /activities?type=task (Pipedrive)
-> POST /api/v4/tasks
   { task_type_id: 1, text: "...", complete_till: [timestamp],
     entity_id: [kommo_deal_id], entity_type: "leads" }

Important: when migrating historical activities (completed ones), they are created as notes in Kommo rather than active tasks. A completed status in the past is context, not an action.

Step 5 — Validation

  • Compare record counts in Pipedrive and Kommo for each object type
  • Spot-check 20–30 cards: open the same deal in both systems and compare history
  • Verify responsible users: every deal in Kommo must have an assigned user
  • Final report: what was migrated, what was not (files, email threads)

Common issues in a Pipedrive -> Kommo migration

Responsible user mismatch. In Pipedrive, users are identified by email. In Kommo — by internal ID. When migrating deals, you must map pipedrive_user_id -> kommo_user_id. If a user exists in Pipedrive but has not been created in Kommo yet, the deal will be assigned to the administrator.

Kommo API rate limits. Kommo limits requests to 7 per second. When migrating 50,000+ activities, you need a queue with a delay and retry logic for HTTP 429 responses.

Custom fields of type “list.” In Pipedrive, option lists are stored as numeric IDs with a separate reference table. When migrating to Kommo, you must first create an enum field with the same option values, then map the IDs.

Closed deals. In Pipedrive, “Won” and “Lost” are final statuses. When creating a deal in Kommo in a final stage, you must specify the correct status_id (142 = Won, 143 = Lost in a standard setup). An incorrect value will send the deals to the active pipeline.

Files. Pipedrive stores files on its own servers (GET /files/{id}/download). Kommo accepts files via multipart upload to a note or deal. In a typical project, files are either not migrated (remaining in a Pipedrive archive) or migrated selectively — only critical documents.

Real-world case

Migration project for a real estate agency (USA, 12 managers):
— 4,200 contacts, 1,800 deals (active + closed over 3 years)
— 28,000 activities and notes
— 6 custom pipelines, 47 custom fields

Via CSV: contacts and deals migrated in 1 day, all history lost.
Via API: 3 weeks — audit, mapping, scripts, migration, validation. 96% of activities migrated; files were left in Pipedrive with a separate archive.

The team noted: in the first week in Kommo, managers could open a deal card and see the full call history — “like we moved, not like we started over.”

Who should consider switching from Pipedrive to Kommo

The switch makes sense if:
— The primary communication channel is messengers (WhatsApp, Telegram), not email
— Pipeline automation of replies and tasks without Zapier is needed
— The team works with a Russian-speaking audience or relies on local services
— The deal cycle is short (under 2 weeks) and lead volume is high

More on what Kommo can do: see the Kommo CRM overview and the Kommo features description.

The switch is not advisable if you need complex cross-object reporting, marketing and sales in a unified database, or are planning to grow to 50+ people — those scenarios typically point toward HubSpot.

Frequently asked questions

Can you migrate from Pipedrive to Kommo on your own?

Contacts and deals — yes, via Kommo’s CSV import (Settings -> Import). This takes a few hours for a base of up to 5,000 records. Activity history and notes — only via API, which requires development work or engagement of a partner. If history is not critical, CSV is sufficient.

Does Pipedrive export notes in CSV?

No. Notes are not included in the standard Pipedrive CSV export. They are only accessible via API: GET /api/v1/notes or per specific object GET /api/v1/notes?deal_id=X. This is one of the main reasons why a self-service migration loses data.

How long does a Pipedrive to Kommo migration take?

For a base of up to 3,000 contacts without activity history — 1–2 days via CSV. With activity history: 2–3 weeks including audit, script development, and validation. The workload scales linearly with the number of activities and custom fields.

What to do with Pipedrive pipelines that do not exist in Kommo?

Pipelines are created manually in Kommo before migration begins. Stages are mapped by meaning, not by name. If Pipedrive has 4 pipelines with different stages, Kommo should have 4 pipelines with the equivalent stages. Once created, their pipeline_id is used when migrating deals.

Is deal statistics migrated (won rate, avg cycle time)?

Pipedrive statistics are derived data — they are not stored as separate objects. When deals are migrated with their creation and close dates, Kommo automatically calculates its own analytics. Historical data will appear in Kommo reports immediately after deals are migrated.

Summary

  • CSV migration from Pipedrive transfers the “skeleton” — without call history, notes, or tasks
  • A full migration requires working with both the Pipedrive API and the Kommo API
  • Order: audit -> structure in Kommo -> base objects -> activities -> validation
  • Typical timeline for a full migration — 2–4 weeks
  • Files and email threads are the only things that cannot be fully transferred

If you are planning a database migration to Kommo from Pipedrive — describe your volume and what needs to be preserved. Exceltic.dev will assess the complexity and provide a concrete plan.

More articles

All →