From Bitrix24 to HubSpot: Why Automated Tools Lose Activity History

Migrating from Bitrix24 to HubSpot via CSV or no-code connectors transfers contacts and deals — but loses the history of calls, tasks, emails, and internal comments. This is not a bug in any particular tool: it is an architectural mismatch between how Bitrix24 stores activities and how HubSpot accepts them. Without special handling, only the database “skeleton” is transferred — without the communication context that constitutes the real value of a CRM.

If your team is planning to move from Bitrix24 to HubSpot and preserving client interaction history matters, this article will explain exactly where data is lost and how to keep it.

Why Companies Move from Bitrix24 to HubSpot

Bitrix24 is an all-in-one platform: CRM, tasks, HR, and a corporate portal in one system. For companies that have outgrown this format, that becomes a problem. Common reasons for switching:

• Reporting. Bitrix24 offers only pre-built templates. HubSpot provides cross-object reports across contacts, companies, deals, and activities without exporting to Excel.
• Marketing and sales in one database. In Bitrix24, CRM and email marketing are separate modules with poor synchronization. HubSpot is a unified platform with a native Marketing Hub.
• International stack. HubSpot integrates natively with Salesforce, Stripe, Calendly, and Typeform. Bitrix24 is locked into its own ecosystem.
• B2B pipeline. For deals with multiple stakeholders, HubSpot offers roles, associations, and cross-object workflows — capabilities Bitrix24 lacks architecturally.

Meanwhile, Bitrix24 accumulates years of data: call history through built-in telephony, client-related tasks, deal comments, and email correspondence via the Email Tracker. This is exactly what is lost in a standard migration.

The Architectural Gap: How Activities Are Stored in Bitrix24 and HubSpot

Bitrix24 stores activities across several unrelated entities:
— CRM_ACTIVITY — calls, emails, meetings, attached to a deal or contact
— TASK — tasks in the CRM section (a separate table from the Tasks module)
— TIMELINE — internal notes and comments on deals
— Emails via Email Tracker — a separate entity linked to a CRM element

All of this is accessible via the Bitrix24 REST API (crm.activity.list, task.item.list), but cannot be exported to CSV.

HubSpot accepts activities through separate API endpoints:
— /crm/v3/objects/calls — calls
— /crm/v3/objects/emails — emails
— /crm/v3/objects/meetings — meetings
— /crm/v3/objects/notes — notes
— /crm/v3/objects/tasks — tasks

Each activity object is created with a separate POST request, then associated with a contact, company, or deal via /crm/v4/objects/{type}/{id}/associations.

No-code tools (HubSpot Data Importer, Albato, Make) work with CSV or standard CRM objects — they cannot read CRM_ACTIVITY via the Bitrix24 API and cannot create activity associations in HubSpot via API. That is why history simply does not transfer.

What Exactly Is Lost in a Standard Migration

“Partial” for contacts and deals means standard fields are transferred (name, phone, email, deal amount), but not all custom fields and not the relationships between objects.

Why “Partial” Is a Problem

A contact without communication history is just a row in the database. When a manager opens a contact card in HubSpot after migration, they see:
— Name, phone, email
— Deal status at the time of transfer
— An empty activity feed

Questions like “when did we last speak,” “what did we promise on the March call,” “why did this deal stall” — go unanswered. The manager calls the client blind. A client who spent 6 months in negotiation with the team gets asked: “Tell me about your problem.”

For companies with long deal cycles (B2B, SaaS, consulting), this means direct losses: re-qualifying leads that were already qualified, repeated demos, and damaged trust.

The Correct Migration Process via API

A complete migration from Bitrix24 to HubSpot involves five stages.

Stage 1 — Data Audit in Bitrix24

Before the transfer: inventory via API.
— crm.contact.list — number of contacts, list of custom fields
— crm.deal.list — deals, stages, custom fields, links to contacts and companies
— crm.activity.list — number of activities by type (calls, emails, meetings, tasks)
— Check for duplicate contacts (Bitrix24 does not block creation of duplicates)

Output: an object map with record counts and a scope estimate.

Stage 2 — Develop a Mapping Schema

Custom fields in Bitrix24 have no direct equivalents in HubSpot. Required steps:
— For each Bitrix24 custom field — create a property in HubSpot via /crm/v3/properties/{objectType}
— Map data types: CRM_FIELD_TYPE_STRING -> text, CRM_FIELD_TYPE_ENUMERATION -> enumeration with value mapping, CRM_FIELD_TYPE_DATE -> date
— Decide what to do with fields that have no equivalent: archive them in notes or create a custom property

This stage requires team involvement — only they know which fields are actively used and which are filled with historical noise.

Stage 3 — Transfer Base Objects

Order matters: contacts first, then companies, then deals — otherwise associations cannot be created.

1. Contacts -> /crm/v3/objects/contacts (batch API, up to 100 records per request)
2. Companies -> /crm/v3/objects/companies
3. Contact–company associations -> /crm/v4/objects/contacts/{id}/associations/companies
4. Deals -> /crm/v3/objects/deals
5. Deal–contact and deal–company associations

Each record receives the Bitrix24 internal identifier (bitrix_id) as a custom property — this is needed to link activities in the next stage.

Stage 4 — Transfer Activity History

The most labor-intensive stage. For each activity type:

Calls (CRM_ACTIVITY_TYPE_CALL):

GET /rest/crm.activity.list?filter[TYPE_ID]=2
-> POST /crm/v3/objects/calls
   { "properties": { "hs_call_title": ..., "hs_call_body": ...,
     "hs_call_duration": ..., "hs_call_direction": ...,
     "hs_timestamp": ... } }
-> POST /crm/v4/objects/calls/{callId}/associations/contacts/{contactId}

Notes and comments:

GET /rest/crm.timeline.comment.list
-> POST /crm/v3/objects/notes
   { "properties": { "hs_note_body": ..., "hs_timestamp": ... } }
-> Association with contact or deal

Tasks (task.item.list):

GET /rest/tasks.task.list?filter[UF_CRM_TASK]=Y
-> POST /crm/v3/objects/tasks
   { "properties": { "hs_task_subject": ..., "hs_task_body": ...,
     "hs_task_status": ..., "hs_timestamp": ... } }

Each request is logged: ID from Bitrix24, ID in HubSpot, status. On failure — retry with an idempotent key (hs_unique_creation_key) to avoid duplicates.

Stage 5 — Validation

• Spot check: 20–30 cards with history in both systems side by side
• Automated check: activity counts by type in Bitrix24 vs HubSpot
• Association check: every activity must be linked to a contact or deal
• Final discrepancy report — what was not transferred (typically files and some custom activity types)

Common Issues and How to Resolve Them

Duplicate contacts in Bitrix24. Bitrix24 does not block creation of contacts with the same email. Deduplication is required before transfer — either via Bitrix24 API (search by email) or through intermediate processing. Transferring with duplicates will cause conflicts in HubSpot or create separate records.

HubSpot API rate limits. HubSpot limits most endpoints to 100 requests per 10 seconds (depends on plan). For a database of 10,000+ contacts, a queue with delays and exponential backoff on 429 responses is required.

Empty required fields. HubSpot requires email for a contact or dealname for a deal. In Bitrix24 these fields can be empty. Pre-processing is needed: fill with placeholders or skip records and flag them for manual review.

Timezones in dates. Bitrix24 stores dates in UTC+3 (or the account’s configured timezone). HubSpot expects Unix timestamps in milliseconds UTC. Converting without accounting for timezone shifts dates by several hours.

Large file attachments. HubSpot API accepts files up to 512 MB via /files/v3/files. Files from Bitrix24 must first be downloaded via disk.file.get, then uploaded to HubSpot Files and linked to an activity. In practice, only small files are transferred; large archives remain in cloud storage.

Real-World Case

A typical Bitrix24 to HubSpot migration project for a B2B company with 3 years of history:
— 8,400 contacts -> 8,217 after deduplication
— 2,100 deals across 4 pipelines
— 47,000 activities (calls, tasks, notes, emails)
— 23 custom fields, of which 18 mapped directly and 5 were reorganized

The transfer took 4 weeks: 1 week for audit and mapping, 1 week for script development and staging testing, 2 weeks for the main transfer with validation. 94% of activities transferred completely; 6% were file attachments, left in Bitrix24 as an archive.

For comparison: an attempt via HubSpot Data Importer + CSV took 2 days and transferred only contacts, deals, and 11 standard fields — without a single activity.

Which Companies Should Consider This

Migration makes sense if:
— B2B with a deal cycle of 2+ weeks and multiple stakeholders on the client side
— Cross-channel analytics from marketing to sales in one database is required
— The team uses or plans to use HubSpot Marketing Hub or Service Hub
— International stack: Stripe, Calendly, Salesforce, Looker — all integrate natively with HubSpot

Migration is not advisable if:
— Main sales channel is messengers and inbound leads with a short cycle
— Team is fewer than 10 people with no growth plans
— Bitrix24 is actively used as a corporate portal (tasks, HR, disk) — migrating only the CRM portion in isolation requires special care

Frequently Asked Questions

Can the migration from Bitrix24 to HubSpot be done independently?

Partially — yes. HubSpot Data Importer allows uploading contacts, companies, and deals via CSV. This is free and works for small databases without critical history. Transferring activities (calls, tasks, correspondence) requires scripts on the Bitrix24 REST API and HubSpot API — this requires development. The scope depends on the number of activities and the presence of custom fields.

How long does a Bitrix24 to HubSpot migration take?

For a database of up to 5,000 contacts with activity history — 3–4 weeks including audit, development, and validation. For databases of 10,000+ — 6–8 weeks. Most time is spent not on the technical transfer but on mapping custom fields and deduplication — this requires business involvement, not just a developer.

What to do with Bitrix24 pipelines that have no equivalent in HubSpot?

Bitrix24 allows creating CRM directions with different stages. In HubSpot these correspond to Pipelines. Create a separate pipeline in HubSpot for each Bitrix24 direction. Stages are mapped manually — there is no literal correspondence; the business must decide how a stage like “Contract Approval” in Bitrix24 is named in the new system.

Can HubSpot run in parallel with Bitrix24 during the transition period?

Yes, and this is the recommended approach. The team continues working in Bitrix24 while migration is in progress; on the agreed date they switch to HubSpot. Synchronization between systems during the parallel period is optional: typically a final sync of new records from the last 2–4 weeks before cutover is sufficient.

Is email history from Bitrix24 lost?

Emails sent through the built-in Bitrix24 Email Tracker (CRM_ACTIVITY_TYPE_EMAIL) are stored as activities and transferred via API — the email body, date, direction (inbound/outbound), and link to the contact. Emails from external mail clients not captured by the tracker are not stored in Bitrix24 and cannot be transferred.

Summary

• CSV and no-code tools transfer only the database “skeleton” — contacts, deals, basic fields
• Call history, tasks, emails, and notes require work via the Bitrix24 REST API and HubSpot API
• Correct sequence: audit -> mapping -> base objects -> activities -> validation
• Typical timeline for a complete migration — 4–6 weeks; attempting to do this over a weekend will result in data loss
• 94%+ of activities are transferable with API migration; exceptions are binary files and custom activity types

If you are currently planning a move from Bitrix24 to HubSpot — describe your database size and what you need to preserve. The Exceltic.dev team will assess the mapping complexity and propose a concrete plan.