Migration from HubSpot to Bitrix24: Data Transfer Without Loss

Migrating HubSpot to Bitrix24: where data gets lost

Moving data from HubSpot to Bitrix24 looks like exporting a few tables and loading them with the built-in import.

In reality, objects in the source system are linked not by fields but by identifiers: a deal references a contact and a company, an activity references a deal, an owner references a user.

A flat export does not preserve these links: instead of a relationship, a name remains as a string, and after loading, database integrity rests only on spelling matches.

Deal migration suffers first. Pipelines almost never match by number and stage logic, and the amount, close date, and source have no direct counterparts in the target fields.

If the mapping is not checked before loading, some deals land in the first stage with empty details, and the manager sees not a work history but a draft card.

Interaction history is the most painful part. Emails, calls, and notes are migrated as separate objects and lose their link to the deal along with the timeline.

Exporting contacts adds duplicates: the same person arrives from a form, from correspondence, and from an old import with different spelling, and deduplication by email removes extra cards along with their activities.

Broken object links mean the sales department cannot see who talked to the client and when, and has to rebuild context from email. Below we examine exactly which steps break the links and how the migration is performed without losing history.

What the migration delivers: integrity, speed, reporting

The migration preserves not table rows but relationships between objects: contact, company, deal, task, and activity are transferred as a single connected set.

Identifiers are matched during preparation, so after migrating HubSpot to Bitrix24, a deal card opens with the full touch history, emails, and tasks.

With manual export to CSV, these links break — the deal arrives as an "orphan," and the manager reconstructs context from memory.

The second effect is controlled handling of duplicate records. Before loading, we run the database through matching rules by email, phone, and domain, merge matches, and only then migrate.

The result is one client card with consolidated history instead of three or four copies that multiply during import and spoil attribution.

Automated reporting is built on the same links. The pipeline, stages, and required fields are configured before data loading, so conversion and manager workload reports are assembled from the system rather than from manual exports.

The time to prepare a summary drops from hours of reconciliation to a few minutes — the numbers reconcile across departments.

Deal search speed is a direct consequence of data cleanliness. Search by filters works, not memory or an email archive: the needed deal is found in seconds, not at the end of the workday. This set of effects is what makes the migration worthwhile.

Data migration methods: comparing approaches

The choice of method is determined not by database size but by what exactly needs to be preserved: only contacts or also relationships, email history, attachments, and deal stages.

Below are four approaches our engineers use in practice, with honest limitations on data volume and structure.

Volume itself is not a barrier: files are split into reasonably sized parts, and exchange proceeds in batches with control over the number of processed records.

What is critical is different — fixing the field map and deduplication rules in advance; otherwise links break, and data has to be cleaned manually inside the new system.

Work stages: from object audit to handover of the environment

Migration between systems is not a one-time file export but a sequence with checkpoints, where each step shows that data has not been lost.

In HubSpot, information is organized by objects with their own relationships: contacts, companies, deals, tasks, attachments, and correspondence history.

In Bitrix24, each object has its own logic of relationships and required fields, so migrating "as is" almost always produces duplicates, broken links, and lost attachments. We break down an order in which the volume is reconciled down to the last record.

1. Object audit. We count records by each type, export the list of custom fields, assess the volume of attachments and relationships, and find duplicates and abandoned records. The output is an inventory table with actual numbers, not expectations.
2. Field mapping scheme. We build a "source field → target field" map, including reference data: deal stages, lead sources, and loss reasons. For fields without a pair, we record a decision — merge, move to a comment, or create a new one.
3. Target preparation. Before migration, we configure pipelines, stages, custom fields, and access rights. Data lands in a ready structure, not in "raw" fields with subsequent manual sorting.
4. Trial run. We migrate part of the real dataset along with relationships and attachments, measure time, and check how correspondence history and cards look. Here we also catch schema conflicts while the volume is small.
5. Main migration. We proceed in batches with a log for each record. Re-running a batch does not create duplicates — this is critical for long migrations that run for days.
6. Record reconciliation. We compare counts for each object, checksums by key fields, selectively open deals and verify the chronology of events. We resolve discrepancies down to zero, not "approximately."
7. Environment handover. We hand over access, a data backfill policy, and documentation on the mapping scheme. In parallel, we provide support — the first weeks of work in the new system show what should be fine-tuned.

This sequence provides the main thing: stopping points. At any step it is clear what has already been migrated and what remains, and rolling back to the previous state does not require re-exporting the entire dataset.

Schemes, access policies, and exchange regulations

Data migration ends not with an export but with a package of documents that the client's team then uses on its own. Without it, the new system turns within a few months into a set of fields and stages whose purpose only one person remembers. Here is what we hand over and what we check at acceptance.

• Object relationship scheme — a mapping: which records and fields became leads, contacts, deals, and companies, where relationships were rebuilt, and which attributes had to be normalized for the Bitrix24 structure.
• Lead routing map — which forms, mailboxes, and telephony write to the new entities, where record identifiers are stored for later reconciliation.
• Access rights matrix — a "role → object → action" table: who sees deals, who changes stages, who exports reports, and which levels are granted to external contractors.
• Exchange regulations — the synchronization schedule with 1C and external services, the rule for the client source of truth, the procedure for resolving edit conflicts, and integration error handling.
• Employee instructions — role-based scenarios: create a lead, hand off a deal between departments, process a duplicate, report a synchronization failure.
• Acceptance and rollback sheet — pre- and post-migration reconciliations, the procedure for returning to the previous state in case of discrepancy, and the person responsible for an incident.

Case study: migrating a portal without stopping the sales department

The sales department worked in HubSpot without pauses: active deals, correspondence history, tasks, and telephony links with inventory accounting.

The new Bitrix24 environment was set up in parallel with the working portal, so managers did not stop for a single day — the transition to the new system took one work evening, when no one was already working deals in the old environment.

How we migrated and reconciled

Objects were exported in dependency order: companies, contacts, deals, tasks, emails, and attachments.

Source portal identifiers were stored in a separate field — they were used to match related records so as not to lose links between contacts and companies and between deals and contacts.

Reconciliation was not selective but covered all records: comparison of object counts by each type, checksums by key fields, and a discrepancy report with the address of each problematic card.

Metrics before and after

The share of records with preserved relationships was 99.6% after the first run; the remainder was resolved manually using the discrepancy log.

Previously, reconciliation was done in spreadsheets and took about three weeks with two employees; now it fits into two days and runs automatically before each backfill.

Support requests in the first month after launch were isolated and about access rights setup, not lost data; before the migration, such requests came in dozens per month.

What to do if a working environment is already deployed in Bitrix24?

A working portal is not a blank slate: deals are already in progress, tasks with assignees are pending, correspondence history has accumulated, and rights are configured.

Loading "on top" will duplicate clients, break the link between a contact and a company, or reset the stage of a deal that a manager is working on right now. We migrate only according to agreed matching rules and with protection for existing records.

Record matching uses stable keys, not names. First the external identifier from the source system, then normalized email, phone, and company domain — this order produces fewer false matches.

We save the reconciliation result in a link table, so a repeat run is idempotent: a duplicate is not created where the record has already been migrated.

Data protection begins before the first real record: we take a snapshot of the portal, run the migration on a copy, and compare the number of records before and after, as well as verify that no deal changed stage or owner.

Migrated data arrives in separate pipelines and stages with restricted rights — the department's working logic continues as before, and the new data is connected after acceptance.

We merge reference data one-way: we add missing stages, sources, loss reasons, and companies, and do not overwrite existing values. Values that differ in meaning are not "reconciled" automatically — they go into a discrepancy report for manual review.

We match users by work email, create new ones for unmatched users, and the rollback point is described in advance: restoring from the snapshot returns the portal to its original state.

Technical concerns before data migration

Before migrating from HubSpot to Bitrix24, engineers ask the same questions — about duplicates, empty fields, and rollback. Below are short answers: they also become points in the regulations and checks on the test environment.

What happens to empty fields?

Some fields in Bitrix24 are required, and in the source they are not always filled. Such records are not discarded: they receive a default value and are included in an incomplete data report for manual clarification.

How are attachments and files migrated?

Files from emails and cards are stored separately from the record and are migrated in their own pass. After loading, attachments are linked to entities, and the list of broken links is provided separately.

Will access rights be preserved?

We migrate roles, departments, and pipelines at the structure level, and the link to employees is configured anew. This way a manager sees only their own deals, while an administrator sees all.

Can changes be rolled back?

Before writing to the working environment, we take a snapshot of the export and run it on a copy. If the result differs from the expected one, changes are rolled back from the snapshot, and working data remains as it was before migration.

Let's discuss the task: what data we migrate and in what order

To come back with a volume estimate, a stage plan, and a scope of work, we need initial data about your HubSpot account and the target Bitrix24 portal.

Below is what is enough to capture from the current system: collecting the list takes half an hour, but the migration order and timelines depend on it.

• Object volume: how many contacts, companies, deals, and tasks, what custom fields and relationships between objects they have.
• Activities and correspondence: the number of emails, calls, notes, and meetings, the share of records with attachments — this is the largest part, and we plan it as a separate wave.
• Pipelines and automation scenarios: deal stages, transition rules between them, what we migrate as is, and what is more logical to rebuild on the Bitrix24 side.
• Data sources: website forms, email, telephony, messengers, external services — for each channel we determine how records will continue to enter the new system.
• Access: service access to the source with read rights, Bitrix24 portal administrator, and a separate test environment for runs.
• Matching rules and duplicates: by which fields we link records, what we do with duplicates and cards without an owner.
• Reconciliation regulations: how we confirm completeness — the number of records for each object, sums and values by key fields, and selective verification of relationships.
• Switchover window: when recording to the source can be closed and how much time the team is ready to work in reconciliation mode.

Send us what you already have: an export, screenshots of sections, a description of sales processes. Describe the task — we will come back with a volume estimate, a stage plan, and a scope of work for each block.