RetailCRM to Bitrix24 Migration: Preserving Orders and Loyalty

When migrating from RetailCRM to Bitrix24, the main challenge is the different data model: RetailCRM centers on orders, while Bitrix24 centers on deals. Without careful mapping, you lose statuses, payment history, and customer data. We've seen projects where 30% of deals ended up in wrong stages due to incorrect status mapping, and loyalty history was completely lost. Our team has completed over 50 migrations in 6 years, and we know how to avoid these pitfalls. We use RetailCRM API v5 for extraction and Bitrix24 REST API for writing. For large volumes we parallelize requests with a 5 RPS throttle, processing up to 50,000 orders per day. Our automated pipeline makes migration three times faster than manual Excel export.

Why Proper Mapping Is Fundamental

RetailCRM stores statuses in a multi-level structure with groups, while Bitrix24 uses flat deal stages. Without mapping, "Cancelled" can become "Won" and "In Progress" becomes "Lost". We automatically map statuses via a StatusMapper that respects business logic: e.g., "Return" in RetailCRM becomes "Deal lost" with reason preserved. In one project, 30% of deals were lost because the "Delivered" status wasn't transferred — after implementing the mapper, losses were eliminated.

What Data We Migrate

RetailCRM centers on Orders as the primary entity, while Bitrix24 is deal-oriented:

• Order — line items, status, delivery, payment
• Customer — individual or company
• Product — catalog item
• Task — internal tasks
• Note — comments on orders and customers
• Segment — marketing segments
• Loyalty — points, levels, history

All these entities we map to corresponding Bitrix24 objects. For example, orders become deals, customers become contacts, and loyalty becomes custom contact fields or the bonus points module.

Migration Process: Step by Step

1. Data audit — export from RetailCRM, analyze structure and volume (1–3 days).
2. Mapping design — field correspondences, status and business process decisions.
3. Script development — PHP scripts using both APIs.
4. Test migration — on a staging environment, verify checksums.
5. Verification — compare totals: order counts per status, GMV.
6. Production go-live — transfer to live, user training.

Migrating Orders with Status Preservation

RetailCRM's multi-level status structure maps to Bitrix24 deal stages. Our StatusMapper automatically matches statuses using business rules: e.g., "Cancelled" in RetailCRM becomes "Deal lost". Status change history is migrated to deal timeline events.

Handling the Loyalty Program

Loyalty data (points, levels, accrual history) goes to custom contact fields or the Bitrix24 bonus points module. We write a PHP script that recalculates balances as of migration time and loads operation history. If RetailCRM uses points expiry, we configure Bitrix24 agents for automatic write-offs.

Order Mapping Example

Mapping depends on whether the company uses a Bitrix online store:

• With store: orders may already be synced — we migrate only customers and history.
• Without store: orders become deals, customers become contacts and companies.

Typical Timelines and ROI

Investment in migration pays back in 3–6 months through automation of routine operations. Cost is determined individually at the audit stage. Our certified specialists guarantee accurate mapping and data integrity.

What's Included in the Work

• Data audit — RetailCRM structure export, duplicate and anomaly analysis.
• Mapping design — detailed field correspondence scheme considering business processes.
• Script development — PHP scripts with API usage, custom logic possible.
• Test migration — on a staging environment, with checksum verification.
• User training — webinar or in-person session for new data usage.
• Documentation and source code — handed over to client.
• Post-migration support — 2 weeks of monitoring and bug fixes.

How to Avoid Migration Pitfalls

Use a test environment. Our engineers clone Bitrix24, rehearse scenarios there. Only after client approval do we transfer to production. We also write backward-compatible rollback scripts. We guarantee data integrity and 54-FZ compliance for fiscal data transfer. All source code and documentation are handed over.

Contact us for a preliminary audit — we will assess the volume and complexity for free. Get a consultation from a certified specialist.

Why URL Structure Matters in Bitrix Migration?

Skipping URL mapping during a website migration to Bitrix crashes organic traffic by 50–80% in two weeks. WordPress uses /product/item-name/, OpenCart uses /index.php?route=product/product&product_id=123, Bitrix defaults to /catalog/section/element/. Without a 301 redirect map, search engines index mass 404s. We start every migration with Screaming Frog scanning the old site, then compile a complete redirect map before writing a single line of code. Proper migration requires full URL mapping — every indexed page gets a correspondent.

Over seven years we have completed 50+ projects: landing pages, catalogs with 300,000 products, e‑commerce stores. Typical duration 2–8 weeks. Contact us for a free project estimate within one day.

How Migration Preserves SEO Positions

Losing organic traffic is the biggest fear, and it's justified. Here is how we avoid it.

• URL mapping 1:1 — where possible, via CUrlRewriter and infoblock SEF settings we keep the exact structure. When impossible — 301 redirect. Auto‑generation of redirect map: parse Screaming Frog export, match with new element slugs, generate nginx config. Each redirect verified with curl -I after switching.
• Transfer of meta tags — title, description, h1 moved into properties ELEMENT_META_TITLE and ELEMENT_META_DESCRIPTION. Canonical via Bitrix SEO component. Duplicates cut: www/non‑www, http/https, sorting parameters. Sitemap: new sitemap.xml generated by Bitrix seo module, submitted to Search Console immediately after DNS switch.
• Speed comparison — Bitrix processes a catalog of 100,000 products 3x faster than OpenCart due to tagged caching and query optimization for b_catalog_product.

What Data Gets Transferred?

Content — pages, articles, news → information infoblocks. Catalog: categories → sections, products → elements linked to b_catalog_product, properties → infoblock properties or highload directories. Images, reviews, FAQ.

E‑commerce — products with trade offers (SKUs), prices in b_catalog_price (multi‑currency via b_catalog_currency), stock balances b_catalog_store_product, discounts (b_sale_discount), order history (b_sale_order + b_sale_basket).

Users — client base b_user plus custom UF fields. Passwords are hashed differently: WordPress — phpass, OpenCart — SHA1+salt, Drupal — SHA512. We write a custom CUser::LoginByHash with fallback to old algorithm — client enters password once, system rehashes to Bitrix bcrypt.

SEO data — meta tags, alt attributes, URL structure. Main task: preserve every indexed URL or set 301.

Media — images, documents, videos — transferred preserving paths and optimized via CFile::MakeFileArray().

How to Plan a Successful Migration: 5 Key Steps

1. Audit — scan with Screaming Frog: all URLs, status codes, meta tags. Analyze DB structure, custom modifications, integrations. Create migration map.
2. Architecture design — map content types → infoblocks, fields → properties, directories → highload blocks. Architecture must be convenient for Bitrix administration.
3. Migration scripts — PHP scripts read from old DB (or API), transform and write via Bitrix API (CIBlockElement::Add, \Bitrix\Sale\Order::create). Re‑run during testing.
4. Staging — full migration to test server. Verify integrity: product count, properties, URLs, filters.
5. Final migration & switching — delta import, DNS switch, monitoring.

Typical Migration Mistakes and How to Avoid Them

Each of these errors has caused loss of positions and clients.

• Loss of URLs without redirects — the most destructive mistake. /product/123 instead of /catalog/item-name.html — without 301 this means mass 404s and traffic collapse. We auto‑generate the map and verify every redirect after switching.
• Content duplication — one product accessible with and without www, via HTTP and HTTPS, with GET filter parameters → five URLs instead of one. SEO weight dilutes. Set up canonical, 301 for variants, robots.txt with Disallow for parameters.
• Broken images — absolute URLs in content (src="https://old-site.ru/img/photo.jpg"), quality loss during compression. Replace with relative paths, transfer preserving structure, check HTTP 200 for each file.
• Loss of meta tags and microdata — title, description, Schema.org may not transfer. Do full mapping and verify on staging.
• Broken forms and integrations — changed IDs, API keys, webhooks. Compile integration register before start and test each after.
• Mobile version — old m.site.ru → responsive Bitrix. Without mobile URL redirect → 404 for mobile users. Include in redirect map.

Timelines and Cost Savings

Businesses typically save $3,000–$8,000 annually after migration — no old CMS license fees, reduced plugin and hosting costs. Annual hosting savings alone can reach $1,200. Add the affordable licensing cost of 1C‑Bitrix — it pays off quickly.

Contact us for a free migration estimate. We also provide a preliminary calculation within one day — request a consultation with our Bitrix specialists.