From Salesforce to Kommo: Data Model Gap and How to Close It During Migration

Migrating from Salesforce to Kommo is not simply moving rows from one database to another. Salesforce is built around four independent objects: Leads, Contacts, Accounts, and Opportunities — each with its own fields and relationships. Kommo builds everything around the deal (Lead) as the primary object. This architectural difference means that some Salesforce data has no direct equivalent in Kommo — it needs to be redesigned, not simply copied.

Companies move from Salesforce to Kommo when they are leaving a large enterprise stack in favor of a more flexible and cost-effective setup, or when they need native messenger integrations and a simple pipeline rather than a complex CRM suite. The main risk in doing so is losing data that has been accumulated over years.

Why Companies Move from Salesforce to Kommo

Salesforce is a powerful system optimized for enterprise B2B. Companies leave it for specific reasons:

• Cost. Salesforce Sales Cloud Professional — from $80 per user per month. Kommo — from $15. For a team of 10, that’s a difference of $7,800 per year on licenses alone.
• Complexity. Salesforce requires a dedicated administrator or Salesforce Developer for configuration and maintenance. Kommo can be configured by a manager without technical assistance.
• Messengers. Salesforce has no native integration with WhatsApp Business API, Telegram, or Instagram. In Kommo, these are built-in.
• Team size. Salesforce was designed for 100+ users. Kommo — for teams up to 50. For smaller teams, Salesforce is overkill.

When switching: most companies have 2–5 years of data accumulated in Salesforce. Activity history (Tasks, Events, Calls), notes, attachments — all of this needs to be preserved.

Data Model Gap: Where the Fundamental Divide Is

Salesforce uses strict separation:

• Lead — an unprocessed lead (incoming inquiry, not yet qualified). After qualification, a Lead is converted into Contact + Account + Opportunity.
• Contact — a person linked to an Account. Exists independently of an Opportunity.
• Account — a company or organization. The central object for B2B.
• Opportunity — a deal. Linked to an Account, can have multiple Contacts with roles (Decision Maker, Economic Buyer, etc.).
• Activities (Tasks, Events, Calls) — independent objects associated with a Contact, Account, or Opportunity.
• Custom Objects — arbitrary business objects (Products, Projects, Locations).

Kommo is structured differently:

• Lead (deal) — the primary object. Everything happens inside a deal.
• Contact — a secondary object, linked to a deal.
• Company — linked to a deal or contact.
• No equivalent to Salesforce Account as a central entity.
• No contact roles on a deal.
• No custom objects.
• Activities (tasks, notes, calls) — events and tasks inside a deal or contact.

Object Mapping Table

Most painful losses:

1. Opportunity Contact Roles. In Salesforce, multiple Contacts are linked to a single Opportunity with roles. In Kommo — one primary contact per deal (others as secondary, without roles). Roles are lost.
2. Account as central object. In Salesforce, an Account is a company with its own activities, contacts, and history. In Kommo, Company is a secondary object without its own event feed. Account-level history — as opposed to deal-level — does not transfer in a structured way.
3. Custom Objects. If Salesforce Custom Objects were in use (e.g., Products, Projects, Service Requests), there is no equivalent in Kommo. The data must either be archived or modeled using custom fields.

What Transfers Fully, Partially, or Not at All

Step-by-Step Migration Process

Step 1 — Salesforce Audit via API and SOQL

Salesforce provides a powerful API (REST API, Bulk API 2.0) and the SOQL query language.

SELECT COUNT(Id) FROM Contact
SELECT COUNT(Id) FROM Account
SELECT COUNT(Id) FROM Opportunity
SELECT COUNT(Id) FROM Task
SELECT COUNT(Id) FROM Event
SELECT COUNT(Id) FROM Lead WHERE IsConverted = false

Additionally: list of all custom fields on objects, list of Custom Objects, record count for each.

GET /services/data/v57.0/sobjects/Opportunity/describe
-> fields[] - all fields, including custom ones

Step 2 — Design the Mapping Schema

Key decisions to make before starting the transfer:

Unconverted Leads. Should they be transferred? If so — as separate deals in a separate “New Leads” pipeline.

Opportunity Contact Roles. Roles are lost. Solution: add a note to the deal with the list of participants and their roles — “[Decision Maker] John Smith, [Economic Buyer] Mary Jones.”

Account hierarchy. If Salesforce has Parent Account -> Child Account — in Kommo these become two independent Companies. The relationship can be indicated via a custom field “Parent Company.”

Custom Objects. Decision per object: archive to CSV + reference in deal note, or create a set of custom fields in Kommo as a surrogate.

Step 3 — Create Structure in Kommo

• Pipelines corresponding to Opportunity Stages in Salesforce
• Custom fields for all mapped Salesforce fields
• Users (User mapping: Salesforce Owner ID -> Kommo User ID)

Step 4 — Transfer Base Objects

Contacts:

SELECT Id, FirstName, LastName, Email, Phone, AccountId, [custom fields]
FROM Contact
-> POST /api/v4/contacts (Kommo)
   Save: salesforce_id -> kommo_contact_id

Accounts -> Companies:

SELECT Id, Name, BillingCity, Phone, [custom fields]
FROM Account
-> POST /api/v4/companies (Kommo)

Opportunities -> Leads:

SELECT Id, Name, Amount, StageName, CloseDate, AccountId, OwnerId,
       (SELECT ContactId, Role FROM OpportunityContactRoles)
FROM Opportunity
-> POST /api/v4/leads (Kommo)
   _embedded.contacts - primary contact
   _embedded.companies - via AccountId -> kommo_company_id

Contact Roles — add via POST request after creating the deal:

POST /api/v4/leads/{id}/notes
{ note_type: "common",
  params: { text: "Deal participants:\n[Decision Maker] Name\n[Economic Buyer] Name" }}

Step 5 — Transfer Activities

Tasks (Salesforce) -> Tasks (Kommo):

SELECT Id, Subject, Description, ActivityDate, Status, WhoId, WhatId
FROM Task
-> POST /api/v4/tasks
   { text, complete_till, entity_id, entity_type }

Events -> Notes:

SELECT Id, Subject, Description, StartDateTime, EndDateTime
FROM Event
-> POST /api/v4/leads/{id}/notes
   { note_type: "common", params: { text: "[Meeting] date\nDescription..." } }

Calls (via Salesforce CTI or Activity History):

SELECT Id, Subject, Description, ActivityDate, CallType, CallDurationInSeconds
FROM Task WHERE TaskSubtype = 'Call'
-> POST /api/v4/leads/{id}/notes
   { note_type: "call_in" or "call_out",
     params: { text: "[call] duration, description" } }

Step 6 — Validation

• Quantitative: records in Salesforce vs Kommo by type
• Qualitative: 30–50 cards side by side
• Owner check: every deal has an assigned owner
• Check that Converted Leads haven’t duplicated with Contacts

Common Issues

Salesforce Bulk API limits. Salesforce Bulk API 2.0 allows exporting up to 100 million records per day, but large volumes require batching. The standard REST API — 2,000 records per request.

Phone number format. Salesforce stores phone numbers in arbitrary formats. Kommo expects international format (+1…). Normalization is required before transfer.

Multi-currency Salesforce. If multi-currency is enabled in Salesforce — Opportunity.Amount is stored in the record’s currency. When migrating to Kommo, values need to be converted to a single currency or a custom “Deal Currency” field added.

Salesforce Formula Fields. Calculated fields (formula fields) don’t store data — they are computed on the fly. When exported via API they return the current value, but if data changes in Salesforce it may change. Transfer as a snapshot value, not as a formula.

Inactive Users. If a deal in Salesforce is owned by an inactive user — it cannot be created in Kommo without an active owner assigned. Options: reassign to an administrator or a new owner.

Real-World Case Study

A typical migration project for a SaaS company (15 employees, Salesforce Professional, 3 years):
— 6,200 Contacts, 890 Accounts, 1,400 Opportunities
— 34,000 Tasks and Events
— 8 Custom Objects (not transferred — archived to CSV)
— 31 custom fields on Opportunity, 22 on Contact

Total duration: 5 weeks. Of these, 2 weeks — mapping design (the longest phase). Custom Objects became the main discussion topic with the client team: ultimately, 3 of 8 were modeled via custom fields, 5 — archived.

Outcome: 97% of contacts, deals, and activities transferred. Losses: Opportunity Contact Roles (transferred as text notes), account hierarchy, files from Salesforce Files (left in S3 with links in notes).

Who Should Consider Moving from Salesforce to Kommo

The move is justified if:
— Sales team of 5–30 people, Salesforce is used at 30–40% of its actual capability
— Primary channel is messengers or telephony, not email campaigns
— No dedicated Salesforce administrator (or they’re leaving)
— Salesforce cost has become a pain point at current deal volume

For more on how Kommo handles custom integrations and the API — see the custom Kommo CRM integrations section.

If you need the reverse direction — from Kommo to a more complex system — read about migrating from Kommo to HubSpot: the same data model gap principle applies, but in the other direction.

Frequently Asked Questions

Can Salesforce Custom Objects be transferred to Kommo?

There is no direct equivalent of Custom Objects in Kommo. Three options exist: (1) model as a set of custom fields on a deal or contact — suitable if the object is simple; (2) archive to CSV and store as a reference outside the CRM; (3) connect Kommo to an external database via a custom integration. The choice depends on how frequently the team accesses this data in daily work.

What do you do with Salesforce Leads that were never converted?

Unconverted Leads in Salesforce are qualified or unqualified leads that never became an Opportunity. In Kommo, they are migrated as separate deals — either into a dedicated “Unqualified” pipeline or into the main one at stage zero. After migration, the team processes them manually.

Does email correspondence history transfer from Salesforce?

Emails captured via Salesforce Inbox or Lightning Email are stored as EmailMessage objects. They are accessible via API, but transferring them to Kommo as proper emails is not possible — Kommo has no Email object with the same structure. Solution: transfer as text notes with date and content, or leave in the Salesforce archive.

How much does a Salesforce to Kommo migration cost?

Cost depends on data volume, number of custom fields, and presence of Custom Objects. Simple migration (up to 5,000 records, no Custom Objects) — from $2,000–3,000. Full migration with activity history and complex mapping — from $5,000. This is a fraction of the annual Salesforce Professional license cost for a 10-person team ($9,600).

How long does parallel operation in two systems last?

We recommend no more than 2 weeks. A long parallel period creates confusion: managers update data in different places and duplicate activities. Best approach: final data sync covering the last 2 weeks before the cutover date, then switch.

Summary

• Salesforce and Kommo use fundamentally different architectures: object-centric vs deal-centric
• Opportunity Contact Roles, Account Hierarchy, and Custom Objects have no equivalent in Kommo — they must be redesigned
• Contacts, deals, tasks, and events transfer via API with mapping
• The main phase is not the technical transfer, but mapping design: 2 of 5 weeks in a typical project
• 97%+ of data is transferable with the right approach; exceptions are objects with no Kommo equivalent

If you are considering a move from Salesforce to Kommo — describe your database size and which Custom Objects were in use. Exceltic.dev will assess mapping complexity and propose a concrete plan.