Bitrix site migration: what breaks during a transfer
A Bitrix site migration almost never breaks at the moment files are copied — it breaks on desynchronization. While you are dumping the database, orders keep being placed on the live site, users keep registering, and stock levels keep updating in 1C.
If the dump is taken at 03:00 and the files and configuration are transferred at 11:00, a layer of changes accumulates in between that simply does not exist on the new server.
The very first order placed in that window goes nowhere — and this is discovered not during the transfer, but a day later when a customer complains.
The second class of failures is access rights and environment.
On the old server the directories were owned by one user, on the new one by another; /bitrix/php_interface/dbconn.php, upload/, bitrix/cache/ get incorrect masks, and the site either returns a 500 or writes "Access denied" to the log on every cache request.
Alongside these are unaccounted-for cron jobs: Bitrix agents, scheduled 1C exchange, exports to marketplaces.
On the new server they are either not added to crontab or run under a different user and silently fail — the exchange stalls, but the error only surfaces once the data diverges.
The third source is external integrations and bindings that live outside the file system: the IP address in payment gateway whitelists, webhooks tied to the old domain, a license key tied to the environment, the SSL certificate and DNS records.
Changing the server address without synchronously updating these bindings results in declined payments and undelivered notifications — even though the site itself opens and looks functional.
That is exactly why downtime during a migration is not "the copy time" but the window in which the database, files, and external dependencies diverge.
Let's break down how this is closed: how to take a consistent data snapshot, transfer the environment without losing permissions, and switch traffic so that a visitor never sees a single error.
How migration works without taking the site offline
Database replication
The primary node keeps serving requests, while a replica is brought up on the new server in constant log-apply mode. During the transfer, the entire stream of production operations is written and reaches the replica — the lag is measured in seconds and is continuously monitored.
When the replica lag drops to zero, the database is ready for cutover: all that remains is to wait for writes to stop and promote the new node to primary.
For a typical «1C-Bitrix» configuration, this gives a write-downtime window of one to two minutes instead of hours of outage.
File synchronization
The uploads directory, cache, static assets, and user files are transferred in two passes. First — a full copy while the site is running: it moves the bulk of the data. Then — incremental re-sync by checksums, which transfers only what changed.
By the time of cutover, the file delta is zero, and the cache on the new server is pre-warmed — the first visitors don't wait for cold page generation.
Traffic switching
Traffic is switched at the DNS level with a low TTL or through a load balancer — so the new server's address is picked up without editing client configurations. The old node stays on standby and accepts requests until the DNS cache updates across all providers.
If something goes wrong, rolling back to the previous server takes minutes: the replica is deployed in reverse.
| Transfer option | When it fits | Limitations |
|---|---|---|
| Database replication + file synchronization | Large project with active requests and orders | Requires replica lag monitoring and a test run |
| Transfer via backup with downtime | Small site, downtime window agreed upon | Full unavailability during dump and restore |
| Phased transfer in parts | Many disparate services and subdomains | Longer on the calendar, requires route coordination |
We run each mode on a copy of production in advance — the cutover is rehearsed before the live launch. We build the replication scheme and traffic-switching order on MySQL with a replica and a reverse proxy that holds sessions and doesn't break customers' shopping carts.
Migration stages: from audit to access handover
Migrating a site to Bitrix is not "copy the files and the database," but a managed sequence of steps where each next one relies on the result of the previous one.
First comes inventory: which modules are involved, where the uploaded files are stored, how cron jobs are set up, the exchange with 1C and external integrations.
In parallel, we record the current environment parameters — the PHP version, web server settings, limits and permissions — so that we can reproduce them on the new server without surprises.
- Infrastructure audit. We build a dependency map: database, file storage, queues, scheduler, external services. Separately, we check which of these are critical for the site's operation and which can be disabled during the migration.
- Migration plan. We determine the order: what is migrated in full, what is synchronized incrementally, where the switchover point is. We record a rollback plan — where we return to if the post-switchover check fails.
- Environment setup. We deploy a new server to the same requirements: runtime versions, extensions, directory permissions, cache and session configuration. The environment must be ready before the production database lands on it.
- Test migration. We run a copy of the database and files on the new server, verify the record counts, the integrity of relations, the operation of forms, payments and the exchange with 1C. Here we also measure response time under load.
- Switchover. We move traffic to the new server during a window of minimal activity, keeping the old one in read-only mode. We change DNS records with a short time to live so that a rollback takes minutes rather than hours.
- Verification and access handover. After the switchover, we go through the checklist: authorization, orders, emails, exports. We hand over to the client the access credentials, the environment diagram and the maintenance instructions.
Each stage ends with a verifiable result — and that is what zero downtime means: the user does not see the moment when the site changed servers. Describe your configuration — we will come back with an estimate and a migration plan.
How is migration to a new server different from moving to the cloud?
Migrating to a new server and moving to the cloud solve different problems, although both relate to Bitrix site migration.
In the first case, you stay on your own infrastructure and change the "hardware" or the platform: a physical server on a dedicated rack, a virtual machine at a hosting provider, or the same server in a different data center.
In the second case, the site moves to a managed platform where scaling, backup, and fault tolerance are handled by the provider, and you work with configuration rather than hardware.
Preparation differs in the scope of work. When migrating to a physical server, you need to plan the disk subsystem yourself, set up redundancy, and think through the backup and monitoring scheme — all of this falls on your team.
A virtual machine removes some of the hardware tasks, but you configure and maintain the environment, web server, database, and cache yourself.
Moving to the cloud shifts the focus: you describe the requirements for the environment, while the platform covers the infrastructure layers, updates, and fault tolerance.
Timelines depend not on the type of platform, but on the volume of data and the complexity of the environment. Migration to a physical server usually takes longer: you need to coordinate delivery, deploy the system, migrate the database and files, and test performance under load.
A virtual machine and the cloud are deployed faster, but they require careful data synchronization so as not to lose orders and requests received at the moment of switching.
Rollback risks are the key difference. On a physical server, returning to the previous platform takes hours: you need to switch traffic and make sure the database on the old node has not diverged from the new one.
In the cloud, rollback is easier thanks to snapshots and rapid deployment of a copy, but a dependency on the provider and its regulations appears.
We always keep the working old server in reserve until stability is confirmed, and we perform the switch via managed DNS with a short record TTL — this enables rollback in minutes rather than hours.
The practical conclusion: if you do not have your own hardware maintenance team and need predictable fault tolerance, the cloud wins.
If there are strict requirements for data placement or you already have your own infrastructure in place, migrating to a new server or virtual machine remains a reasonable choice.
In both scenarios, we plan the migration so that the site remains available and the rollback point is at hand.
Case study: migrating an online store to Bitrix with no downtime
An online store on Bitrix ran on a single server: the web application, the database, and the catalog's file storage all lived on one machine.
Under peak load — sales, mailings to the database — the server went into swap, catalog pages took several seconds to serve, and some orders were lost at the checkout stage.
There was no standby site: any kernel update or scheduled hardware replacement meant the store would go down.
What was changed
The roles were separated: the application, the database, and the catalog files moved to separate nodes, with a load balancer and two copies of the application in front of them.
The database was moved to leader–follower replication, heavy catalog queries went to the follower, and sessions and cache were moved to shared storage so the cart would not be lost when switching between nodes.
The migration was done without stopping sales: first the new site was brought up, then data replication and file synchronization were enabled, after which traffic was switched over to it.
The old server remained a hot standby until it was confirmed that all orders and payments were processing normally.
Metrics before and after
| Metric | Before | After |
|---|---|---|
| Downtime during migration | hours of downtime | no downtime |
| Catalog response under load | seconds | fractions of a second |
| Lost orders at peak | regularly | failure class eliminated |
| Rollback to the previous version | manual, slow | by switching traffic |
The key effect is not speed as such, but predictability: peak load no longer brings the store down, and updates and server maintenance are no longer an event that puts revenue at risk.
The architecture was deployed relying on 1C-Bitrix and its built-in clustering mechanisms, so platform updates do not break the configuration.
If your store runs on a single server and you are afraid to touch production — describe your task, and we will come back with an estimate and a migration plan.
Compatibility, access, and rollback: what to discuss before the start
Before starting a Bitrix site migration, three technical concerns always come up: environment compatibility, access and roles, and the rollback plan. Let's go through them in order — they determine whether the migration will be manageable or turn into an overnight emergency.
What if the current server is set up in a non-standard way? First, we take inventory: PHP and MySQL versions, the set of extensions, web server configuration, cron jobs, agents, mail queues, external integrations.
If custom modules or core modifications were running on the old environment, we record them separately and migrate them as-is rather than "cleaning them up" along the way. Compatibility is verified on a staging environment before traffic is switched, not on production.
What about access? We need accounts with the minimum sufficient permissions: database read access, file system access, DNS management, access to the hosting panel and repository. We assign roles in advance — who owns DNS, who confirms the switch, who accepts the result. We don't send passwords and keys in chat: we set up a separate secure vault.
What if something goes wrong after the switch? The rollback plan is prepared before the start, not after a failure.
The old server remains operational with an up-to-date copy of the database and files, DNS records are reverted with a single change, and the point of no return is fixed. Rollback takes minutes, not hours.
Can the site be migrated without downtime?
Yes. Traffic is switched only after the new environment has passed verification on staging: the database is synchronized, files are in place, integrations respond. The DNS switch happens during a minimal-load window, and users see a working site without interruptions.
The client receives:
- web server, PHP, and database configurations as ready-to-use files;
- an infrastructure diagram with server roles and data flows;
- a backup policy and backup schedule;
- a document with the rollback plan and checkpoints;
- a registry of access rights and account owners;
- an acceptance checklist with verification results;
- operating instructions for the new environment for your team.
Describe your task — we'll come back with an estimate and a migration plan tailored to your environment.