Migrating from On-Premise Bitrix24 to the Cloud

Migration from On-Premise Bitrix24 to Cloud

A company may need to move away from self-hosted infrastructure due to operational overhead, IT cost reduction, or to access cloud-exclusive features unavailable in the on-premise version. The reverse transition—from on-premise to cloud—has a fundamental limitation: Bitrix24 provides no official on-premise import tool. Data must be migrated through the API in the reverse direction.

What Can Be Migrated and What Cannot

Not everything available in on-premise is accessible in the cloud. Key differences to verify before deciding on the transition:

If the on-premise installation includes custom PHP modules or components, they must be rewritten as REST applications in the cloud. This represents significant work that can exceed the cost of migration itself.

CRM Data Migration Strategy

Data is exported from on-premise through REST API (which operates identically in both versions) and imported into the cloud using the same REST API. The sequence:

1. Create an OAuth application in the cloud portal for request authentication
2. Transfer users—invite manually through the interface or use user.add (on-premise only; cloud user addition via API is restricted)
3. Recreate directories: deal statuses (crm.status.add), sales pipelines (crm.dealcategory.add), custom fields (crm.userfield.add)
4. Transfer CRM data: companies → contacts → leads → deals with ID mapping preserved
5. Transfer files from Disk via disk.folder.uploadfile

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

Cloud API Rate Limiting Considerations

Cloud Bitrix24 enforces stricter API limits than on-premise. The "Team" plan allows 2 requests per second, while the "Company" plan supports up to 200 requests per second with enterprise features. When migrating large data volumes, implement rate limiting in the script:

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);
    }
}

Custom Fields and Data Types

Bitrix24 user-defined fields support types: string, integer, double, date, datetime, boolean, enumeration, file, url, employee, crm. The cloud version supports the same types, but the file type behaves differently: files must first be uploaded via disk.folder.uploadfile, then linked to the CRM record.

The employee type (binding to a Bitrix24 user) requires preliminary mapping: user IDs differ between on-premise and cloud instances.

Business Processes and Automation

Business process templates from on-premise (bizproc.workflow.template.list) can be exported to XML and imported into the cloud. In practice, this works only for simple processes without custom PHP actions. Complex business processes require reengineering using cloud tools: robots and CRM triggers.

Parallel Operation Period

I recommend 2–4 weeks of simultaneous operation in both systems. During this time, new data is entered in the cloud while the legacy on-premise instance remains in read-only mode for verification. After the period expires—deactivate on-premise and release the server.

Typical Timelines

The final decision on transition should be made after a detailed functional comparison: sometimes it turns out that for a specific business, on-premise is preferable, and migration is not justified.