1C-Bitrix is moved differently from most CMS platforms: the system has a built-in backup module that packages files and the database into one archive. This is more reliable than manual copying because the module automatically excludes temporary files and cache.
How moving Bitrix differs from other CMS platforms
Bitrix stores database connection settings in bitrix/php_interface/dbconn.php rather than a single config file, and makes heavy use of the main module for disk caching in the bitrix/cache directory. You do not need to move this directory — it is rebuilt automatically and can be several gigabytes in size.
Preparing the new server
Check that the new server has the versions from the table below — Bitrix is sensitive to mismatched PHP versions and extensions:
| Component | Minimum | Recommended |
|---|---|---|
| PHP | 8.1 | 8.3 |
| MySQL | 5.7 | 8.0 |
| mysqli module | required | required |
| Free disk space | x2 of site size | x3 of site size |
You need extra free space because the backup archive will temporarily take up as much space again as the site itself.
Creating a backup with the BackUp module
In the site control panel, open "Settings" → "Backup" → "Create backup" and choose the option to split into 100-500 MB volumes when the site is larger than 2 GB — this makes uploading the archive over FTP easier. With SSH access to the server, it is faster to run the backup from the console:
php bitrix/modules/main/tools/backup.php
Download the finished archive (or the set of .tar.gz volumes) to your local computer, or transfer it straight to the new server with rsync, as described in the article moving site files.
Restoring on the new server
Upload the archive to the /upload/backup/ directory of the site on the new server via the "Data Restore" web interface in the Bitrix admin panel. The restore wizard unpacks the files itself and offers to create a database — enter the new MySQL login and password you set up in advance on the new server.
Restoring from the console without the web wizard — import the database with:
mysql -u bitrix_user -p bitrix_db < backup_db.sql
The general algorithm for exporting and importing MySQL, including working with large dumps, is covered in the article moving a MySQL database.
Configuring dbconn.php and checking the license
After restoring, open bitrix/php_interface/dbconn.php and check that the $DBHost, $DBName, $DBLogin and $DBPassword constants point to the new server. Then clear the cache from the admin panel: "Settings" → "Auto-caching" → "Clear cache", or delete the contents of the bitrix/cache directory manually.
The Bitrix license is tied to the domain, so changing the IP address without changing the domain needs no reactivation. The domain changes too — go to "Product Settings" → "License Keys" and update the binding.
Switching the domain without downtime
Before switching the A record, open the site on the new server by IP, overriding the host in the local /etc/hosts file, and make sure the catalog, cart and admin panel at /bitrix/admin/ work. Lower the record's TTL to 300 seconds a day before the switch so changes propagate quickly across DNS servers. A detailed scheme is in the article switching hosting without downtime.
Bitrix migration checklist
- PHP and MySQL versions on the new server meet the requirements.
- The backup was created with the BackUp module, not manually.
- The bitrix/cache directory was excluded from the transfer.
- The dbconn.php file points to the new database.
- The cache was cleared from the admin panel after restoring.
- The site was tested by IP before the DNS switch.
After switching the domain, go through the general checklist in the article post-migration site checklist.