When migrating from RetailCRM to Bitrix24, the main difficulty is the different data model: RetailCRM is centered on orders, while Bitrix24 is centered on deals. Without careful mapping, statuses, payment history, and customer data are lost.
We have encountered projects where, due to incorrect status mapping, 30% of deals ended up in the wrong stages, and loyalty history was lost. Our team has performed more than 50 migrations over 6 years, and we know how to avoid these pitfalls.
We use RetailCRM API v5 for export and Bitrix24 REST API for writing. For large volumes, we parallelize requests with a limit of 5 RPS, which allows processing up to 50,000 orders per day. Migration through our automated pipeline is 3 times faster than manual transfer via Excel.
Why is correct mapping the foundation of migration from RetailCRM to Bitrix24?
RetailCRM stores statuses in a multi-level structure with groups, while Bitrix24 uses flat deal stages.
Without mapping, "Canceled" can become "Success," and "In Progress" can become "Lost." We automatically match statuses via StatusMapper, which takes business logic into account: for example, "Return" in RetailCRM maps to "Deal cancellation" while preserving the reason.
On one project, a client lost 30% of deals because the "Delivered" status was not transferred — after implementing the mapper, losses were eliminated.
What data do we transfer?
RetailCRM is built around orders (Orders) as the central entity, which distinguishes it from classic CRMs like Bitrix24 that are oriented toward deals:
- Order — order with items, status, delivery, payment
- Customer — buyer (individual or company)
- Product — product (from the store catalog)
- Task — tasks (built into the interface)
- Note — comments on orders and customers
- Segment — customer segments (marketing)
- Loyalty — loyalty program (points, levels)
We transfer all these entities into the corresponding Bitrix24 objects. For example, orders become deals, customers become contacts, and the loyalty program becomes custom contact fields or a bonus points module.
How is the migration structured: step-by-step process
- Data audit — export from RetailCRM, analysis of structure and volume (this stage takes 1–3 days).
- Mapping design — which fields correspond to which, solution for statuses and business processes.
- Migration script development — in PHP using RetailCRM API v5 and Bitrix24 REST API.
- Testing on a copy — transferring data to a test environment, reconciling checksums.
- Verification — comparing summary metrics (number of orders by status, GMV).
- Launch in production — transfer to the production environment, employee training.
How to transfer orders while preserving statuses?
RetailCRM has a multi-level status system with groups. Corresponding deal stages are created in Bitrix24.
We automatically map statuses via StatusMapper, which takes business logic into account: for example, "Canceled" in RetailCRM can become "Deal lost." It is also important to preserve the status change history — we transfer it to the deal timeline events.
What to do with the loyalty program?
Loyalty data (points, levels, accrual history) is migrated via custom contact fields or the Bitrix24 bonus points module. We develop a PHP script that recalculates balances at the time of transfer and uploads the transaction history. If RetailCRM uses a points expiration system, we configure Bitrix24 agents for automatic deduction.
Order mapping: example
When integrating RetailCRM with Bitrix24, order mapping depends on whether the company has an online store on Bitrix.
If the store exists: orders may already be synchronized — we migrate only customers and history. If there is no store: orders are transferred as Deals, customers — as Contacts and Companies.
| RetailCRM | Bitrix24 (without store) | Bitrix24 (with store) |
|---|---|---|
| Customer | Contact / Company | Site user |
| Order | Deal | Order (b_sale_order) |
| Order Item | Deal item | Cart item |
| Task | Task | Task |
| Note | Timeline comment | Comment |
| Segment | User group | CRM segment |
Typical timelines and payback
| Volume | Timeline |
|---|---|
| up to 10,000 orders, up to 5,000 customers | 2–3 weeks |
| 10,000–100,000 orders | 4–8 weeks |
| 100,000+ orders, loyalty, segments | 2–4 months |
Investments in migration pay off within 3–6 months through automation of routine operations. Cost is calculated individually at the audit stage. Our certified specialists guarantee accurate mapping and data integrity.
What is included in the work
- Data audit — export of RetailCRM structure, analysis of duplicates and anomalies.
- Mapping design — detailed field correspondence scheme taking business processes into account.
- Script development — in PHP using APIs, with the ability to add custom logic.
- Test migration — on a copy of the environment, with verification of checksums.
- Employee training — webinar or in-person meeting on working with the new data.
- Documentation and source code — transferred to the customer.
- Post-migration support — 2 weeks of monitoring and bug fixing.
How to avoid mistakes during migration?
Use a test environment. Our engineers configure a Bitrix24 clone where they practice transfer scenarios. Only after customer confirmation is the data transferred to production. We also write backward compatibility scripts in case of rollback.
We guarantee data integrity and compliance with 54-FZ when transferring fiscal data. All source codes and documentation are transferred to the customer.
Contact us for a preliminary audit — we will assess the volume and complexity of the migration. Get a consultation with a certified specialist.