Upgrading from 1C-Bitrix Business to Enterprise Edition

Upgrading from 1C-Bitrix Business to Enterprise Edition

The "Enterprise" edition is not simply the next step in the lineup. It is a fundamentally different level of platform scalability. Companies move to it not because of new interface features, but because of technical requirements: high loads, unlimited sites under a single license, a web cluster with multiple nodes, extended cache infrastructure, and vendor SLA.

How "Enterprise" Differs from "Business"

Unlimited number of sites. In "Business" the number of sites is technically unrestricted, but the license is designed for one domain. "Enterprise" explicitly permits an unlimited number of domains and sites — a fundamental distinction for holding companies and agencies.

Unrestricted clustering. "Enterprise" supports a full web cluster: multiple web servers behind a load balancer, distributed session storage (via session_module backed by memcached or Redis), database replication, a dedicated search server (Sphinx). In "Business" clustering is limited.

Extended caching. Support for cluster-level cache (\Bitrix\Main\Data\Cache via \Bitrix\Main\Data\ManagedCache with a memcached backend in cluster mode).

Role-based model across multiple sites. In "Enterprise" user permissions can be configured at the level of a specific site within a multisite installation via b_user_site.

SLA and vendor technical support. "Enterprise" includes priority support from 1C-Bitrix — important for projects with recovery time requirements (RTO).

File storage. Support for S3-compatible storage (AWS S3, Yandex Object Storage) via the clouds module — for distributed media file storage in a cluster.

When Upgrading to "Enterprise" Is Justified

The upgrade is warranted if at least one of the following conditions applies:

• Peak loads that a single server cannot handle (500–1,000+ concurrent users)
• Fault-tolerance requirement: stopping one node must not stop the site
• Several dozen sites managed by one team
• Integration with enterprise systems (SAP, large 1C configurations) with stability requirements
• Regulatory requirements for data storage and backup

Upgrade Process and Architectural Decisions

Upgrading to "Enterprise" is not simply changing a key. It is an architectural project:

Cluster infrastructure design. Define the topology: how many web nodes, where the load balancer is (nginx / HAProxy), DB replication scheme (master + replica), distributed cache scheme.

Cluster setup. Configuration in dbconn.php for connecting to slave servers, configuring \Bitrix\Main\Config\Option for cluster cache, configuring session storage.

Media file migration. If moving to S3 — export files from /upload/ to the storage, set up CDN, update paths in the database.

Search configuration. Sphinx or Elasticsearch as an external search engine — configuring the search module to work with an external index.

Load testing. After assembling the cluster — load testing (Apache JMeter or equivalent) to verify load balancing and fault tolerance.

Case Study: Upgrade for a Large Retailer

Client — a federal retailer, 47 regional sites on separate "Business" licenses, unified through a custom-built aggregator admin panel. Sites periodically went down during promotional periods.

Task: migrate to a single "Enterprise" with cluster architecture.

Architecture after the upgrade:

• 3 web nodes behind an nginx load balancer
• MySQL master + 2 replicas (read queries on replicas)
• Clustered memcached for cache and sessions
• Yandex Object Storage for /upload/ via the clouds module
• 47 sites under one license with a shared catalog and regional pricing

The work took 6 weeks: design (2 weeks), implementation (3 weeks), load testing and go-live (1 week).

During the next peak promotional period the site handled the load without degradation — the load balancer distributed traffic across the nodes.

Timeline

Upgrade with cluster infrastructure setup — 4–10 weeks depending on the number of sites, integration complexity, and infrastructure requirements. For simple scenarios (multisite without a cluster) — 2–4 weeks.