Copper is a CRM deeply integrated with Google Workspace: Gmail, Google Calendar, Google Drive. Kommo CRM is purpose-built for messenger-based sales. The switch makes sense for teams that actively work through WhatsApp, Telegram, and Instagram and need better pipeline automation. The main migration challenge — Copper does not export Activities (notes, calls, meetings in deal cards) via its standard CSV. These are the most valuable data for the team. Automated tools like SyncMatters do not transfer them either. Here is how to do a complete migration without data loss.
Why Companies Move from Copper to Kommo
Copper was built as a CRM for teams working entirely within the Google ecosystem. That is its core strength — and its core limitation:
- No messenger integrations — WhatsApp, Telegram, Instagram are not natively available in Copper; for companies where sales run through messengers, this is a critical gap
- Basic automation — Copper does not support complex conditional pipeline logic; Kommo’s Digital Pipeline is significantly more flexible
- Tight API rate limits — as team and data volume grow, Copper API restrictions become a problem for integrations
- Price vs. functionality — Copper pricing is comparable to Kommo with fewer capabilities for sales processes
- Google dependency — teams moving away from Google Workspace or diversifying their tools lose Copper’s main advantage
The Core Migration Problem: Activities Are Not Exported via CSV
Copper provides a standard CSV export for its core objects. But on closer inspection, a critical limitation becomes apparent:
What is exported via CSV:
- ✅ People (contacts) — with custom fields and tags
- ✅ Companies — with custom fields
- ✅ Opportunities (deals) — with current field values and stages
What is NOT exported via CSV:
- ❌ Activities — notes, calls, meetings attached to deal cards
- ❌ Email threads from Gmail Sync — client correspondence history synced from Gmail
- ❌ Google Calendar events — meetings linked to deals and contacts
- ❌ Object relationships — contacts do not remain linked to companies and deals after import
Activities are the actual history of client work: call results, post-meeting notes, agreements. Without them, deal cards in Kommo will be empty — managers will have no context on ongoing negotiations.
Why SyncMatters and Similar Tools Do Not Solve the Problem
SyncMatters (MigrateMyCRM) is positioned as an automated migration tool for Copper → Kommo. The real picture is similar to the Albato limitations for Bitrix24:
- ✅ Transfers People, Companies, Opportunities — current field values
- ✅ Works automatically without coding
- ❌ Activities are transferred partially or not at all — depends on the pricing plan and volume
- ❌ Gmail threads are not transferred — email history from Gmail Sync stays in Copper
- ❌ Google Calendar events are not transferred
- ❌ No custom mapping logic — if the data structure differs from the standard schema, it breaks
- ❌ No deduplication — re-running creates duplicates
- ❌ No delta migration — data created during migration is lost
The only way to get complete data from Copper including Activities is the Copper REST API.
Data Model: Copper vs Kommo
The structures of the two CRMs are relatively similar — both use the classic contact + company + deal model. But there are nuances that require decisions before migration begins:
| Copper Object | Kommo Object | Notes |
|---|---|---|
| People | Contact | Direct match |
| Companies | Company | Direct match |
| Opportunities | Lead | Direct match |
| Pipeline + Stages | Pipeline + Stages | Must be recreated in Kommo |
| Tasks | Task | Fields differ — mapping required |
| Activities (Notes) | Note | API only |
| Activities (Calls) | Note of type “Call” | API only |
| Activities (Meetings) | Note of type “Meeting” | API only |
| Custom Fields | Custom fields | Types must match |
| Tags | Tags | Direct match |
| Gmail Sync (emails) | Note | Partial transfer via API |
| Google Calendar Events | — | No direct equivalent in Kommo |
Key decision: Google Calendar events linked to deals in Copper have no direct equivalent in Kommo. They are transferred as notes of type “Meeting” with date, participants, and description — or ignored if they contain no meaningful context.
Step-by-Step Correct Migration Process
Step 1: Data Audit via Copper API
Before starting the transfer, a complete picture must be obtained via the Copper REST API:
GET /v1/people — contacts with custom fields
GET /v1/companies — companies
GET /v1/opportunities — deals across all pipelines
GET /v1/activities — all activities (notes, calls, meetings)
GET /v1/tasks — tasks
GET /v1/custom_field_definitions — list of custom fields
GET /v1/pipeline_stages — stages of all pipelines
The audit answers key questions: how many objects of each type exist, how deep is the Activity history, are there custom fields with non-standard types, which pipelines are active.
Step 2: Prepare Kommo
Before data transfer begins, Kommo must be fully configured:
- Pipelines created with stages corresponding to Copper Pipelines
- Custom fields created for Leads and Contacts with correct types
- List field values populated
- Users created —
copper_user_id → kommo_user_idmapping table ready - Tags created if they are used in Copper
Critical mistake: starting the import before creating custom fields. Data without structure creates chaos.
Step 3: Transfer Core Objects
Transfer order matters — start with objects that have no dependencies:
- Companies → Kommo Companies
- People → Kommo Contacts (linked to Companies)
- Opportunities → Kommo Leads (linked to Contacts and Companies)
- Tasks → Kommo Tasks (linked to Leads)
At this stage, each object receives an ID mapping: copper_opportunity_id → kommo_lead_id. This table is used in the next step to link Activities.
Step 4: Transfer Activities — The Key Stage
Activities are extracted via the Copper API, filtered by type and object link:
GET /v1/activities?type[category]=note&parent[type]=opportunity
GET /v1/activities?type[category]=call&parent[type]=opportunity
GET /v1/activities?type[category]=meeting&parent[type]=opportunity
Each Activity is transferred to Kommo as a note, preserving:
- Activity type (note / call / meeting)
- Date and time of creation
- Author (via the user mapping table)
- Full content
POST /api/v4/leads/{kommo_lead_id}/notes
{
"note_type": "common",
"params": {
"text": "[Call | 15.03.2025 | John Smith]\nOutcome: client..."
}
}
Step 5: Transfer Gmail History
Email threads synced from Gmail to Copper are a unique data type with no direct equivalent in Kommo. The approach depends on how important the correspondence history is:
Option A: Full transfer
Each email thread is transferred as a note with the subject, date, sender, and body. Volume can be substantial — limiting the period to the last 1–2 years is recommended.
Option B: Selective transfer
Only emails linked to active deals from the last N months are transferred. Archived correspondence stays in Gmail as a reference.
Option C: Archiving
Email history is not transferred to Kommo — it remains accessible in Gmail. In Kommo lead cards, a link is added to search the client’s correspondence by email in Gmail.
Step 6: Delta Migration and Switchover
While the main migration and validation are underway, the team continues working in Copper. Delta migration transfers objects created or modified after the main transfer. After successful validation, the team switches to Kommo in a single day.
Common Issues in Copper → Kommo Migration
Copper API rate limits.
Copper has strict limits on the number of API requests. With large data volumes (10,000+ objects), transferring via API requires careful queue management with pauses and retry logic. Attempting to transfer everything at once leads to 429 errors and partial transfer.
Multi-Select custom fields.
Copper supports Multi-Select fields. In Kommo the equivalent is a “List” field with multiple selection. During transfer, values must exactly match pre-created options in Kommo — otherwise data is lost.
People linked to multiple Companies.
Copper allows linking one contact to multiple companies. Kommo supports linking a contact to one company. During migration, the primary company must be determined — typically the one with the most associated deals.
Loss of Google Calendar context.
Meetings from Google Calendar synced to Copper contain participants, descriptions, and outcomes. When transferred as notes, some structure is lost. For teams that actively use Calendar sync, setting up a new Kommo integration with Google Calendar after migration is recommended.
Real-World Case
Digital agency, 6 managers, 3 years in Copper, ~2,500 deals, active Gmail sync.
The agency used Copper because of its deep Gmail integration — all client correspondence was automatically linked to deals. The decision to switch to Kommo was made after several major clients shifted to communicating via WhatsApp — working with WhatsApp in Copper was not possible.
Self-migration attempt via CSV: contacts and deals were transferred, all Activity notes and Gmail history were lost. Managers could not recall negotiation context with clients — several deals in active negotiation stalled.
Custom API migration: full transfer of Activities via Copper REST API, Gmail threads from the last 18 months transferred as notes, Google Calendar meetings as notes of type “Meeting” with participants and outcomes, delta migration, one week of validation.
Result: 2,500 deals, 11,000 Activity records, and 4,500 email threads transferred. The team switched to Kommo without losing context on active negotiations. WhatsApp Business was connected on the first day in Kommo.
Which Companies Should Consider This Migration
Copper → Kommo migration is most relevant for small teams that have outgrown the Google ecosystem as their sole working environment, or that actively use messengers for sales. Copper loses its competitive advantage the moment a team moves beyond Gmail and Google Calendar.
Especially relevant for companies operating in markets where WhatsApp is the primary communication channel — Latin America, the Middle East, South Asia, Southern Europe — where Kommo’s native WhatsApp Business API integration provides a fundamental operational advantage.
Frequently Asked Questions
Why are Activities not exported from Copper via CSV?
Copper CSV export covers only core objects with a flat data structure: People, Companies, Opportunities. Activities are related objects with links to parent records — their structure is not supported by the standard CSV format. The only way to obtain Activities is via the Copper REST API through the /v1/activities endpoint.
What happens to Gmail correspondence history when switching to Kommo?
Gmail history stays accessible in Gmail — it does not disappear. The question is whether it is needed in Kommo cards. A custom migration offers three options: full transfer as notes, selective transfer for the last N months, or archiving without transfer with a link to Gmail. The optimal choice is determined during the audit.
Can Gmail still be used after switching to Kommo?
Yes. Kommo has its own Gmail and Google Calendar integration. After migration a new integration is set up — incoming emails from clients automatically create leads or are linked to existing cards. The working principle is similar to Copper but implemented differently.
How are contacts linked to multiple companies in Copper handled?
Kommo supports linking a contact to only one company. During migration, the primary company is determined for each such contact — typically the one with the most associated deals or the most recent activity. Other links are recorded in a contact note.
How long does a Copper → Kommo migration take?
A basic migration of up to 1,500 deals without extensive Gmail history — 3–5 working days. A complete migration with Activities, Gmail threads, and Google Calendar events for 5,000+ objects — 1–2 weeks including validation and delta migration. Exceltic.dev determines exact timelines after a data audit via the Copper API.
If you are planning a move from Copper to Kommo and want to preserve Activities and Gmail correspondence history — describe the task to the Exceltic.dev team. We will audit the data and propose a migration plan.