Migration Bitrix24 → Kommo: 121,419 deals

A Bitrix24-to-Kommo migration is the transfer of every deal, contact, file and customer-interaction record from Bitrix24 CRM into Kommo CRM while preserving each deal’s original creation date, comment timeline, call recordings and assigned sales rep. Unlike a spreadsheet import, a purpose-built migration tool keeps the full chronology of work with each customer and carries data that simply cannot travel through Excel: call recordings, open tasks, and the original relationships between deals, contacts and companies.

This case is straightforward to summarize and unusual to deliver. A major manufacturer with 121,419 deals on Bitrix24 decided to move the whole operation to Kommo. The brief sounded simple: do it without breaking anything. The customer’s real concern, the one every operator shares the moment they think about switching CRMs, was less about features and more about memory — would the new system remember what happened in the old one, or would the team open Kommo on day one and stare at a flat database with today’s date stamped on every deal?

What does every team fear when switching from Bitrix24 to Kommo?

When a director decides to change CRMs, what stops them rarely has to do with price or with team resistance. The killer question is always: «what about the history?» Years of agreements, measurements, quotes, recorded calls and uploaded files are sitting inside the old system. If a migration mashes all of that into one undated heap, the company is effectively starting fresh — and for a business with long sales cycles, this is a direct revenue loss. A sales rep opens a deal and cannot reconstruct what was discussed with the client six months ago. That uncertainty alone keeps companies on the wrong CRM for years.

Our customer was in exactly this situation. Manufacturing windows is a measurement-and-revisit business: site visits, calculations, sign-offs, claims, repeat orders. Each deal carried somewhere between one and five attached documents — contracts, measurement sheets, photos of the installation site. Phone is the primary sales channel, and the recordings of disputed conversations are worth more than any written note when a complaint comes in.

The target system was Kommo — the international version of amoCRM, the same product with global billing and a worldwide footprint. Companies leaving local CRM ecosystems land here often enough that we hear the question «how do we move from Bitrix24 without losing anything?» almost every week.

The shape of the database on day one of the project:

• 121,419 deals to move — the live pipeline plus several years of closed-won archive;
• one client per deal, with phone numbers and emails;
• one to five files per deal, around 30 GB in total;
• every recorded call, including missed ones;
• 16 custom deal fields that do not exist out-of-the-box in Kommo — created and populated as part of the migration.

Why doesn’t an Excel import work for large databases?

The default advice you will find in most migration guides is: export to a spreadsheet, import into the new CRM. For a small database this works. For a serious one, it quietly destroys everything that mattered:

• Dates collapse. Every deal inherits the date of the import file. A deal from 2021 and a deal from last week look identical — «created today». Year-over-year reports, sales-rep velocity, customer tenure: all reset to zero.
• Calls vanish. Recorded conversations cannot travel through a spreadsheet at all.
• Files stay behind. Contracts and measurements either get left in the old system or, in the «best» case, become links that will die the moment the old subscription lapses.
• Open tasks disappear. «Call back Tuesday» and «send updated quote» — the operational layer of the pipeline — is gone, and a slice of customers simply falls out of the workflow.
• Customers duplicate. If one client appears across three deals, the spreadsheet creates three customer records. At 121,419 deals you end up with tens of thousands of clones.

So we built our own tool. It speaks directly to both systems through their programmatic interfaces (their APIs), pulls a deal out of Bitrix24 with all its attached substance, and reconstructs it in Kommo one to one.

What does it actually mean to migrate deals with full history?

This is the part the whole project was about. «Migrate with history preserved» is the phrase every vendor uses. Here is what it actually means when we say it — line by line:

• Deal creation date in Kommo is the original one from Bitrix24. A deal from March 2022 reads «March 2022» in Kommo. The last-modified date follows the same rule.
• Comments and notes travel with their original date and time. Open a deal, see the timeline in the order events actually happened.
• Phone calls appear as proper calls inside the deal card: inbound or outbound, duration, and — the part that surprises people — the recording itself plays directly in the card. We carried over missed calls too, which the quality department treats as first-class data.
• Open tasks arrive with their text, deadline and assignee intact. Monday morning a sales rep sees the same tasks they saw on Friday afternoon in the old system.
• Owners. Every deal, task and call is attached to the same person who owned it before — we matched the two account directories by work email.
• No duplicate customers. Before moving any deal, the tool checks each contact against the Kommo address book — by phone and email, with several phone-number formats normalized to one shape. One person, one record, no matter how many deals they appear in.
• 16 custom deal fields — object type, region, area, source and the rest — were created in Kommo and filled in for every deal. Drop-down list fields too: we mapped the options across the two systems automatically.

Two small details the sales reps appreciated. First, every migrated deal carries a marker tag — one filter inside Kommo separates «moved from the old system» from «born here». Second, the migration walks newest-to-oldest, so the team can start working in the new CRM on the same day the run starts: fresh deals arrive first, the multi-year archive streams in behind them.

What cannot be migrated between Bitrix24 and Kommo?

We write this section into every case study, and it is always short. If a vendor promises «we move 100% of everything», they are either guessing or shading the truth. Between any two CRM systems there is always data that cannot travel — not because the vendor is lazy, but because the target system refuses to accept it from any external tool.

In this project there is exactly one such thing: the stage-transition log of each deal. That is the record that reads «on March 3 the deal entered stage Measurement; on March 12 it moved to Quote; on March 18 it landed in Contract Signed». Bitrix24 holds that history. Kommo will not let any external tool write those events with their original timestamps — that is a deliberate restriction on its side.

What this means in practice for the team:

• Each deal arrives in Kommo directly at its current stage — wherever it stood in Bitrix24 the moment we read it.
• «How many days did deals spend at stage Quote, on average» as a Kommo report cannot be reconstructed for the pre-migration period. That kind of analysis has to be built either from a Bitrix24 export of past data, or counted forward from the cutover.
• The substance — who agreed to what, and when — is fully there, because it lives inside the notes and the calls with their original dates. Open a deal and the timeline reads in the order events actually happened.

That is the entire honest minus. If pre-migration stage-velocity reports are central to your operation, plan for it now rather than discover it later.

How do you move 30 GB of files from Bitrix24 into Kommo?

The cheap way to migrate files is to leave them in the old system and write a link into the new one. That looks like a solution right up until the old CRM subscription gets cancelled — at which point every link dies in unison. A year from now a sales rep opens a deal, clicks «contract_final.pdf» and gets an error page. In our experience, 12–18 months after a link-based migration, 100% of attachments become unreachable, and there is no way to recover them — the source data has been physically removed from the old system.

We moved the files for real. Each document downloads from Bitrix24 and uploads into Kommo’s own storage, into the right deal card. Contracts, measurement sheets, site photos, signed acceptance reports — everything sits inside the new system and stops depending on the old one. Large files (heavy scans and photo packs) are streamed in chunks so the run doesn’t stall on a single big attachment. File type is detected automatically and preserved in the correct format.

Total volume in this project: about 30 gigabytes — on average 1–5 files per deal, ranging from 50 KB (single photo) to 80 MB (full measurement pack with photo report). Not a single file remained a link back to Bitrix24 — everything physically moved into Kommo storage and will continue to open even after the Bitrix24 subscription is fully terminated.

How did we push the migration to 181 deals per minute?

Moving one deal with its full history is engineering-trivial. Moving 121,419 of them is an engineering problem, because both systems cap how fast external tools may talk to them: Bitrix24 and Kommo each allow only so many requests per second. Exceed the cap and you queue. This is a reasonable defence; for a migration it means you cannot just «pour faster» — you have to spend fewer requests per deal. Below are the five rounds of optimization we went through.

Round 1: what did we start with?

The first version moved deals one at a time, sequentially. We projected the whole job out — weeks. For a live business that needs to be in Kommo now, that is a death sentence. Time to accelerate.

Round 2: what does parallelism give us?

Five concurrent workers, five deals moving at once. Speed went up and immediately hit the next ceiling: Kommo’s rate limit. Workers spent half their time queued. The next gain had to come from making each deal cheaper, not from running more of them.

Round 3: which requests can we drop entirely?

We profiled what the requests were actually for. About half of them were the same question repeated for every deal: «does this customer already exist in Kommo?». The fix: before the migration starts, pull the entire Kommo address book into the tool’s memory once and check locally from then on. Traffic dropped by half. Speed went up.

Round 4: why ship in crates?

Next bottleneck: each deal was still firing a dozen tiny requests — one per comment, one per task. We rewrote that part to batch up to 50 notes and 50 tasks per request. Per-deal load fell about five times. With that headroom we pushed workers from five to eight.

Round 5: how do we speed up the source?

Now Kommo was no longer the bottleneck — Bitrix24 was, on the read side. The same trick applied in reverse: Bitrix24 will pack up to 50 sub-requests into one batch call. We did that, plus added automatic retries on transient network blips so a flaky connection didn’t kill the run.

Result: 181 deals per minute

After tuning and a clean restart the tool cruises at 181 deals per minute — every deal arriving with its comments, calls, tasks and files. The actual end-to-end result: all 121,419 deals moved in roughly 19–20 hours of total run time — including several deliberate restarts after each speed-up. Inside the promised day, with margin.

What happens if the migration is interrupted mid-run?

The second fear after «we’ll lose history» is «what if the migration breaks at hour 18?». A day of work, a network hiccup at 70% completion, and is the whole thing a wash? And won’t we end up with duplicate deals?

The tool’s design answers both:

• Per-deal memory. A local journal records: «this Bitrix24 deal became this Kommo deal». On any re-run, already-moved deals are skipped or carefully updated — never re-created.
• Auto-resume. If the migration server reboots, the tool finds the unfinished run on startup and continues from the same place without human intervention.
• Newest first. The run walks recent deals before historical ones. The team starts working in Kommo within hours, while the multi-year archive streams in behind the scenes.
• Live dashboard. Throughout the run: deals done, deals remaining, current speed, estimated finish time. No «wait, is it doing anything?» moments.

We restarted the run several times during this project — deliberately, after each speed-up. Zero duplicates in Kommo at the other end.

The final numbers

Below is the summary of every measurable indicator from the completed project. Each row is a concrete technical fact we can verify against migration logs and the resulting state of both systems — not a marketing approximation.

For context against typical market expectations: 121,419 deals is roughly 40–80× larger than the average CRM-to-CRM migration vendors describe (1,500–3,000 deals); the 181-deals-per-minute pace is about 30× faster than a typical CSV import; and 30 GB of files placed inside Kommo storage — rather than left as broken links — is a full-data migration standard most projects do not even attempt.

The migration is complete — the numbers above are final. The 110 deals (under 0.1%) that landed in the error log were resolved by hand.

How do you plan your own Bitrix24-to-Kommo migration?

If you are considering a move from Bitrix24 (or any legacy CRM) to Kommo, here is the order of operations we recommend:

1. Measure what you have. Deal count, file count and size, whether calls are recorded. This drives both Kommo plan choice (storage quotas) and migration duration.
2. Decide what to leave behind. Our customer chose not to migrate the lost-deals archive — it cut both volume and cost. Won and active deals always come along.
3. Audit your fields. Custom fields that haven’t been filled in for two years probably shouldn’t cross over either.
4. Map your people. Every sales rep needs a Kommo account with the same work email — otherwise there is no one to assign the deals to.
5. Insist on dates and calls. The litmus test for any vendor: «what creation date will a 2022 deal have after the move?» If the answer is «the import date», history is gone.
6. Start with a pilot batch. A handful of deals move first; sales reps inspect them by hand; only then does the full run start.
7. Do not turn the old system off immediately. Keep Bitrix24 in read-only mode for a month as a safety net while the team verifies everything is on the new side.