Why Companies Move from Cloud to Self-Hosted
Cloud plans work well up to a point. The most common triggers for switching to Bitrix24 On-Premise are:
- Data sovereignty requirements — regulated industries, government procurement, or local data-protection laws that require data to stay on company-controlled servers.
- User count economics — once a team exceeds roughly 50 active users, the per-user cost of a cloud subscription often exceeds the one-time on-premise license plus annual renewal.
- Custom development limits — server-side PHP customisations, custom modules, and deep API work are only available on the self-hosted edition.
- Integration architecture — internal ERP, accounting, or document systems that cannot reach public cloud endpoints.
Before budgeting the project, read our deeper breakdown of why data sovereignty drives on-premise decisions and how total cost of ownership compares over a three-year horizon.
Phase 1: Audit and Inventory
The goal of this phase is a complete picture of everything that needs to move. Skipping it causes surprises mid-migration.
What to inventory:
| Area | What to document |
|---|---|
| CRM entities | Leads, deals, contacts, companies, products, smart processes — field count and volume |
| Automations | Robots, triggers, business processes per funnel |
| Integrations | Every connected service: telephony, messengers, website forms, ERP, e-signature |
| Custom fields | Field IDs, types, dependencies (IDs change after migration) |
| Users & structure | Departments, roles, access-rights matrix |
| Documents | Print-form templates linked to CRM entities |
| Tasks & workgroups | Task fields, group settings, checklists |
A thorough audit also surfaces stale data — old pipelines nobody uses, test users, deprecated integrations. This is the right moment to clean them out rather than carry legacy noise into the new environment.
From our project experience: outdated or undocumented API usage in the existing cloud configuration is one of the most common sources of unexpected extra work. Identify all custom apps and marketplace solutions before quoting the project.
Phase 2: Server Preparation and Product Deployment
Self-hosted Bitrix24 requires a dedicated Linux server (or VM). Based on typical project specifications, the implementation partner will provide requirements covering:
- CPU cores and RAM relative to user count
- Disk subsystem sizing (especially if storing large file volumes)
- Local network and DNS configuration
- Operating system setup (a current CentOS/Ubuntu LTS is standard)
- Ports 80 and 443 accessible for browser access; SSH root access for the implementation team
What gets configured during deployment (~7 hours of work):
- Clean Bitrix24 Corporate Portal installation with test data removed
- License key registered
- Push & Pull service configured (required for real-time chats and notifications)
- System email for notifications
- SSL certificate (Let's Encrypt or your own)
- Admin-restricted access (IP allowlist for the control panel)
- Proactive security module: no critical vulnerabilities
- HSTS header and HTTP→HTTPS redirect
- Web antivirus enabled
- Database tuning: query cache disabled,
innodb_log_file_sizeincreased - Automated backups to the same server (or a remote destination)
If the client does not have their own server capacity, the partner provides hosting recommendations.
Phase 3: Migration Scripts and Data Transfer
This is the technical core of the project. Because Bitrix24 does not provide a single "cloud export → on-premise import" button, migrations rely on custom PHP/CLI scripts developed by the implementation team.
The diagram below illustrates the migration data flow — scripts extract each entity type from the cloud portal, map old IDs to new ones, and load records into the self-hosted instance in a defined sequence.
The migration pipeline runs users and org structure first, then CRM configuration (fields, stages, permissions), then the actual record data, and finally automations and integrations — each stage depends on the previous one completing cleanly.
flowchart TD
CLOUD[Bitrix24 Cloud Portal] -->|Backup + API export| SCRIPTS[Migration Scripts PHP/CLI]
SCRIPTS -->|1 — Users & org structure| ONPREM[Self-Hosted Portal]
SCRIPTS -->|2 — CRM config: fields, stages, permissions| ONPREM
SCRIPTS -->|3 — CRM records: leads, deals, contacts, companies, products| ONPREM
SCRIPTS -->|4 — Tasks & smart processes| ONPREM
SCRIPTS -->|5 — Business processes & automations| ONPREM
ONPREM -->|ID mapping table| SCRIPTS
SCRIPTS -->|6 — Integrations reconnected| EXT[External Systems]
Entity-by-entity effort estimates and known constraints:
| Entity | Typical effort | Key limitation |
|---|---|---|
| Users & org structure | 2–5 h | Passwords cannot be bulk-exported; new passwords delivered via Excel to users. 2FA codes, chats, My Drive files, and calendars are not transferable. |
| Leads | 2–4 h | Only left-panel fields migrate. Right-panel activity (calls, emails, comments, meetings, print documents) does not transfer. |
| Deals | 2–6 h | Same right-panel limitation as leads. Field IDs change, so document templates must be remapped. |
| Contacts | 2–4 h | Left-panel fields + automations + access rights. Right-panel activities not included. |
| Companies | 2–4 h | Same as contacts. |
| Products | 2–4 h | Product card fields transfer; product images do not. Existing deal/lead links to products do not carry over. |
| Smart processes | 2–6 h | Field configs and automations transfer; existing records can only be moved manually (no native bulk import). |
| Document templates | 2–6 h | Templates transfer but must be reconfigured — field IDs change on the new portal and old print forms break without remapping. |
| Tasks | 2–4 h | Core task fields transfer (name, description, assignee, deadline, checklist, tags). Group disks, group feeds, group calendars, and file attachments on tasks do not transfer. |
| Business processes / lists | 2–4 h | Process logic and fields transfer; historical list items do not. |
| Integrations | 2–15 h | Every integration must be reconnected from scratch. Changing the server breaks all OAuth tokens, webhooks, and connection strings. Client provides access credentials for all systems. |
For context on what a complete Bitrix24 project looks like from a cost and timeline perspective, see our implementation cost and timeline overview.
Phase 4: New Portal Configuration
While the migration scripts handle raw data, the self-hosted portal also needs deliberate reconfiguration — only for entities that are actually in use. Obsolete pipelines and unused fields are excluded.
Configuration checklist:
- Company structure: departments, positions
- Custom fields (recreated before data import so IDs can be mapped)
- CRM funnels, stages, smart processes
- Information blocks (for catalogue and content sections)
- System baseline: permissions, menu, outbound email
- Robots, triggers, and notification rules
- Business process scenarios — tested against real data
Phase 5: Testing, Go-Live, and Cutover
This phase has the highest operational risk. The recommended sequence:
- Freeze activity on the cloud portal — agree a cutover date with all teams. Any work done in the cloud after the freeze will not be in the new system.
- Final backup of the cloud portal.
- Run migration scripts — users → structure → data. Verify data integrity; produce a migration report.
- Back up the new portal before opening it to users.
- Client acceptance testing — the client and key users test all functions and integrations. Issues found are fixed before DNS switch.
- Domain switch — update DNS to point to the self-hosted server (using the same domain keeps user bookmarks intact).
- Post-release monitoring — watch for errors that did not exist on the old portal.
- Decommission cloud portal — only after the team confirms everything works.
Typical project timeline: a focused migration with a clear scope takes approximately 2 weeks for a standard dataset. Larger volumes or complex custom code can extend this. The deployment alone is scoped at about 2 working days when the server is ready and SSH access is provided upfront.
What Cannot Be Migrated Automatically
This deserves its own section because expectations here cause the most friction:
- CRM activity history (timeline items): calls logged, emails sent, meeting notes, and comments in the right panel of any CRM card do not transfer via standard tools. Custom scripting to migrate the timeline is possible but adds scope and cost.
- Internal chat history between employees.
- My Drive files per user.
- Personal and group calendars.
- Product images and existing product-to-deal links.
- Group workspaces: group disk, group feed, group calendar, group automation robots.
- Task file attachments and comments.
- Historical smart-process records (must be re-entered manually or via a separate custom script).
If any of these are business-critical, raise them during the audit phase so they can be scoped separately.
Risks and Scope Expansion
Based on our project archive, the most common reasons a cloud-to-self-hosted migration goes over initial scope:
- Incompatibility between existing customisations and the self-hosted version (especially if the cloud portal had marketplace apps that have no on-premise equivalent).
- Undocumented or deprecated API usage in current custom code that must be rewritten.
- Hidden data structures discovered only when the export scripts run.
- Client-side changes to business process requirements mid-project.
- Additional integration work (e.g., ERP or accounting system connections) that was not in the original list.
- Increased data volume vs. what was declared in the audit.
Any out-of-scope item is assessed, priced, and agreed separately — it does not block the main migration.
Post-Go-Live Support
After the client starts working on the new portal, the implementation partner provides one month of warranty support covering issues directly related to the migration: data correctness, settings, and integrations covered by the project plan. Errors that existed on the old portal before migration are outside warranty scope.
If you are also evaluating other CRM migrations, our guides on migrating from HubSpot to Bitrix24 and migrating from Salesforce to Bitrix24 cover the same structured approach for those source systems. For teams just starting their Bitrix24 journey, the onboarding questionnaire is a useful companion to the audit phase described above.