Blog June 4, 2026 11 min read

Migrating off Bitrix24: a step-by-step checklist with zero data loss

Q: Can I move the entire conversation and call history out of Bitrix24?

Deal history and comments — yes, via the REST API (the programmatic data-exchange interface). Call recordings depend on where they live: the built-in Bitrix24 telephony exposes recordings in a limited way, while external services (Ringostat, Binotel) store them on their side and carry over by reconnecting the integration.

Q: How long does a migration from Bitrix24 to Uspacy take?

A standard project is 3-5 weeks: one week for inventory and field mapping, 1-2 weeks to configure Uspacy, and one week for the test and live migration with verification. Complex automations add time.

Q: What do I do with Bitrix24 business processes during a migration?

They cannot be moved automatically — each system has its own automation engine. The working approach: document which processes are actually in use (usually 20-30% of what was configured) and rebuild them with the new system's native tools.

Q: Does the sales team stop working during the migration?

No, if the migration is planned correctly: the team works in Bitrix24 until day X, the data delta is moved over the weekend, and from Monday work happens in the new system. Downtime — zero business days.

Q: Which Bitrix24 data is not worth moving?

Deals closed more than 1-2 years ago, inactive contacts with no deals, leads that have not converted in over a year, and system fields nobody ever filled in. These get exported to Excel/BigQuery as an archive — access stays, but there is no ballast in the new system.

Q: Where do companies most often migrate from Bitrix24?

In our practice: Uspacy — when you need a familiar Ukrainian product without an excess of modules; Pipedrive — when the focus is B2B sales and a predictable pipeline; NetHunt — when the team lives in Gmail. The choice depends on the process, not on what is trendy.

Q: How much does a migration off Bitrix24 cost?

It depends on the volume of data, the number of custom fields, and the automations. The range is wide, so an honest figure is only possible after a portal inventory — that is the first week of the project, at a fixed price.

Q: Can I migrate on my own using the standard export?

Partly: a CSV export moves contacts and companies, but it loses comments, activity history, links between entities, and files. For a base of up to 1,000 contacts with no history — acceptable. For a working portal with years of data — no.

What to move, what to archive, in what order, and where data most often gets lost. An 18-point checklist proven on real-world migrations.

MigrationBitrix24UspacyChecklist

TL;DR

In short

Migrating off Bitrix24 is three phases: inventory (what is actually used), transfer (contacts, active deals, history), and integrity verification.
Data is most often lost in three places: deal comments, links between entities, and files attached to records.
You should move only active data: closed deals older than 2 years are better exported to cold storage than dragged into the new system.
A standard migration to Uspacy takes 3-5 weeks; to Pipedrive or NetHunt, 4-6 weeks because of differences in the data model.

Bitrix24 is rarely abandoned because of a “bad system.” It gets abandoned because the portal has turned into a dumping ground: hundreds of fields nobody fills in, automations nobody remembers the purpose of, and a license that costs more than the value it delivers. Below is the migration checklist we use.

Phase 1: inventory (week 1)

1. Get the real picture of usage. How many active users logged into the portal over the past month? Which sections were opened? Usually what is actually alive is deals, contacts, and tasks — everything else is dead.

2. Count the data. The number of contacts, companies, deals (open / closed over a period), leads, tasks, files. This is the basis for estimating timelines.

3. Identify the custom fields that work. A field filled in on fewer than 10% of records is a candidate for the trash, not for transfer.

4. Document the live automations. Not all the ones configured, but the ones that actually trigger. Look at the log for the past month.

5. Map the integrations. Telephony, website forms, messengers, 1C/BAS. For each one: is there an equivalent in the target system, and is middleware (an intermediary service that links systems) needed.

Phase 2: preparing the target system (weeks 2–3)

6. Design the data model from scratch. Do not copy the Bitrix24 structure — it was the problem in the first place. Pipelines, stages, fields — built around the real process.

7. Build the field mapping. A table of “field in Bitrix24 → field in the new system → transformation rule.” This is the core migration document.

8. Decide the fate of the archive. The recommendation: active deals + deals closed in the last 1–2 years go into the new system; the rest goes to cold archive (Excel, BigQuery, a portal backup).

9. Configure the target system before migrating data. The data moves into a ready structure, not the other way around.

10. Reconnect the integrations. Telephony and forms must write into the new system from day X.

Phase 3: migration and verification (weeks 4–5)

11. Run a test migration on a slice of data. 500–1,000 records. They surface errors in mapping, encoding, and duplicates.

12. Check the three classic loss points:

deal comments and timeline — the REST API returns them as separate requests; they are not in the standard export;
links between entities — contact ↔ company ↔ deal must be preserved;
files — record attachments have to be downloaded and re-linked.

13. Agree on day X and the freeze. From Friday evening the portal is in read-only mode (view only, no changes); over the weekend the delta (data that changed after the test transfer) is moved; on Monday the team is in the new system.

14. Migrate the live data. Following the prepared scenario, already verified on the test run.

15. Reconcile integrity. Record counts for each entity, a spot check of 50 random records by hand, and a check of totals on open deals.

16. Do not switch off Bitrix24 right away. A month in read-only as a reference is cheap insurance.

After the migration

17. The first week is hypercare (active support immediately after launch). Daily collection of the team’s questions, quick fixes to fields and automations. This is exactly where the system either takes root or it does not.

18. After a month — a review. What of the migrated data is going unused? Which fields are managers asking for? The system has to live and change.

A migration is not “pour the data over” — it is the chance to rebuild the process without the ballast. The teams that understand this get a new system that works better than the old one from the very first week.

FAQ

Q1 Can I move the entire conversation and call history out of Bitrix24?

Q2 How long does a migration from Bitrix24 to Uspacy take?

Q3 What do I do with Bitrix24 business processes during a migration?

Q4 Does the sales team stop working during the migration?

Q5 Which Bitrix24 data is not worth moving?

Q6 Where do companies most often migrate from Bitrix24?

Q7 How much does a migration off Bitrix24 cost?

Q8 Can I migrate on my own using the standard export?

Not ready for a call?

Take the Bitrix24 migration checklist with you

18 steps that save your data: inventory, field mapping, the three classic loss points, day X. A 2-page PDF, print-friendly.

Need help with your CRM?

A free intro consultation. Tell us the task — we’ll show our approach.

Book a call → Telegram