Setting up 1C-Bitrix Enterprise: where the portal breaks
A portal on the Enterprise edition is not a site with an extended set of modules, but a bundle of the storefront, the accounting system, and the exchange services between them.
Setting up 1C-Bitrix: Enterprise is different in that most failures are born not in the page code, but at the junctions: between the portal and the accounting system, between access rights and the cache, between the backup policy and actual recovery.
The most common point of failure is data exchange with the accounting system. The nightly export session runs longer than its window and does not finish by morning, some reference data remains in yesterday's state, and the user sees different balances in two windows.
Duplicates and orphaned records accumulate for months because the exchange is configured without integrity control and without conflict resolution.
The second bottleneck of the portal is performance under load. A catalog with a million items on live filters turns the catalog into a queue if indexes are not offloaded, heavy queries are not separated, and section-based caching is not configured. Reference data and rights are read on every request, although they change once a day.
Access rights and backups complete the list of failure points for an enterprise portal.
Inherited groups at deep nesting cause slow checks and leaks into closed sections, and a backup that has never been restored is not protection but complacency: recovery reveals broken links and incomplete exchanges.
Next we look at how this is addressed: with an exchange policy that controls discrepancies, profiling of heavy queries, an access rights audit, and verifiable recovery from backup.
What a configured portal delivers: effect in measurable values
A configured portal is not a "checkmark in the configuration", but a set of values that can be taken from monitoring before and after work.
The first thing that changes is response time under real load: catalog and personal account pages stop drifting during peak requests, and the query queue does not grow with the number of concurrent visitors.
The second is stability: the server does not go into restart during a seasonal sale or mass export, because caching and load distribution are configured for the traffic profile, not by default.
A separate value is the share of exchange errors with the accounting system.
When synchronization scenarios are described explicitly (what is transferred and in what order, how a conflict is resolved), discrepancies in balances and order statuses no longer require manual reconciliation.
The share of manual operations in typical processes drops to exceptions: an employee intervenes only where human judgment is needed, not where the mechanism has broken.
Recovery time after a failure is also manageable. Backups, a deployment policy, and a predictable rollback procedure turn an outage from "the portal is down while we figure it out" into "we brought it up in minutes, lost only the last transactions".
At the same time, entire classes of failures disappear: disk overflow from logs, hung background tasks, locks on mass operations.
These are the values — response, share of exchange errors, stability under load, share of manual operations, and recovery time — that we record as control points. Setting up 1C-Bitrix Enterprise is considered complete when there is a measurement before and after for each of them.
Deployment options: comparison of operating modes
The deployment mode determines two things: how the site will behave if a node fails and how long it will take to roll out updates.
In the Enterprise edition, roles are distributed among servers — web layer, applications, database, cache — and with correct configuration, the failure of one node does not stop the project. Below are the options that are actually chosen between when setting up 1C-Bitrix Enterprise.
| Option | When it fits | Limitations |
|---|---|---|
| Hosting on own hardware, single node | Small load, data must not leave the perimeter | No node redundancy: a disk failure means downtime until recovery from backup |
| Own hardware with node redundancy | Internal systems, access control and predictable load are important | Requires a second set of servers, replication, and a failover policy |
| Cloud infrastructure | Peaks and seasonal sales, fast launch of new projects | Dependence on the provider, need to control where the data physically resides |
| Fault-tolerant cluster | 24/7 service where downtime is unacceptable | More complex maintenance: balancing, replication, separate cache control |
Separately, there is maintenance mode — this is not a hosting method, but a tool needed by any of the options. It closes the site with a stub page during module updates and database migrations, so the visitor sees a clear page, not a connection error.
In practice, a mixed scheme is more common: the database and files on own hardware, front-end nodes and backups in the cloud. We transfer the project between modes in stages so that switching does not require stopping the service.
Implementation stages: from audit to handover to support
Implementation in 1C-Bitrix Enterprise starts not with enabling modules, but with recording what already works: edition, rights, response time of sections, background exchanges, and scheduled tasks.
Without this picture, any change lands on unpredictable load and breaks neighboring scenarios that no one remembered.
-
Portal audit. We capture a map of modules and settings, measure the response of key sections, analyze exchange logs, queues, and agents. The output is a list of bottlenecks and settings that conflict with each other.
-
Target configuration. We design the scheme: the set of enabled modules, roles and access rights, what goes into cache and what is calculated on the fly, how search indexing and backup are configured. The scheme is fixed before work begins — otherwise changes spread across the portal.
-
Module configuration. Changes are made in segments, not all at once: first the perimeter that does not affect users, then the working sections. This way, an incident at one step does not block the entire portal.
-
Post-change verification. We run control scenarios along the affected paths, compare response and logs with audit measurements, and check rollback to the previous state. A change is accepted only if the numbers are no worse than the baseline.
-
Handover to operation. We hand over the policies: what and when to maintain, which settings not to change without analysis, where to look at logs, how to roll back. The administrator receives a document, not verbal explanations.
-
Post-launch monitoring. For the first weeks, we compare actual metrics with targets: if a section's response has grown or the exchange has queued up, we investigate before users notice it.
Roles, access rights, and policies: what remains in the project
After module configuration, the project should retain a set of artifacts that your administrator can use without us. This is not a folder with exports, but verifiable documents: what is configured, why exactly so, under what conditions it changes, and how to roll back. For each item we hand over a separate file with a version and revision date.
- Access rights matrix — a "role × section × action" table with explicit exceptions. It shows who can do what without reading code or going through settings.
- Description of user roles: which groups are created, which inherit rights automatically, where rules are overridden pointwise and why.
- Module configuration files with comments — enabled parameters, default values, the consequence of changing each one.
- Scheme of connections between sites, modules, and external systems: exchange with the accounting perimeter, queues, failure points, direction of data flows.
- Configuration of action logs — which events are written, retention period, how to export and analyze an incident step by step.
- Maintenance policy: frequency of tasks, backup procedure, planned maintenance window, rollback point.
- Administrator instructions — grant access, revoke, change role, check log: step by step, tied to system screens.
- Rollback procedure: what is restored first if a module change affected the public part or exchange.
We check the set at acceptance: we ask the administrator to perform typical operations according to the instructions on the test perimeter. If a step is described ambiguously or the matrix diverges from actual rights — we rewrite before handover.
Case study: how the portal stopped falling under peak load
A portal on 1C-Bitrix in the Enterprise edition serves several thousand employees and counterparties: catalog, personal account, exchange of requests with the accounting system.
On days when reporting periods closed, simultaneous sessions increased several times over, pages took 20–30 seconds to assemble — some users left without waiting for a response.
What it was
The bottleneck was not the web layer, but data exchange: synchronization with the accounting system ran entirely on a schedule, pulled all changes in one package, and held locks on tables until the end of the export.
The cache was reset on every catalog update, pages were reassembled, the query queue grew — at peak, the service returned errors instead of pages.
What we rebuilt
The exchange was split into portions by changed entities and moved to a queue with acknowledgment of processing for each batch.
The cache received tagging by catalog sections and is reset pointwise, and the number of concurrent heavy operations was limited so that peaks were distributed rather than added together.
What the result was
- response time under peak — 1–2 seconds instead of 20–30;
- the exchange window with the accounting system shrank from nightly to a few minutes, nightly service restarts are no longer needed;
- failures under load: there were several incidents per month, now zero for the reporting period.
The metrics were taken on the same load profile before and after, so the increase in stability cannot be attributed to a seasonal decline. We review queue and cache thresholds as the catalog grows, and rollback to the previous configuration remains possible in one action.
How does Enterprise differ from the standard package?
The differences between editions show not in the number of modules, but in architecture. The standard package is designed for one portal and one site: shared database, shared cache, single template.
The 1C-Bitrix Enterprise edition is for companies where several sites, brands, or branches share one core and a common user base.
Multi-site capability is built in here: each site gets its own domains, templates, rights, and content catalog, but works with shared data and single authorization.
This removes the need to synchronize portal copies manually — the structure and changes are distributed from one administrative section, and the load can be distributed between servers.
The modules of the extended package cover what in the basic version is bypassed with third-party scripts: managing multiple sites from one core, composite cache for high traffic, cluster configuration, rights differentiation by department, and business logic with multiple approval branches. They determine whether the portal can withstand peak load without data discrepancies.
Migration between editions is a separate project, not a license change. First we record which modules are actually involved, then transfer data, convert multi-site, reconfigure cache, agents, and rights, run everything on the test perimeter, and leave a rollback point.
There is one limitation here: what in the standard package was solved with workarounds must be rewritten according to the rules of the extended package during migration.
Technical doubts before starting: answers to frequently asked questions
Before starting, the technical side raises more questions: what will happen to accumulated data, can a running system be changed, how to connect it with the accounting perimeter, and who is responsible for it after handover. Below are short answers with the order of work and control points.
What will happen to data from the current system?
We transfer the structure of departments, users, task history, files, and rights in two passes: a trial on the test perimeter and a final one during a window of minimal activity.
We match reference data by keys and resolve discrepancies before switching so that after launch we don't have to fix rights manually.
Can a portal that is already running be configured?
We assemble changes on a copy, test scenarios, and deliver them in packages — the production perimeter does not stop, and rollback takes minutes.
Setting up 1C-Bitrix Enterprise on a live portal goes through separate modules and access rules, so changes do not affect the logic of neighboring sections.
How is integration with the accounting system arranged?
The exchange runs according to a policy through a queue: if the accounting system is unavailable, data is not lost but resent. Each record gets a key, so duplicates are not created, and the exchange log shows what and when diverged.
What is included in support after handover?
A policy for responding to requests, portal monitoring, installation of module updates, and vulnerability remediation. We test updates and security first on the test perimeter — if a patch breaks a scenario, the production portal does not receive it.
Let's discuss the task: we'll send an estimate and work plan
To come back with an estimate and work plan, rather than general wording, we need a minimum set of source data: access to the test perimeter or a fresh copy of the database, current settings of the core and connected modules, a list of integrations, and a description of what exactly is unsatisfactory in the operation of the Enterprise edition. This is enough to estimate the scope based on facts, not assumptions.
In response we send:
- a map of the current configuration: which modules are active, which rules and limits are set, where the load bottlenecks are;
- a list of configuration work broken down by stages and indicating what is rolled out first;
- a plan for regression and load testing before going to production;
- a diagram of environments and the procedure for transferring settings between the test and production perimeters;
- a list of responsible persons on both sides and points where the customer's decision is required;
- a draft support and rollback policy after changes.
The approval procedure is transparent: we discuss the task, clarify priorities, fix the boundaries of the first stage — only after that does the project start.
We send the estimate and work plan within a few business days after receiving the data; if the perimeter is unavailable, we mark the items that will require on-site verification. Describe the task — we will come back with an estimate and a plan.