How to Move Self-Hosted Bitrix24 to a New Server: A Complete Migration Guide

When Does a Server Move Make Sense?

A self-hosted Bitrix24 (Alaio) server move is the right choice when you are upgrading hardware, changing datacenter or hosting provider, or refreshing the underlying OS - it is fundamentally different from a cloud-to-on-premise migration, which involves a separate licensing and data-transfer process.

Common triggers include:

• Hardware upgrade - the current physical server can no longer meet growing user load (see hardware sizing guidance for capacity benchmarks).
• Datacenter or provider change - switching to a closer region, a lower-cost provider, or a private cloud for data-residency reasons.
• OS refresh - moving from an end-of-life OS to CentOS Stream 9 or another supported platform. This is increasingly common as older distributions reach end-of-support.
• Disaster recovery rehearsal - testing that a backup restores cleanly on a separate machine before an actual emergency.

A server move does not reset your Bitrix24 data or configuration - it is a like-for-like relocation. What does change is the server hostname, IP address, and the downstream services (SSL certificate, Push & Pull, cron jobs, webhooks) that reference those values.

---

Pre-Move Checklist

Run through every item on this checklist before you touch the production server; skipping even one step is the most common cause of extended downtime.

Infrastructure

• New server provisioned and reachable over SSH (port 22)
• Ports 80 and 443 open on the new server's firewall/security group
• A dedicated external IP assigned to the new server
• DNS TTL for the portal domain reduced to 300 s at least 24 hours before cutover
• SSL certificate strategy confirmed (Let's Encrypt auto-issue, or custom certificate ready to upload)

Software environment (as of 2026)

• OS: CentOS Stream 9 or the official Bitrix VM image (VMware / VirtualBox)
• PHP ≥ 8.2, with the mbstring extension enabled
• default_charset set in php.ini; mbstring.internal_encoding left empty
• Apache mod_rewrite enabled (if using Apache)
• Percona / MySQL version matching the source server
• Nginx version confirmed

Bitrix24 licence and integrations

• Active licence key confirmed - an expired key blocks updates and REST API after the grace period
• List of all registered domains for the licence compiled (all must be re-registered after the move)
• Inventory of all active webhooks, REST applications, and third-party integrations documented
• Push & Pull server mode noted (cloud or local)
• System mail (SMTP) settings saved
• Cron job list exported

Backup

• Full backup completed: files + database together, timestamped
• Backup archive stored outside the application servers (separate storage, object store, or remote location)
• Backup restoration tested on a staging machine at least once before production move

---

Provisioning the New Server

The new server must be running CentOS Stream 9 (bare metal or VM) or the official Bitrix VM image before any data is transferred; deploying onto an unsupported OS will prevent the Bitrix24 environment scripts from running correctly.

Two supported deployment paths exist:

Path	Best for	Notes
Official VM image (VMware, VirtualBox, etc.)	Teams without a dedicated sysadmin	Pre-configured LAMP stack; update via menu.sh
Bare CentOS Stream 9	Full control, custom networking, cloud VMs	ACP Group engineers deploy the required web environment manually

Regardless of the path, the following network configuration is mandatory:

• Port 80 - HTTP (required for portal function and Let's Encrypt validation)
• Port 443 - HTTPS (required for portal function and all REST integrations)
• Port 22 - SSH (required for remote administration)
• Dedicated external IP - the domain must resolve to this IP before SSL issuance

Assign the portal domain to the new server's external IP as early as possible. Let's Encrypt (or your custom certificate) is installed after DNS has propagated to the new IP.

For sizing guidance by user count, refer to our hardware sizing guide. As a quick reference from our project archive:

Users	CPU	SSD Storage	RAM
Up to 50	4-core Xeon class	128 GB	8-12 GB
50-100	4-core Xeon class	256 GB	16-24 GB
100-500	4-core Xeon class	512 GB	24-32 GB
500-1,000	6-core Xeon class	1 TB	48-64 GB

Figures reflect typical ACP Group project specs; exact requirements depend on file storage volume and integration load.

---

Taking the Full Backup and Transferring It

A valid migration backup must include both the file system (the entire Bitrix24 document root) and the database dump taken at the same point in time; a files-only or database-only backup cannot restore a working portal.

The logical flow of a server move from backup through to cutover.

The process starts with the running production portal on the old server. A full backup (files + DB) is created and transferred to an intermediate storage location. The new server pulls the backup, the environment is deployed, and the backup is restored. DNS is then switched to the new server's IP, SSL is issued, and post-restore services (mail, Push & Pull, cron, webhooks) are reconfigured before the old server is decommissioned.

flowchart LR
    OLD[Old Server\nBitrix24 running] -->|1. Full backup\nfiles + DB| STORE[Backup Storage\nexternal]
    STORE -->|2. Transfer| NEW[New Server\nCentOS Stream 9]
    NEW -->|3. Deploy environment\n& restore backup| RESTORED[Bitrix24 restored]
    RESTORED -->|4. DNS cutover\nnew IP| DNS[Domain / DNS]
    DNS -->|5. SSL issued| SSL[Let's Encrypt\nor custom cert]
    SSL -->|6. Reconfigure services| SVC[Mail · Push&Pull\nCron · Webhooks]
    SVC -->|7. Verify & go live| LIVE[Portal live\non new server]
    LIVE -->|8. Decommission| OLD

Key backup points:

• Back up while the portal is still running for a warm copy, then take a second consistent backup after locking user access at the start of the migration window.
• Store the archive on separate storage - never on the same server being migrated. Our internal policy (and the Bitrix24 best practice) is to keep backup archives outside all application servers.
• Verify the archive size is complete before transferring. A truncated transfer is a common silent failure.

For a deeper look at backup strategy, see our on-premise backup and disaster recovery guide.

---

Restoring and Reconfiguring on the New Server

Restoration follows a strict sequence: deploy the environment first, restore files and database second, and only then reconfigure domain-dependent services - reversing this order causes configuration mismatches that are time-consuming to untangle.

Based on our project delivery process, the restoration sequence is:

1. Lock user access on the old portal (maintenance mode) to ensure no new data is written after the final backup.
2. Transfer the backup to the new server.
3. Deploy the backup using the Bitrix24 restore utility (restore.php) or the VM image's built-in restore workflow.
4. Point the domain to the new server's external IP (customer action - requires access to DNS registrar).
5. Issue SSL - Let's Encrypt or upload a custom certificate - after DNS has propagated.
6. Reconnect system mail (SMTP settings).
7. Reconfigure Push & Pull - if running the local Push & Pull server, switch the module back to "Use locally installed server" in the admin panel; if using the cloud Push & Pull, re-register the domain with the licence.
8. Restore cron jobs from the saved list.
9. Update integration URLs and webhooks to reflect the new server's hostname/IP.
10. Apply any deferred Bitrix24 updates via Marketplace → Platform Update in the admin panel (requires an active licence).

---

What Commonly Breaks After a Server Move

The four most frequent post-move failures are licence key errors, Push & Pull going silent, broken webhooks pointing to the old server, and PHP configuration mismatches that block the update system.

Licence key / domain registration

When Bitrix24 detects a new server environment during start-up, it may flag the licence as used on an unregistered domain. All domains used by the portal must be listed in the licence registration. Missing a domain (for example, a secondary admin URL) blocks cloud Push & Pull and can prevent updates. On non-Enterprise licences, a maximum of two simultaneous installations (e.g. staging + production) are permitted.

An expired licence is a related risk: after the grace period, the REST API, Marketplace installs, and the update system are all disabled. Renew before migrating. See self-hosted Bitrix24 editions and licensing for the full restrictions matrix.

Push & Pull not working

Push & Pull powers real-time chat, document sync, and notifications. After a move it almost always needs explicit reconfiguration - either re-pointing the local Node.js Push & Pull server through Nginx, or re-registering the cloud endpoint. Symptoms: chat messages delayed, document co-editing broken, browser tab notifications missing.

Webhooks and integration URLs returning 404 or connection refused

Any REST application, inbound webhook, or third-party integration that hardcodes the old server's IP address or hostname will fail silently. Audit every integration before cutover and update URLs proactively. This is especially important for telephony connectors (VoIP/SIP routes are registered against a domain), website-to-CRM lead forms, and ERP sync connectors.

PHP configuration blocking updates

The Bitrix24 update system enforces specific PHP requirements (as of 2026):

• PHP ≥ 8.2
• mbstring extension present
• default_charset set in php.ini
• mbstring.internal_encoding must be empty (use default_charset instead)
• Apache mod_rewrite enabled

If the new server's PHP configuration doesn't meet these requirements, the update system will block new updates. Validate configuration immediately after restore and before announcing go-live.

File path mismatches

If the document root path differs between old and new servers (e.g. /home/bitrix/www vs /var/www/html), configuration files that reference absolute paths will break. Check /bitrix/php_interface/dbconn.php and any custom module configs for hardcoded paths.

---

Migration Steps at a Glance

#	Step	Who	Expected Result
1	Reduce DNS TTL to 300 s	Client / DNS admin	Fast propagation at cutover
2	Inventory integrations, webhooks, cron, mail settings	Engineer	Complete reconfiguration list
3	Confirm licence is active and all domains registered	Engineer	No licence surprises post-move
4	Provision new server (CentOS Stream 9 or VM image), open ports 80/443/22	Engineer	New server ready to receive backup
5	Take full backup (files + DB) on old server	Engineer	Consistent archive stored externally
6	Lock user access on old portal	Engineer	No new writes during transfer
7	Transfer and restore backup on new server	Engineer	Bitrix24 running on new server
8	Point domain DNS to new server IP	Client / DNS admin	Domain resolves to new server
9	Issue SSL certificate	Engineer	HTTPS working on new server
10	Reconfigure mail, Push & Pull, cron, webhooks	Engineer	All services operational
11	Validate PHP config (version, mbstring, charset)	Engineer	Update system unblocked
12	Run parallel check (old server on standby)	Engineer + Client	Confirm no regressions
13	Confirm go-live, decommission old server	Engineer + Client	Migration complete

A typical server move engagement with ACP Group spans approximately three weeks from project kick-off to decommission, with the actual cutover window (steps 6-11) lasting under two hours in most cases.

---

Parallel Run, DNS Cutover, and Decommissioning

Keep the old server running in read-only maintenance mode for at least 48 hours after cutover - this is your rollback window if a configuration issue surfaces that was not caught during testing.

During the parallel run

• New server is live; old server is in maintenance mode (users cannot write data).
• Monitor error logs on the new server for PHP warnings, failed cron jobs, and webhook delivery failures.
• Ask a representative group of users to test core workflows: CRM deal creation, chat, file upload, telephony if applicable.
• Verify that all scheduled automated processes (robots, business processes, triggers) have fired correctly.

DNS cutover

Because DNS TTL was reduced before the move, propagation is typically complete within 5-15 minutes for most resolvers. Use a global DNS checker to confirm the new IP is resolving worldwide before announcing go-live to all users.

Post-cutover

• Restore DNS TTL to normal values (3,600-86,400 s).
• Archive the old server's configuration files (/etc/nginx, /etc/httpd, /etc/php.ini, /etc/my.conf) before decommissioning - these are useful references for future maintenance.
• Update your internal documentation with the new server's IP, hostname, and access credentials.
• Schedule the first post-move backup on the new server and verify it completes successfully.

For teams considering a move to a cloud infrastructure provider alongside this migration, our guide to deploying self-hosted Bitrix24 on AWS, Azure, or a private cloud covers provider-specific networking considerations. If the move is also an opportunity to review your overall security posture, the 25-point security hardening checklist is worth running in parallel with the restoration steps.

Teams evaluating whether self-hosted is still the right model before committing to new hardware will find a grounded cost comparison in the 3-year TCO analysis.

---

Working with a partner on self-hosting. Want the control of self-hosted Bitrix24 without running the server yourself? ACP Group can deploy and operate it for you - see managed self-hosted Bitrix24, support & maintenance plans, or request a turnkey deployment quote.