Migrate On-Premise Bitrix24 to Cloud: Portal and CRM Migration Guide

You want to move away from managing your own server, shrink IT infrastructure, and use cloud capabilities that aren't available in the on-premise version. Switching from On-Premise to the cloud has a fundamental constraint: Bitrix24 does not provide an official import tool from the boxed version. Data transfer is only possible via REST API — in the opposite direction compared to migrating from the cloud to the box. Over 5 years, we have completed more than 30 such projects and know all the pitfalls.

Cloud Bitrix24 offers built-in features not available in the on-premise version: WebRTC telephony, full-featured mobile app, automatic updates. This offloads the IT department and reduces server hardware costs by 40-60%. For example, for a company with 50 employees, savings on server equipment and administration can reach €5,000 per year. Our certified Bitrix24 partners guarantee a smooth migration with zero downtime.

Data Available for Transfer

Not everything in the on-premise version is available in the cloud. Key differences to check before deciding:

Why Custom Modules Are the Main Problem

If your on-premise has custom PHP modules or components, they need to be rewritten as REST applications in the cloud. This is the main challenge: such rework can outweigh the migration cost itself. During the audit phase, we evaluate each module and provide a conclusion.

CRM Data Migration Process

Data is exported from the on-premise via REST API (it works the same in both versions) and loaded into the cloud via the same REST API. Sequence:

1. Create an OAuth application in the cloud portal for request authentication.
2. Migrate users — invite manually via the interface or use user.add (only in On-Premise; cloud API restricts adding users).
3. Recreate directories: deal statuses (crm.status.add), funnels (crm.dealcategory.add), user fields (crm.userfield.add).
4. Migrate CRM data: companies → contacts → leads → deals with ID mapping preserved.
5. Migrate Disk files via disk.folder.uploadfile.

The migration script works with two API clients simultaneously: one connected to the on-premise (source), the other to the cloud (receiver).

Official Bitrix24 documentation Bitrix24 REST API documentation limits request frequency to the cloud API more strictly than to the on-premise API. On the 'Team' tariff — 2 requests per second, on 'Company' — up to 200. For large volumes, we implement rate limiting:

class RateLimiter
{
    private float $lastRequest = 0;
    private float $minInterval;  // seconds between requests

    public function wait(): void
    {
        $elapsed = microtime(true) - $this->lastRequest;
        if ($elapsed < $this->minInterval) {
            usleep((int)(($this->minInterval - $elapsed) * 1_000_000));
        }
        $this->lastRequest = microtime(true);
    }
}

What Are API Limits and How to Work Around Them?

API limits are a key factor in planning. According to Bitrix24 REST API documentation, limits are lower for cloud tariffs. The RateLimiter above is a standard solution. In practice, we use a configurable interval and job queue to stay within limits. For example, the 'Company' tariff is up to 100 times faster than the 'Team' tariff for data transfer.

Cloud Bitrix24 reduces total cost of ownership (TCO) by 2–3 times compared to the on-premise version by eliminating server hardware and its administration. This means savings of €5,000–€20,000 per year depending on company size.

What's Included in the Work?

• Audit of the current configuration: inventory of modules, user fields, business processes.
• Agreement on the migration plan: which data to transfer, what to rewrite.
• Development of transfer scripts: with rate limiting and ID mapping.
• Test run: on a copy of data, integrity check.
• Parallel operation: 2–4 weeks of co-use of on-premise and cloud.
• Employee training: working with the new interface and REST applications.
• Post-migration support: 2 weeks after switchover.

Checklist before migration:

• Check which PHP modules are used — they won't transfer.
• Determine the cloud tariff: it affects API limits.
• Assign a person responsible for user ID mapping.
• Create an OAuth application in the cloud portal.
• Prepare the environment for parallel operation.

Parallel Operation Period

The recommended parallel operation period is 2–4 weeks. During this time, new data is entered into the cloud, while the old on-premise remains read-only for verification. After the period, deactivate the on-premise and free the server. This eliminates portal downtime and allows data integrity verification.

Typical Timelines

Migration cost varies depending on data volume and customization complexity. Request an audit of your portal — we will determine the exact budget and migration timeline. Contact us for a consultation. With over 5 years of experience and certified experts, we guarantee a seamless 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.

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.