Migrating from Bitrix24 Cloud to Self-Hosted: Step-by-Step Plan

Why Companies Move from Cloud to Self-Hosted

Companies migrate to Bitrix24 self-hosted (Alaio) when they face three pressures at once: compliance requirements (LGPD, GDPR), the need for deep customisation, and a 3-year TCO analysis that favours a perpetual licence over a growing per-user subscription.

The decision typically surfaces as a business scales and three pressures converge: full control over data (compliance requirements, LGPD, GDPR, or internal policy), the need for customisations that the cloud version does not support, and a 3-year TCO analysis that favours a perpetual licence. If you are still evaluating this decision, see the full cloud vs. self-hosted TCO analysis and the article on data sovereignty with Bitrix24 on-premise.

The most common triggers we see in real projects:

• Regulatory compliance - data must reside on a company-owned server or a controlled data centre
• Deep integrations - internal APIs, legacy systems, or on-premise ERP that require direct database access
• Code-level customisation - proprietary modules, UI modifications, or business workflows not supported in the cloud
• Cost predictability - a subscription that grows with headcount versus a one-time licence plus annual renewal

---

Project Phase Overview

A Bitrix24 cloud-to-self-hosted migration is divided into 4 sequential phases - audit, server deployment (~7 h), data migration, and go-live testing - with a typical total timeline of 2 to 4 weeks and 1 month of guaranteed post-cutover support.

The process follows four sequential stages. The complete flow, from audit to post-go-live support:

flowchart TD
    A[Phase 1: Audit and inventory] --> B[Phase 2: Self-hosted server deployment]
    B --> C[Phase 3: Data and configuration migration]
    C --> D[Phase 3b: Integration reconnection]
    D --> E[Phase 4: Testing and go-live]
    E --> F[Guaranteed post-go-live support]

Phase 1 - Audit and inventory: a complete mapping of the cloud portal structure - active CRM entities, pipelines, automations, external integrations, custom fields, and data volume. Obsolete entities are excluded from scope to avoid inflating the workload.

Phase 2 - Server deployment: Linux environment setup, Bitrix24 on-premise installation, removal of test data, licence key registration, Push & Pull configuration for chats, SSL via Let's Encrypt, SMTP for system notifications, and automated backups. Estimated time: approximately 7 hours. The client can provide SSH (root) access to their own server, or the deployment team can recommend a compatible hosting provider.

Phase 3 - Data migration and reconfiguration: transfer of each CRM entity, reconfiguration of automations, and reconnection of all external integrations. Detailed in the next section.

Phase 4 - Testing and go-live: joint testing with the client, post-test adjustments, domain switch (DNS cutover), and post-launch monitoring. After go-live, 1 month of guaranteed support covers any issues that did not exist in the original portal.

---

What Is Migrated - and What Is Not

In a migration to self-hosted, fields, pipelines, automations, and permissions for CRM entities are migrated; activities on the right-hand side of cards (comments, calls, emails), files attached to tasks, chat history, and all external integrations are not migrated and must be reconnected from scratch.

This is the most critical section for setting expectations. The table below summarises the real scope based on the project plans we have executed:

Entity	What is migrated	What is not migrated
Users and structure	Employee data, departments, passwords (delivered in a spreadsheet)	Chat history, "My Drive" files, personal calendars, 2FA
Leads	Fields, pipeline stages, cards (left side), automations, permissions	Right-side card activities (comments, calls, emails, meetings)
Deals	Fields, stages, cards, automations, permissions	Right-side card activities
Contacts and Companies	Fields, cards, automations, permissions	Right-side card activities
Products	Fields, product cards	Product images; existing links to deals/leads
Smart Processes	Fields, stages, automations, permissions	Right side of the card; existing data imported only via manual script
Tasks	Core fields (title, assignee, deadline, checklist, tags)	Attached files, comments, groups and their settings
Document templates	Template structure	Templates must be remapped (field IDs change during migration)
Business Processes / Universal lists	Settings and logic	Historical elements already created
External integrations	Settings are replicated from scratch on the new server	No integration migrates automatically - all must be reconnected

Important note: because the server changes, all external integrations must be reconfigured from scratch - the client must provide access to integrated systems during this phase.

---

Effort Breakdown by Module

Migration effort ranges from ~7 hours for server deployment to 2-15 hours per module (external integrations being the most variable item), with a total calendar timeline of 2 to 4 weeks for standard to complex projects.

Based on the project plans we have executed, the following are typical hour ranges per module:

Module	Estimated hours
Server deployment	~7 h
Users and company structure	2-5 h
Leads	2-4 h
Deals	2-6 h
Contacts	2-4 h
Companies	2-4 h
Products	2-4 h
Smart Processes	2-6 h
CRM document templates	2-6 h
Tasks	2-4 h
Business Processes / Lists	2-4 h
External integrations	2-15 h (depends on quantity and complexity)

The typical total timeline for a cloud to self-hosted migration project is between 2 and 4 weeks of calendar time.

---

Migration Scripts: When the Standard Approach Is Not Enough

For portals with high data volumes or advanced customisations, purpose-built PHP/CLI scripts replace the standard Bitrix24 export/import process, always executed in the order users - company structure - CRM data to preserve cross-entity references.

For portals with high data volumes or advanced customisations, the standard Bitrix24 export/import approach is not sufficient. In these cases we use purpose-built PHP/CLI scripts that cover:

• User migration with old-to-new ID mapping
• Infoblock transfer
• CRM entity migration (including timeline, where applicable)
• Testing on an isolated copy of the database before running in production

The execution sequence always follows this order: users - company structure - CRM data. This ensures that cross-entity references are preserved correctly.

Risks that may expand scope and timeline:

• Incompatibility between existing customisations and the Bitrix24 version on the new server
• Use of deprecated or undocumented APIs in the source portal
• Custom code that needs to be rewritten
• Data volume larger than identified during the initial audit

Any item on this list is treated as additional scope, with an estimate provided and client approval obtained before execution. For a better understanding of the hardware requirements, see the Bitrix24 self-hosted server sizing guide.

---

Post-Deployment Security Hardening

Post-deployment hardening for Bitrix24 self-hosted covers at least 8 mandatory layers - from adjusting innodb_log_file_size and disabling display_errors to HSTS, admin access restriction by IP, and web antivirus - with a target of zero critical errors in the internal security scanner.

The technical deployment includes a set of security configurations that must be applied immediately after installation:

• Database structure error correction (automated and manual checks, targeting 0 errors)
• Disabling PHP error display in production (display_errors)
• Database adjustments: disabling query_cache and local_infile; increasing innodb_log_file_size
• Raising the proactive protection level - the internal scanner must report no critical vulnerabilities
• Adding the HSTS header and enforcing HTTP to HTTPS redirection
• Restricting admin panel access by IP address
• Protecting against portal use inside iframes (clickjacking prevention)
• Enabling web antivirus

For a complete 25-point checklist, see the article on security hardening for Bitrix24 self-hosted.

---

Testing, Go-Live, and Post-Migration Support

The self-hosted go-live follows 5 steps - backup, client validation, bug fixing, domain cutover, and monitoring - with 1 month of guaranteed post-launch support covering any issue that did not exist in the original portal, within the agreed scope.

The testing phase is carried out jointly with the client before access is opened to all users. The flow:

1. Full backup of the new portal after migration
2. Handover of the environment to the client for validation (integrations, features, automations)
3. Resolution of issues identified during testing
4. Release of access to end users (domain cutover)
5. Post-launch monitoring

After go-live, guaranteed support covers for 1 month any issue that did not exist in the original portal - provided it falls within the scope agreed in the project plan.

---

Typical Costs and Commercial Terms

A Bitrix24 cloud-to-self-hosted migration typically costs between USD 900 and 2,000, with a 2-week timeline for standard scope and up to 4 weeks for complex portals; payment is either 100% upfront or 50%/50% at signing and after the guaranteed support period.

Pricing varies according to portal complexity, data volume, and the number of integrations. Based on projects we have executed:

• Cloud to self-hosted migration (standard scope): equivalent to USD 900-2,000 (local currency amounts vary by region)
• Execution timeline: 2 weeks for standard-scope projects; up to 4 weeks for complex portals
• Typical payment terms: 100% upfront, or 50% at signing + 50% after the guaranteed support period

For full greenfield implementation projects (without migration), costs and timelines follow a different logic - see the real Bitrix24 implementation cost and timeline data.

---

Working with a partner for self-hosting. Want the control of Bitrix24 self-hosted without managing the server yourself? ACP Group deploys and operates it for you - see managed Bitrix24 self-hosted, support and maintenance plans, or request a turnkey quote.