Data Migration from Zoho CRM to Bitrix24
Once we had a client who, after a self-attempted migration, lost all relations between deals and contacts. Recovery took three weeks and required manual archival review. Switching from Zoho CRM to Bitrix24 isn't just copying records. Differences in architecture, API, and business logic often come as a surprise. We offer turnkey migration: from analysis to employee training. Our engineers are certified and have over 10 years of Bitrix24 experience, with more than 50 CRM migration projects completed.
Why Migration from Zoho to Bitrix24 Is Not Trivial
Zoho CRM uses its own role model and extended field types. For example, Subform and Formula have no direct counterpart in Bitrix24. Without proper mapping, you can lose relationships between records or face duplication.
Another challenge is the API. The Zoho CRM API limits 200 records per request, critical for catalogs of 100,000+ records. Slow export drags migration to weeks if pagination is not optimized. We use cursor pagination to bypass this limitation, speeding up the process threefold compared to standard approaches.
How We Migrate Data: Process and Technologies
Source Analysis and Mapping Design
The first step is auditing the current Zoho structure: modules, custom fields, relationships, data volume. We create a mapping map. Standard modules are migrated according to the table:
| Zoho Module |
Bitrix24 |
| Lead (unconverted) |
Lead |
| Contact |
Contact |
| Account |
Company |
| Deal |
Deal |
| Task |
Task |
| Event |
Activity type "Meeting" |
| Call |
Activity type "Call" |
| Note |
Comment |
Custom Zoho modules have no direct counterpart. We convert them into custom entities (On-Premise configuration) or emulate via smart processes and high-load blocks.
Development and Testing
We write scripts in PHP 8.1+ using Composer. For working with Bitrix24, we use REST API. A test migration on a data copy reveals errors before launch. At this stage, we handle custom fields: Formula is replaced by robots, Subform by separate CRM entities, Multi-select Lookup by multiple fields.
Example from practice: a client with a catalog of 150,000 products and 30 custom fields. A test migration revealed 12% duplicate records due to mismatched uniqueness fields. We rewrote the mapping, adding external_id from Zoho, and the retest showed 0% duplicates.
Launch and Support
After the final migration, we check the integrity of relationships, record counts, and business processes. We guarantee data integrity and provide a week of post-migration support. The result is a fully operational system with correct relationships.
What to Do with Custom Modules?
Custom Zoho modules (e.g., Training or Inventory) have no counterpart in Bitrix24. We emulate them via smart processes or high-load blocks. For role models, we configure permissions manually based on the client's documentation. There is no direct access rights migration.
How We Guarantee Data Integrity
We use a three-stage check: test migration on a copy, automatic comparison of record counts and fields, manual spot-check of key deals. To date, no project has led to data loss — that's our reputation.
What's Included in the Work
- Detailed migration plan with timeline
- Field mapping (standard and custom)
- Migration script development
- Test and final migration
- Employee training on Bitrix24
- Documentation on settings and processes
Typical Migration Timelines
| Volume |
Modules |
Timeframe |
| Up to 20,000 records, standard modules |
4 modules |
2–4 weeks |
| 20,000 – 100,000 records, custom fields |
6–10 modules |
4–8 weeks |
| 100,000+ records, custom modules, subforms |
10+ modules |
2–4 months |
Typical Mistakes and How to Avoid Them
-
Record duplication — due to mismatched uniqueness check fields. We use custom
external_id.
-
Relationship loss — if parent object references are not transferred. Relationship mapping is mandatory.
-
Zoho custom scripts not transferred — their business logic is recreated in Bitrix24 via robots or custom handlers.
Contact us for a project assessment. We'll prepare a precise plan and timeline. Get a consultation today — it's free.
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
-
Audit — scan with Screaming Frog: all URLs, status codes, meta tags. Analyze DB structure, custom modifications, integrations. Create migration map.
-
Architecture design — map content types → infoblocks, fields → properties, directories → highload blocks. Architecture must be convenient for Bitrix administration.
-
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.
-
Staging — full migration to test server. Verify integrity: product count, properties, URLs, filters.
-
Final migration & switching — delta import, DNS switch, monitoring.
Detailed stage timeline
| Stage |
Duration |
Activities |
| Audit |
1–3 days |
Full site scan, integration register |
| Architecture |
2–5 days |
Infoblock design, field mapping |
| Scripts |
3–10 days |
PHP based migration engine |
| Staging |
1–2 days |
Full dry run, integrity checks |
| 301 redirects |
1–2 days |
Map in .htaccess or nginx.conf |
| Final migration |
1 day |
Delta import, DNS switch |
| Post‑migration |
2–4 weeks |
Monitor Search Console, fix crawl errors |
| Deliverable |
Description |
| Documentation |
Redirect map, mapping description, DB schema |
| Access |
Admin panel, FTP/SSH, API keys |
| Training |
Video tutorials or on‑boarding session |
| Support |
2 weeks post‑migration monitoring, bug fixing |
| Guarantee |
Rollback to old site within 48 hours |
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
| Project type |
Timeline |
Notes |
| Informational site (up to 500 pages) |
2–4 weeks |
Content + design + redirects |
| E‑commerce store (up to 10,000 products) |
4–8 weeks |
Catalog + orders + integrations |
| Large store (100,000+ products) |
2–4 months |
Custom scripts + load testing |
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.