Imagine your 1C-Bitrix "Business" online store starts slowing down under peak load—500 concurrent sessions, response time drops to 10 seconds. Clients complain, managers get nervous, and you realize it's time to scale. As a team of certified Bitrix specialists with 7 years of experience and over 100 migrations, we frequently encounter this situation. Migrating to the "Enterprise" edition is not just a key change; it's an architectural overhaul that solves load and fault tolerance issues.
What Makes Enterprise Different from Business
| Feature | Business | Enterprise |
|---|---|---|
| Number of sites | Limited by license | Unlimited |
| Clustering | Partial | Full cluster |
| Caching | Standard | Cluster (memcached) |
| Search | Built-in | Sphinx/Elasticsearch |
| File storage | Local | S3-compatible |
| Support | Standard | Priority SLA |
Unlimited sites—Enterprise explicitly allows unlimited domains and sites, a must for holdings and agencies. Unrestricted clustering: full web cluster with multiple web servers behind an nginx load balancer, distributed session storage via memcached or Redis, database replication, dedicated Sphinx search server. Extended caching via \Bitrix\Main\Data\Cache in cluster mode. Role-based model across multiple sites via b_user_site. Priority support with SLA from the vendor. File storage on S3-compatible object stores through the clouds module.
When Is Migration to Enterprise Justified?
Migration becomes justified under at least one of these conditions:
- Peak loads that a single server cannot handle (500-1000 concurrent users)
- High availability requirement: one node failure must not bring the site down
- Dozens of sites managed by one team
- Integration with corporate systems (SAP, large 1C configurations) requiring stability
- Regulatory data storage and backup requirements
Why Enterprise Handles Loads Better
Through clustering, Enterprise distributes traffic across multiple servers, giving a 3-5x performance boost over a single Business node. Cluster cache on memcached reduces database response time, and S3 storage offloads the file system. Consult with an architecture specialist—we offer a free analysis of your current load.
How the Migration to Enterprise Works
- Cluster infrastructure design. We determine the topology: number of web nodes, load balancer (nginx/HAProxy), DB replication scheme (master+replica), distributed cache.
- Cluster setup. Configuration in
dbconn.phpfor connecting to slave servers, cluster cache configuration via\Bitrix\Main\Config\Option, session storage. - Media file transfer. If moving to S3—upload files from
/upload/to storage, configure CDN, update paths in the database. - Search setup. Sphinx or Elasticsearch as external search engine—configure the
searchmodule to work with an external index. - Load testing. After cluster assembly—load testing (Apache JMeter or similar) to verify balancing and fault tolerance.
Timeline Table by Complexity
| Scenario | Timeline | Peculiarities |
|---|---|---|
| Multi-site without cluster | 2–4 weeks | One license, single catalog, regional settings |
| Cluster of 2–3 nodes | 4–6 weeks | Load balancing, replication, memcached, S3 |
| Full cluster with search and S3 | 6–10 weeks | 3+ nodes, Elasticsearch, object storage, CDN |
Example Cluster Cache Configuration
Cluster cache is configured via bitrix/.settings.php:
'cache' => array( 'type' => 'memcache', 'hosts' => array('192.168.1.10:11211'), 'usecluster' => true, ) Case Study: Large Retailer Migration
Our client—a federal retailer with 47 regional sites on separate Business licenses, united under a common admin panel through a custom aggregator. Sites periodically crashed during promotions. Task: migrate to a single Enterprise with a cluster architecture.
Architecture after migration:
- 3 web nodes behind an nginx load balancer
- MySQL master + 2 replicas (read queries on replicas)
- Cluster memcached for cache and sessions
- Yandex Object Storage for
/upload/viacloudsmodule - 47 sites under one license with a single catalog and regional pricing
The work took 6 weeks: design (2 weeks), implementation (3 weeks), load testing and launch (1 week). During the next peak promotion, the site handled the load without degradation—the load balancer distributed traffic across nodes.
What's Included in the Work
- Analysis of current architecture and loads
- Cluster topology design
- Web server, load balancer, and cache setup
- Data migration and storage configuration
- Load testing and optimization
- Documentation and training for your team
Timelines
Migration with cluster infrastructure setup: 4-10 weeks depending on the number of sites, integration complexity, and infrastructure requirements. For simple scenarios (multi-site without cluster): 2-4 weeks.
Order a turnkey migration—we will assess your project and suggest the optimal architecture. Get a consultation for your project: we provide a free load analysis and migration path advice.