Why Zoho CRM migration to Bitrix24 breaks in the middle
Migration from Zoho CRM to Bitrix24 usually starts as moving tables: export contacts, deals, tasks — upload them. Everything breaks on relationships. In Zoho, a deal rests on several entities: contact, company, owner, emails.
If you transfer them as separate files, the links between deals, contacts, and companies are broken — the deal opens, but it no longer has an associated contact.
A separate pain point is losing communication history. Emails, calls, and comments are stored linked to internal record IDs, not names. When transferring a customer base without preserving these IDs, some messages cannot find their recipient and settle as dead weight. The manager sees a deal without the discussion of terms and calls the customer as if they were new.
The third reason is fields. In Zoho, they were configured for a specific sales department: reference lists, multiple values, calculated fields.
In Bitrix24, these types have different logic, and during a direct transfer some values arrive empty or truncated — an empty field looks like missing data, even though the data existed.
And the main organizational trap: while the transfer is underway, the sales department continues working in the old system. Deals move through stages, new emails arrive, owners change — the database changes faster than it is transferred. Without freezing and re-transferring changed records, the migration turns into endless catch-up.
That is why we transfer not with files but with a data model: first a mapping of entities and fields, then relationships, then communication history, and only at the end — switching the department. We explain how this is closed at each step.
What managed transfer provides: speed, integrity, control
Managed transfer is not "exported an archive and uploaded it back." First, the target structure is deployed: pipelines, reference lists, custom fields, and statuses are aligned with the previous ones; otherwise, some data will land in empty fields and lose meaning. Only after that are records uploaded — in layers, from reference lists to deals.
Data integrity is checked by relationships, not by row count. A contact remains linked to a company, a deal — to a contact, a task and email — to a deal, an attachment does not detach from a comment.
The acceptance criterion is zero orphan records for significant entities: if the relationship has not been restored, the record is not considered transferred.
Record reconciliation has three levels: counts for each entity before and after, comparison of key fields on a control sample, then manual review of discrepancies.
Transfer completeness control is closed with a report — how many records went in, how many were accepted, what remained in quarantine and why. Such a report removes the main risk: silent loss of history.
Downtime is reduced by uploading changes afterward. While the main migration is underway, the working system continues to live, and changed records are transferred in a second pass. The switchover window is measured in hours, not days, and is scheduled for an agreed time.
The "lost history" failure class is eliminated at the schema level: each record has a source, transfer time, and run label.
Therefore, any entity can be rechecked, topped up, or rolled back to a return point without a full re-transfer — the duration of work becomes predictable.
Data transfer methods: batch export or synchronization
Transfer from Zoho CRM to Bitrix24 is rarely one-time: some deals, notes, and communication continue to live in the source until the new system becomes primary.
Whether the source is frozen or left operational determines the method — batch export, continuous synchronization, or manual assembly of reference lists.
| Option | When it fits | Limitations |
|---|---|---|
| Batch export | The source is fixed for the duration of the move, volume is known in advance | Data is current as of the cut; relationships, attachments, and stage history require separate completion |
| Continuous synchronization | Both systems run in parallel for weeks | Matching keys and duplicate protection are needed; an error in the rules is replicated across the entire volume |
| Manual field transfer | Few records, non-standard reference lists and fields | Slow, depends on operator attention, change history is not preserved |
Limitations of batch export
The source returns data in portions, and pauses are needed between requests — otherwise part of the export fails due to exceeding the request limit.
Before transfer, we fix the field schema and value mapping: stages, sources, owners, record types; otherwise rows arrive empty and have to be reviewed manually.
How synchronization behaves
Continuous exchange runs on a schedule or by event and relies on an external record ID, so a repeat run does not create duplicates.
During the move, both systems remain operational, and disputed records go into a discrepancy log — they are reviewed by a responsible person, not by automation.
Transfer stages: schema audit, relationship setup, final reconciliation
Transfer does not start with export but with reviewing what has accumulated in the source. A working database almost always has duplicate contacts, fields with incompatible types, and attachments linked to the wrong entities.
If you run the import immediately, these defects move into the new system along with the data, and they have to be reviewed in live mode.
- Data schema audit — inventory of entities, fields, reference lists, and files; we mark what we transfer as is, what we normalize, and what goes to archive without transfer.
- Field mapping — a "source → target" table with types and transformation rules; separately review places where the structure does not match one-to-one.
- Relationship setup — deals, contacts, companies, owners, pipeline stages; we create reference lists in advance so records do not remain without a parent.
- Test-environment run — a full transfer to a copy of the target system with time measurement and the share of rejected records; duplicates and broken relationships surface before the live database.
- Mapping rule adjustments — based on the run results, we refine the logic, transfer missing reference lists, and configure rights and roles.
- Control reconciliation — we reconcile the number of records in each entity, selectively check relationships and deal history, and record each discrepancy with its cause.
- Handover — final transfer, data verification instructions, and a return point to the previous environment until acceptance is confirmed.
What we hand over after transfer: schemas, access policies, procedures
Transfer is a one-time operation, but the value is in what remains after it.
If, as a result, the client's team has no description of relationships, field mapping, and access rules, any card edit again turns into excavation: why a deal has two contacts, where the owner came from, what will happen during a repeat export.
Therefore, the project is closed not with "the data has moved" but with a set of documents and settings in hand.
- Object relationship schema. What is linked to what after transfer: deals with contacts and companies, tasks, calls, and emails with cards, attachments with records. It shows which entities are affected by closing a deal and where cascading changes are possible.
- Field mapping. Old source field → field in Bitrix24, value type, required status, rules for transforming reference lists and recalculating owners. A new developer does not have to guess where a value in the card came from.
- Access policies and user roles. A "role → section → action" matrix configured directly in the system, not in a separate table. A separate block covers what external users and contractors can see.
- Repeat export procedure. Frequency and launch window, operator steps, behavior on discrepancy — update the record or create a duplicate, who confirms a disputed case.
- Reconciliation log. For each entity: how many records the source provided, how many were accepted, how many were skipped and for what reason. We also rely on it during rechecking before handover.
- Administrator instructions. How to assign a role, add a field to the map, run and roll back an export, what to do if access to the source fails.
Transfer documentation is stored as a single set in the client's internal knowledge base or next to the task configuration, not in chat. Then the team handles a repeat export, rights audit, or onboarding a new employee itself, without going back to the contractor.
Case study: transferring a customer base without losing deals and history
Before the transfer, the Zoho CRM database had been running for several years and had accumulated traces of manual work: duplicate companies under different spellings, deals without a linked contact, communication as separate emails off to the side of the cards.
A simple export would have produced neat tables and dead links in Bitrix24 — the manager opens a deal and does not see what was agreed. That is why we transferred not "as is" but with key review and subsequent reconciliation.
How we transferred
First, we built an intermediate layer between the systems: contacts, companies, deals, and tasks were sorted into entities, and linking was built by internal IDs, not names — otherwise duplicate companies would have broken the relationships.
Communication history was pulled to the cards as an event feed, preserving the author, date, and email direction.
What reconciliation showed
The main environment was transferred in 36 hours, and reconciliation and top-up upload took about another day.
Of 320,000 contacts and 74,000 deals, 99.4% of records passed reconciliation: discrepancies were truncated phone numbers, empty required fields, and several cards with identical email addresses.
They were reviewed in a separate pass over 4 hours, "deal — contact — company" relationships were restored for 98% of deals, and communication was pulled to 91% of cards.
Rollback to the original snapshot remained available until final confirmation — until that moment, the working data in the old system was not touched.
How does one-time data transfer differ from continuous synchronization?
One-time transfer is a snapshot of data at a specific moment: we export deals, contacts, communication history, tasks, and attachments, transfer them to Bitrix24, and reconcile the count and checksums for each entity.
After that, the systems live independently — the old one is shut down, and the new one becomes the single source of truth.
The limitation is also clear: edits made in the previous environment after the cut will no longer be pulled in. Therefore, the transfer is scheduled for a window when employees are not working, and recording is stopped for that time. But the result is predictable — it is checked once, and after that the picture does not change.
Continuous synchronization is needed when the transition is stretched out: some departments continue working in the old environment, and external services are still tied to the previous reference lists and customer IDs. Then a regular entity exchange is set up between the systems, with records matched by a stable key.
The main work here is not in the transfer itself but in the rules: which environment is considered the owner of a field, how conflicting edits are resolved, by what attribute duplicates are merged, and what happens to a record if no response is received.
Without an explicit priority, both systems begin overwriting each other, and the data diverges faster than it can be reconciled manually.
The choice of transfer method comes down to three questions: whether the entire team moves on the same day, whether there are external integrations in the old environment, and whether history needs to be visible in the new system immediately.
If everyone moves at once, a one-time transfer is enough. If the transition is phased, synchronization is used, but necessarily with an exchange shutdown date and a discrepancy log.
Concerns about Bitrix24: duplicates, attachments, rights, and fields
Duplicate contacts are collapsed before upload, not removed manually afterward.
We normalize phone numbers and addresses, compare records by match, and assemble groups where the leading card becomes the one with the full deal history, while the others are attached to it as linked.
Links in deals, tasks, and emails are relinked to the leading card — no "orphaned" activities remain in Bitrix24.
Attachments and communication travel together with the deal: files are placed in the portal storage, and emails are loaded into the feed with dates and participants.
Links to external files that are no longer available are marked separately — it is clear that part of the data cannot be restored, and this is recorded in the report rather than surfacing a month later.
We enable required fields after upload, not before: otherwise historical records with incomplete completion simply will not pass, and some contacts will be lost.
We configure rights by roles and departments — an employee sees their own deals and shared reference lists, while other pipelines remain closed; we test on test accounts before opening access to the team.
Can we roll back if something transferred incorrectly?
Yes. Upload goes to a copy of the portal and into a separate pipeline, the return point is fixed before the start — an unsuccessful run is rolled back without losing the working database.
What should be done with duplicates that appear after the transfer?
We leave an auto-merge rule based on matching address and phone: new records are collapsed on entry, and the contact list does not grow.
Let's discuss the task: we will return with an estimate and transfer plan
To return with a transfer estimate and timelines, we need not a general idea but a snapshot of the current Zoho CRM configuration and database volume.
The more accurate the source data, the fewer assumptions in the work plan and the more predictable the result after transfer to Bitrix24. Below is what we request from the client and what we clarify on a call.
- type of access to the source system: administrator rights or exports by modules;
- list of modules and configured fields — standard and customized, including relationships between records and required completion;
- database volume by module: number of records, attachments, and files, presence of duplicates and outdated records;
- pipelines and deal stages, their order and transition rules — the logic of transfer to stages depends on this;
- users, roles, and access rights, so the team structure is preserved after the switch;
- automations, scenarios, integrations, and forms — what we transfer as is and what we rebuild from scratch;
- completeness requirements: which records are critical, whether selective migration is acceptable, and what to do with attachments.
After the call, we return with an estimate and work plan: composition of stages, transfer timelines, data reconciliation points, and rollback procedure.
We build the plan so that migration can be carried out in parts — first reference lists and users, then deals and history, without downtime in the department's work.