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.