Data Migration from amoCRM to Bitrix24: Complete Guide

Our company is engaged in the development, support and maintenance of Bitrix and Bitrix24 solutions of any complexity. From simple one-page sites to complex online stores, CRM systems with 1C and telephony integration. The experience of developers is confirmed by certificates from the vendor.
Showing 1 of 1All 1626 services
Data Migration from amoCRM to Bitrix24: Complete Guide
Medium
~1-2 weeks
Frequently Asked Questions

Our competencies:

Development stages

Latest works

  • image_website-b2b-advance_0.webp
    B2B ADVANCE company website development
    1356
  • image_bitrix-bitrix-24-1c_fixper_448_0.webp
    Website development for FIXPER company
    943
  • image_bitrix-bitrix-24-1c_development_of_an_online_appointment_booking_widget_for_a_medical_center_594_0.webp
    Development based on Bitrix, Bitrix24, 1C for the company Development of an Online Appointment Booking Widget for a Medical Center
    693
  • image_bitrix-bitrix-24-1c_mirsanbel_458_0.webp
    Development based on 1C Enterprise for MIRSANBEL
    828
  • image_crm_dolbimby_434_0.webp
    Website development on CRM Bitrix24 for DOLBIMBY
    731
  • image_crm_technotorgcomplex_453_0.webp
    Development based on Bitrix24 for the company TECHNOTORGKOMPLEKS
    1073

Data Migration from amoCRM to Bitrix24: Complete Guide

We have been migrating CRM systems for over 5 years and have completed more than 50 projects transferring data from amoCRM to Bitrix24. This process requires deep understanding of both platforms: without a sound strategy, you risk losing deal history or creating duplicates. In this article, we’ll cover the technical nuances and show how we ensure data integrity.

amoCRM and Bitrix24 are close competitors on the Russian market, but their data models differ significantly. amoCRM is built around deals (pipeline-centric model), while Bitrix24 is a more complex system with separate leads, deals, contacts, and companies. This difference defines the entire migration strategy.

Key Differences Between the Models

Aspect amoCRM Bitrix24
Central entity Deal (lead) Lead → Contact + Deal
Contacts Attached to deals Independent entity
Companies Attached to deals Independent entity
Tags On deals and contacts UF fields or categories
Pipelines Multiple, with stages Pipelines (directions) with statuses
Custom fields Simple setup UF fields with types

In amoCRM, a "deal" (lead) is both a lead and a deal simultaneously. During migration, you must decide: transfer everything into Bitrix24 deals, or split into leads + converted deals. We recommend the second option, as it opens access to business processes and pipelines of Bitrix24.

Why Proper Migration Matters

Errors during the mapping phase lead to lost deals and dissatisfied clients. Poorly transferred custom fields can break reports. Unpreserved call history deprives managers of context. We guarantee that after migration, all data is available and correct. Request a preliminary project assessment — it’s free of charge.

How We Extract Data from amoCRM

amoCRM provides REST API v4. Authentication via OAuth 2.0. API limits: no more than 7 requests per second — when exporting a large database, a delay between requests is mandatory.

Client for paginated contact export (250 records per request):

class AmoCrmClient {
    public function getContacts(int $page = 1): array {
        $url = "https://{$this->domain}.amocrm.ru/api/v4/contacts"
            . "?page={$page}&limit=250&with=leads,companies";
        $http = new \Bitrix\Main\Web\HttpClient();
        $http->setHeader('Authorization', 'Bearer ' . $this->accessToken);
        return json_decode($http->get($url)->getResult(), true);
    }
}

Mapping Pipelines and Statuses

Pipelines in amoCRM map to directions (pipelines) in Bitrix24. They are created in advance via crm.category.add, then for each pipeline, statuses are created via crm.status.add.

Mapping is saved in a file or table for use when transferring deals:

$pipelineMapping[$pipeline['id']] = $b24CategoryId;
$statusMapping[$status['id']] = 'STAGE_' . $status['id'];

How Custom Fields Are Created in Bitrix24?

In amoCRM, custom fields are created arbitrarily. Before migration, we create corresponding UF fields in Bitrix24 via crm.deal.userfield.add. The field type is determined by the field_type from the amoCRM API:

  • TEXT → string
  • NUMERIC → integer
  • DATE → date
  • MULTISELECT → list (enumeration)

Transferring Contacts

Each amoCRM contact becomes a contact in Bitrix24. Phone numbers and emails are stored in PHONE and EMAIL fields with codes WORK and HOME. Creation date is transferred via the DATE_CREATE field.

After creating a contact, we save the mapping contact_id (amo) → contact_id (B24) for linking deals.

Transferring Deals with Notes

Deals are the core of migration. Each amoCRM deal is transferred to Bitrix24 via crm.deal.add with links to contacts and companies based on the mapping. We preserve the original ID in a user field UF_CRM_AMO_ID for verification and debugging.

Notes from amoCRM are transferred as timeline comments via crm.timeline.comment.add. This preserves the negotiation history, visible to the manager in the deal card.

Tasks and Calls

Tasks from amoCRM are transferred via crm.activity.add with type=2. Call recordings (if telephony is connected) are transferred via crm.activity.add with type=4 (CALL). This is valuable historical information for resuming work with the client.

How to Avoid Duplicates on Re-Run?

During re-runs of the migration script (due to errors or restarts), we check: do not create a record if UF_CRM_AMO_ID already exists in Bitrix24.

$existing = $b24->call('crm.deal.list', [
    'filter' => ['UF_CRM_AMO_ID' => $amoLead['id']],
    'select' => ['ID'],
]);

if (!empty($existing['result'])) {
    continue; // Already transferred
}

Validation Results

Metric Verification Method
Number of contacts amoCRM count vs B24 crm.contact.list
Number of deals Comparison by pipelines
Custom fields Spot-check 50 records
Notes Chronology for 10-15 deals

What’s Included in the Work?

  • Technical documentation: mapping schema, transfer logs, admin instructions.
  • Team training: 2 webinars on working in Bitrix24, Q&A in chat.
  • Test run: migration of a database copy for verification.
  • Warranty: 2 weeks of free support after transfer — we fix any issues that arise.

Timelines

Data Volume Timeline
Up to 3,000 contacts and deals 1-2 weeks
3,000-20,000 records + custom fields 3-5 weeks
20,000+ records + call and task history 2-3 months

Switching from amoCRM to Bitrix24 is a change in the team’s work paradigm. Alongside data migration, training on new business processes is required — a task no less important than the technical transfer. Bitrix24 offers a more flexible system: according to Wikipedia, modern CRM can increase sales by 29%. With our experience, you will get the maximum from the new platform.

Get a consultation for your project — we will assess the scope and propose an optimal migration plan. Contact us: send an email or leave a request on our website.

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.
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.