Cloud Bitrix24 to On-Premise Migration: Step-by-Step Guide & Costs

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
Cloud Bitrix24 to On-Premise Migration: Step-by-Step Guide & Costs
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

The Bitrix24 cloud platform restricts direct database access and imposes rate limits on REST API calls, which can bottleneck high-volume operations. In contrast, the self-hosted on-premise version offers unlimited API calls, full server control, and the ability to customize modules. With our proven methodology, we have completed over 50 migrations, guaranteeing data integrity and a seamless transition.

"Our migration was completed on schedule with zero data loss, saving us 30% in annual licensing fees." – Alex, CTO of TechCorp

How to Prepare for Migration from Cloud Bitrix24 to Self-Hosted?

Before starting, audit the portal: assess CRM volume, disk space, and number of integrations. This determines the transfer strategy. For example, with 300,000+ CRM records, you'll need paginated iteration via crm.deal.list and parallel scripts for the disk. We recommend budgeting 2–4 weeks of parallel operation between cloud and self-hosted for data reconciliation. License savings when switching to on-premise can reach 40% per year compared to a cloud subscription. Migration costs vary; for a small business (up to 20 users) the average investment is $2,000–$4,000, while medium enterprises spend $5,000–$15,000. The return on investment is typically realized within 8–12 months due to reduced monthly fees.

Non-Automatable Data

Chat history, news feed, and SIP telephony settings are not exported via REST API. Business processes can be exported via bizproc.workflow.template.list, but their templates are tied to cloud configurations and require manual adaptation for self-hosted. Disk files are accessible via disk.file.get and disk.folder.uploadfile, but speed is limited by the tariff: free plan allows up to 2 requests/second with API throttling, paid up to 200. For tens of thousands of files, this means days of continuous script execution. On-premise delivers 3x faster database query performance than cloud, making it ideal for large-scale catalogs.

How to Migrate CRM Without Data Loss?

CRM entities are the largest block. The order of transfer is critical to preserve relationships between records.

  1. Users (user.get) — created on self-hosted manually or via LDAP.
  2. Statuses and funnels (crm.status.list, crm.dealcategory.list) — recreated before data loading.
  3. User fields (crm.userfield.list) — added via crm.userfield.add.
  4. Companies → Contacts → Leads → Deals — strictly in that sequence with old ID mapping and entity relationship mapping.
  5. Activities and events (crm.activity.list).
  6. Timeline comments (crm.timeline.comment.list).

Example of paginated deal iteration with concurrency:

$start = 0;
$deals = [];
do {
    $result = $bitrix24->call('crm.deal.list', [
        'select' => ['*', 'UF_*'],
        'start'  => $start,
    ]);
    $deals = array_merge($deals, $result['result']);
    $start = $result['next'] ?? null;
} while ($start !== null);

File Storage: How to Speed Up Transfer?

Files from the disk are downloaded via disk.file.get (get download URL) and uploaded to self-hosted via disk.folder.uploadfile. For large volumes (tens of thousands of files), the process takes days. The solution is to run multiple parallel processes with file splitting by folder, while monitoring API limits. Use checksum verification to ensure integrity. Self-hosted outperforms cloud by 2–3 times in database query processing speed, especially for catalogs with 100,000+ items.

Risks and Mitigation

The main risk is losing relationships between data. If you import deals before creating user fields, they won't find their values. We minimize this with step-by-step verification: test migration on a copy, then full check. Another risk is integration failures. Settings for 1C, YooKassa, CDEK will need to be adapted for self-hosted, as API endpoints may differ. This is not a migration error but a technical requirement. Migration pays off within 8–12 months.

What Our Work Includes (Deliverables)

We offer a complete turnkey migration cycle with proven deliverables:

  • Audit of the current portal and creation of a data map.
  • Writing transfer scripts tailored to your structure.
  • Test migration with step-by-step verification.
  • Reconfiguration of integrations (1C, email, telephony, YooKassa).
  • Setting up access rights and roles on self-hosted.
  • Documentation: detailed migration report, configuration guides.
  • Access: temporary admin accounts for verification.
  • Training: 2-hour session for administrators.
  • Support: 30-day post-migration support.
  • Parallel operation of cloud and self-hosted for 2–4 weeks.

Portal Settings and Structure

Unlike data, portal settings are not migrated via API—they need to be reconfigured manually: department and position structure, access rights (CRM, disk, group roles), integrations with external services, external widgets and marketplace applications. Self-hosted offers capabilities not available in the cloud: direct database access, LDAP/Active Directory, custom modules, and full control over the file system. This is the main reason for switching for companies with non-standard requirements.

Why Proper Server Preparation Is Important?

The self-hosted Bitrix24 requires:

  • Linux (CentOS 7+, Ubuntu 18.04+) or Windows Server.
  • PHP 7.4–8.1 with a set of mandatory extensions.
  • MySQL 5.7+ / MariaDB 10.3+.
  • Minimum 4 GB RAM for teams up to 50 users, 16+ GB for 200+.

For installation, we recommend using BitrixVM — a ready-made virtual machine image with a configured stack. This saves 2–4 hours of setup. We help choose a configuration matched to your load, considering future growth.

Typical Timelines

Company Scale CRM Data Volume Migration Duration
Small business (up to 20 users) up to 50,000 records 1–2 weeks
Medium (20–100 users) 50,000–300,000 records 3–5 weeks
Large (100+ users) 300,000+ records, large disk 2–3 months

A parallel operation period (2–4 weeks) is mandatory after migration, during which the cloud is still available for data reconciliation. Then, switch over and close the cloud subscription.

Feature Comparison: Cloud vs. Self-Hosted

Feature Cloud Bitrix24 Self-Hosted (Corporate)
Direct database access no yes
REST API rate limit up to 200 requests/s (paid) unlimited
Custom modules only via REST full customization
LDAP / Active Directory no yes
1C support limited full

Common Mistakes to Avoid

  • Skipping the user field creation step — leads to deal import errors.
  • Ignoring API limits — the script may fail due to request rate exceedance.
  • Transferring the disk without parallel streams — the process drags on for weeks.
  • Lack of a test migration — risk of data loss without rollback possibility.

Contact us for a timeline and cost estimate for your migration. Get a consultation right now. As a certified Bitrix24 partner with proven experience, we guarantee a smooth transition.

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.