Migrating to 1C-Bitrix Enterprise: Where Business Breaks Down
The Business edition is designed for a single server, and this is baked into its architecture: the web server, database, and file storage all live on one machine. As long as traffic is steady, the scheme handles the load unnoticed.
As soon as a peak appears — a sale, a seasonal surge, a newsletter to the entire database — the nodes start competing for the same resources: the web server waits for a response from the database, the database waits for disk space to free up, and response time grows not linearly but avalanche-like.
The first symptom is degradation under load: pages respond slower and slower, the request queue grows, some users leave before waiting for the catalog or cart to load.
Then comes web server failure: the process hits the limit of simultaneous connections, and the site returns an error entirely, not just for individual sections.
Recovery in such a scheme means restarting the service and manually offloading the database — that is, downtime that every client sees.
The second bottleneck is the lack of a cluster. In Business, you cannot move the database to a separate node, put several web servers behind a load balancer, and survive the failure of one of them without stopping the site.
Any hardware failure is a single point of failure, not a switchover to a backup. Backup also hits the same machine: taking a dump under load without slowing down the site is nearly impossible.
The third limit is the Business edition's caps as growth continues: the number of simultaneous visitors, the size of the search index, working with high-load components and multi-site functionality.
A project hits a ceiling not because the code is bad, but because the edition is not designed for that kind of output. Migrating to 1C-Bitrix Enterprise removes precisely these limitations — let's break down how this is addressed technically.
What a clustered architecture and fault tolerance deliver
A cluster of web servers turns a site from a single point of failure into a set of nodes, with load balancing distributing traffic among them.
If one node goes down, the balancer stops sending requests to it, and the remaining nodes take on the load — the visitor sees nothing except, possibly, a slightly slower response to a single request.
Previously, the failure of a single server meant complete unavailability until an administrator intervened manually.
A site's fault tolerance is built not only on duplicating nodes, but also on the state of sessions and data. Sessions are moved to shared storage, files go to shared object storage, and the database runs in replication mode with automatic failover to a standby node.
Then any web server can serve any visitor at any time, and a node going down does not break the shopping cart or log the user out.
Recovery time with this approach is measured in seconds: the balancer removes the failed node via health-check, and the standby node takes over automatically.
The manual scenario of bringing a server up from a backup took hours and always carried the risk of losing some orders placed at the moment of the failure.
Under peak load, the cluster behaves predictably: as traffic grows, nodes are added, and throughput scales linearly rather than hitting the ceiling of a single server.
This removes the main pain of sales and seasonal spikes, when a site goes down precisely at the moment of maximum sales.
The practical effect of the transition is that the failure rate drops from hours of downtime per month to minutes, recovery no longer depends on an on-call engineer, and peak loads stop being a threat.
Next, we will look at how this is arranged at the configuration level and what changes in the support policy.
Deployment options: single server, cluster, cloud
The choice of deployment option determines not only the project budget, but also how the system withstands peak loads, updates, and failures.
On Bitrix Enterprise, the same functionality can be deployed on a single server, assembled into a fault-tolerant cluster, or hosted in the cloud — and each approach has its own ceiling, beyond which compromises begin.
| Option | When it fits | Limitations of the approach |
|---|---|---|
| Single server | Low traffic, internal portals, project launch | No redundancy: hardware failure stops the site; updates only with downtime; load growth hits the resources of a single machine |
| Cluster configuration | High traffic, online stores, mission-critical services | Requires a dedicated engineer and monitoring; more complex debugging; more expensive to maintain; requires release discipline |
| Cloud infrastructure | Variable load, fast launch, distributed teams | Dependency on the provider; restrictions on custom modules and network settings; predictable costs only with proper autoscaling |
What to consider when choosing
A cluster configuration provides fault tolerance and horizontal scaling, but requires load balancing, database and cache replication — without this, the failure of a single node brings down the entire site. The cloud removes some of the hardware tasks, but security and backup settings remain on your side.
In practice, a hybrid is most often chosen: the core and database on dedicated servers, static content and heavy tasks in the cloud. This option covers both performance and cost predictability.
We analyze the load and fault-tolerance requirements, then propose a configuration for the task — without unnecessary redundancy where it is not needed, and with headroom where downtime is unacceptable.
Stages of Transition to 1C-Bitrix Enterprise
Transition is not a license replacement, but a restructuring of the architecture for load and fault tolerance. That is why we run it as an engineering project with fixed stages: each subsequent step relies on the result of the previous one, not on assumptions.
- Infrastructure audit. We capture the current picture: peak traffic, request profile, bottlenecks in code and on servers, database volume and structure, external integrations. The output is a report with growth points and a list of what will not survive the load.
- Cluster scheme design. We determine how roles are distributed: web servers, database, cache, search, file storage. The cluster scheme is fixed on paper before setup — this way we see where replicas are needed and where redundancy is sufficient.
- Environment setup. We deploy servers, configure balancing, database replication, shared cache, and fault-tolerant file storage. We bring the configuration to a state that survives the failure of an individual node without stopping the site.
- Data and code migration. We migrate the database and files, adapt components for cluster mode, and remove dependencies on a single server. We perform the migration with the ability to roll back to the original environment.
- Load testing. We run scenarios close to real peaks and see where the system hits its limit. Based on the results, we adjust the configuration and code, then repeat the measurements until stable indicators are achieved.
- Handover and documentation. We hand over the cluster scheme, maintenance regulations, recovery and monitoring instructions. The client's team understands how the system behaves under load and what to do in case of failure.
This order removes the main risk of transition — discovering that the new configuration cannot handle the load only after launch. Describe your task — we will come back with an estimate and a work plan based on these stages.
Access policies, IAM roles, and data migration
Migrating to Bitrix Enterprise almost always goes hand in hand with putting permissions in order: on Business, access was historically granted "as it happened," but on Enterprise that is no longer safe.
We analyze the current permission matrix, map it against IAM roles, and migrate data so that the access separation does not have to be redone after launch. Below is what the customer receives as a deliverable at the end of this work block.
- Access matrix: a mapping of "employee → role → section → action," with redundant and inherited permissions clearly flagged.
- IAM role description: which roles are set up, what each one permits, and how a role is linked to an account and a user group.
- Access policies for the administrative area and for data: who gets extended permissions and under what conditions, and how permissions are revoked when an employee changes position or leaves.
- Data migration procedure: the order of migrating users, groups, content, and relationships, integrity checkpoints, and rules for rolling back to the previous environment.
- Cluster diagram with node roles: where the web servers are, where the database is, where the cache and queue are, and how the load is distributed among them.
- Environment configurations: database connection parameters, caching settings, limits, and timeouts, moved into separate files for each environment.
- Cluster documentation: how the environment is deployed, how a node is added, what to do when a component fails, and how to verify recovery.
- Acceptance checklist: a list of checks for permissions, data integrity, and cluster behavior under load before release to production.
Each item is not a report "for a checkmark" but a working artifact: using it, your team will be able to grant access to a new employee, revoke permissions upon dismissal, or connect a node without contacting us.
The cluster documentation and access policies are written so that an engineer can read them, not just the implementation author.
Describe your task — we will get back to you with an estimate and a plan for this work block.
Case study: migrating from Business to Enterprise without downtime
The project is an online store on the "Business" edition with two application servers and shared session storage in the file system. Peak load occurred during sales: when one node failed, carts and authorization "fell apart" because sessions were not shared.
Recovery after a failure took an average of 40 minutes — an engineer manually brought the node up, checked integrity, and switched traffic. The share of requests with errors during peak hours reached 4%, and some orders were lost at the checkout stage.
What was changed
The store was migrated to 1С-Bitrix Enterprise and a fault-tolerant circuit was assembled: several application servers behind a load balancer, shared session and cache storage, a database replica with automatic failover when the primary node fails.
Separately, the web server's cluster mode was configured and heavy operations — price list generation, exports, search — were moved to separate nodes so they would not compete with order checkout.
Metrics before and after
| Metric | Before | After |
|---|---|---|
| Recovery time when a node fails | ~40 minutes | 1-2 minutes |
| Share of requests with errors at peak | up to 4% | less than 0.1% |
| Behavior under peak | degradation, lost orders | linear growth, no failures |
| Scheduled maintenance | store shutdown | no shutdown, nodes one at a time |
The migration was carried out on a running store: the new circuit was brought up in parallel, data was transferred, load-testing scenarios were run on a copy of the traffic, and DNS was switched during a night window. Downtime for customers — zero, placed orders were not lost.
After the switch, enhanced monitoring was maintained for two weeks and bottlenecks were analyzed based on metrics.
How Does Business Differ from Enterprise in Practice?
At the code level, the core of both editions is the same — modules, API, and database structure are identical. The difference shows up in the fact that the Business edition is designed for a single server: the web application, database, and cache all live on one machine.
Enterprise was designed from the ground up for a distributed scheme, where the application, database, and cache are spread across nodes and combined into a cluster. As long as the load fits within a single server, the difference isn't visible.
As soon as peak traffic appears or hardware fails, the behavior of the systems diverges fundamentally.
Cluster capabilities are the main engineering difference. In Business, fault tolerance is built on redundancy: a second server, a database replica, manual or semi-automatic failover.
In Enterprise, load balancing, replication, and failover when a node goes down are baked into the architecture: multiple web nodes, a distributed cache, database replicas. When one node fails, traffic is redistributed among the rest, and the user doesn't notice any downtime.
For an online store with peak sales or a portal with authentication, this is the difference between "the site is down" and "the site is running."
Licensing is also structured differently. Business is tied to a single server, and with horizontal scaling, each additional machine must be licensed separately. Enterprise is licensed for the cluster as a whole, so adding web nodes doesn't require revisiting licenses.
This removes the scaling limitation: capacity can be increased with nodes rather than by replacing the single server with a more expensive one.
The support level is the third difference. For Business, standard technical support on a ticket basis is available. For Enterprise, an extended level applies: priority request handling, a dedicated engineer, and assistance with designing the cluster architecture. During a production incident, this shortens the time until the vendor's specialists respond.
The practical takeaway: switching to Enterprise is justified when a single server can no longer handle the load, when downtime costs more than the infrastructure, or when fault tolerance without manual intervention is needed.
If these conditions aren't present, Business solves the task more cheaply and simply. We analyze your load profile and tell you straight whether an edition change is needed — without pushing anything extra.
Common technical concerns when upgrading
Concerns about upgrading to the senior edition are usually not about the license, but about what will break along the way. Below are the four questions engineers ask most often, and how they are addressed in practice.
Module compatibility: will custom modifications have to be rewritten?
Not rewritten, but checked. Your own modules, event handlers, and components work on both editions — it is not the core that changes, but the set of available capabilities: clustering, per-site separation, extended permissions.
We run each module on a test bench, record what requires changes, and make targeted fixes. We look at third-party solutions separately: some of them have versions for the senior edition, some do not, and this is visible before work begins, not after.
Migration without downtime: how do you move data without stopping the site?
We migrate in two passes. First — a full copy of the database and files to the new environment, on which all checks are rehearsed.
Then — a short synchronization window: we catch up on the changes accumulated since the copy was made, switch the traffic, and keep the old environment in hot standby.
For catalogs with a large volume of orders, the window is measured in minutes, not hours, and is scheduled for nighttime traffic.
Load testing: how do you know it will withstand the peak?
The bench is assembled in the same configuration as the production environment, and the profile of real peaks is reproduced on it — a sale, a newsletter, a seasonal spike.
We look not at the average response time, but at behavior under queueing: where the database hits its limit, where the cache does, where the balancer does. Based on the results, connection pools, caching, and replicas are tuned. If a bottleneck remains, it is found before launch, not on the day of the promotion.
Rollback plan: what if something goes wrong after the switch?
Rollback is designed in advance and tested on the bench. The old environment remains operational, its data is not deleted, and traffic switching is reversible at the balancer level.
We separately define the point of no return: before it, rollback takes minutes; after it, it requires reverse synchronization, and we state in advance where that boundary lies. The decision to launch is made based on the results of load tests, not based on the calendar.
Let's discuss your Enterprise migration task
To make the migration assessment realistic, we need to understand the current project landscape: server configuration and cluster layout, database volume and structure, active modules and customizations, integrations with 1C and external systems, as well as peak loads and fault-tolerance requirements.
The cluster architecture, migration strategy, and scope of work depend directly on these inputs — so we start with a thorough review, not a template proposal.
Describe the task in your own words — what works now, what is no longer satisfactory, and what result you need. We will come back with a migration assessment and a work plan: stages, timelines, team composition, and acceptance criteria. If risks surface during the review, we will name them directly, before the start.
- We will review the current configuration: servers, cluster, database, modules, customizations.
- We will assess the migration scope and the bottlenecks that will create load during the transfer.
- We will check integrations with 1C and external systems for compatibility.
- We will propose a cluster architecture for your peak loads and fault-tolerance requirements.
- We will draft a work plan with stages, timelines, and checkpoints.
- We will define a rollback strategy and a zero-downtime cutover procedure.
- We will agree on the team composition and areas of responsibility at each stage.
Let's discuss the task — tell us how the project is set up now and what you want to achieve. We will come back with a migration assessment, a work plan, and clear success criteria.