1C-Bitrix Small Business: where a standard project breaks
The "Small Business" edition of 1C-Bitrix covers the storefront, shopping cart, and checkout — which is honestly enough at the start.
Bottlenecks begin not with an empty catalog, but with growth: when the product range moves into thousands of items and traffic reaches hundreds of concurrent visitors. We analyze exactly where a standard project breaks and what module configuration provides.
First — catalog. Sections are kept in a flat structure, the filter is built on properties without indexes, and the query pulls the entire reference book instead of the results page.
Response time grows with every new item, and visitors from search are the first to feel it: slow site response eats orders before traffic can bring them in.
Second — behavior under load. Caching is enabled formally, static files are not served separately, and agents run on user requests. A peak — a sale or newsletter — turns this into a queue, and the site starts serving pages in pieces.
Third — manual operations in the admin panel. Recalculating discounts, updating prices, order statuses, and exports to the accounting system are done by hand because the exchange is only partially configured.
Module limits are clearly visible here: some checks, integrations, and scenarios are simply not included in the edition.
All three bottlenecks of the edition are connected: the catalog sets the speed, speed sets the load, and the load comes back as manual work for employees. We analyze how this is addressed by module configuration and procedures.
What proper configuration of the edition's modules provides
Configuring the modules of the "1C-Bitrix Small Business" edition is not a one-time configuration tweak, but a set of modes that determine how the site behaves under real load.
While default values are active, catalog response speed drops even at several hundred concurrent visitors: every request to a product page goes directly to the database, and exchange with the accounting system runs synchronously and blocks page rendering.
Properly configured caching modules, composite mode, and separate indexes for queries change the picture.
The catalog serves prepared pages from cache, exchange with 1C goes into a background queue and does not slow down the storefront, and heavy operations are moved to low-traffic hours.
Catalog load stops being a bottleneck: response time remains predictable both at peak and during reindexing.
The second layer is automation of routine operations. Scheduled tasks update stock and prices themselves, clear outdated caches, collect reports, and send notifications to responsible staff.
The share of operations that were previously performed manually falls, and along with it the number of support requests decreases: typical failures are resolved before the user notices them.
The checklist based on the results of additional configuration is short. Response speed of key pages fits within the target threshold. The share of automatic operations exceeds manual ones. Traffic growth does not increase the support queue.
The error log contains no recurring incidents. Each point is confirmed by measurements before and after — otherwise configuring the edition's modules remains a set of guesses.
Comparison of additional configuration options and their limitations
The limits of additional configuration are set by the edition, not by a set of settings: in "Small Business," some modules and scenarios are simply not supplied, and they cannot be enabled through administration.
That is why we first sort the task into three categories — it is covered by built-in tools, it is faster to cover with a ready-made extension, or it runs into the need to move to a higher edition.
A mistake at this step is the most expensive: a missing module built with a third-party solution works today and conflicts when the core is updated tomorrow.
| Option | When it fits | Limitations |
|---|---|---|
| Built-in edition modules | The task is solved by configuring permissions, templates, business processes, the catalog, and already active modules | Boundaries are set by the edition: some functions are unavailable, and non-standard logic cannot be assembled through settings |
| Third-party extensions | A narrow function is needed: an integration, a report, an additional field in a card | Dependence on the author and compatibility with updates; accumulating extensions causes conflicts |
| Custom development | The logic is unique and is found neither in built-in modules nor on the market | Maintenance effort grows: the solution is tested with every core update |
| Migration to a higher edition | Modules and limits are needed that the current edition does not have by definition | Data and settings migration is not fully automatic, and scenarios are tested on a copy |
Practice shows: about half of requests for "additional configuration" are covered by built-in tools, and we say so honestly before work begins.
We take on extensions only for bottlenecks, and we move to an edition change when limitations hinder development, not a single task. Describe what should work — we will come back with an estimate and a plan for each of the options.
Work order: settings audit, scheme, implementation
The "Small Business" edition provides a ready set of modules, but an enabled module is not the same as one configured for the task.
A site settings audit shows which edition capabilities are actually used, where properties and sections are duplicated, and which agents and scheduled tasks remain from previous contractors. Without this map, any change hits the neighboring node.
- Audit of the current configuration: we capture the set of modules, user group permissions, caching settings, and the information block scheme.
- Integration scheme: we record the flows between the site, 1C, and external services — what is transferred where, at what frequency, and by what attribute discrepancies are reconciled.
- Implementation plan: the order of changes with a rollback point at each step; settings that affect the storefront and checkout are moved into a separate window.
- Assembly on a copy: we transfer changes to a copy of the production site and run through exchange, discounts, cart, and payment.
- Verification on production data: we reconcile stock, prices, and orders after exchange, and review the error log and catalog response time.
- Project handover: the administrator receives an update procedure, a description of the integration scheme, and instructions for typical failures.
Each stage is closed with a short report: what was found, what was changed, how it was verified. This way, configuration does not turn into a series of live edits.
Package: configurations, access roles, procedures
The package is assembled during the work, not after delivery: every artifact is tied to the real environment and verified on it. Otherwise, the documentation diverges from the settings within a month, and the next change again begins with a blind investigation.
- Configuration description: which edition modules are enabled, which are disabled and why, which components and templates are overridden, and what has been moved from the control panel into configuration files.
- Role and access policy scheme: a "role — permission level — sections" matrix, separate groups for content editors, order operators, and administrators, and mandatory two-factor authentication for privileged accounts.
- Maintenance procedure: frequency of core and module updates, the procedure for testing an update on a staging environment, maintenance windows, and conditions for rolling back to the previous state.
- Administrator instructions: where to view event and error logs, how to read the load report, and what to do if a page, email, or 1C exchange fails.
- Backup: copy composition (files, database, custom settings), schedule, retention depth, storage location, and the procedure for verifying restoration on a separate environment.
- 1C exchange procedure: which entities are synchronized, at what frequency, and how to resolve discrepancies in prices, stock, and order statuses.
- External services map: payments, delivery, newsletters, analytics — where access keys are stored, who the owner is, and what to do when credentials change.
- Change log: what was changed and when in settings, code, and permissions — indicating the author and reason.
All documents are stored next to the code in the version control system and updated together with it. After that, the client's team maintains them independently — or hands them to us, and changes go into the common log.
Case study: how the project stopped hitting edition limits
Before: the catalog grew, the edition did not
The project is wholesale trade, a store on the "Small Business" edition of the 1C-Bitrix platform.
The catalog grew from 3,000 to 18,000 items, and the edition's ceiling became visible: characteristic reference books were kept in custom tables, the filter assembled one query from five sources, and 1C exchange ran as a full export on a schedule. The catalog responded in 4–6 seconds, and during peak hours some carts failed by timeout.
What was changed
Data was arranged by purpose: the product core remained in information blocks, reference books moved to Highload blocks, and filter links moved to a separate indexed table.
Catalog and product pages were switched to composite cache, heavy queries to managed cache with scheduled warming, and 1C exchange was made incremental.
The edition was not changed — limits were removed through additional configuration, preserving the current license and section structure.
After: metrics
- Catalog response: 4–6 s → 0.7–1.1 s on an unwarmed cache.
- Share of pages served from cache at peak: 0 → 93%.
- Timeout failures when accepting requests: isolated → zero over the sale season.
- Catalog size: 18,000 → 40,000 items without changing the edition.
- 1C exchange: minutes → tens of seconds, full export no longer blocks the storefront.
Six months later, the assortment grew by another third — the data scheme and cache warming held up without a rebuild.
What to do if the project is already deployed on 1C-Bitrix?
A project on 1C-Bitrix rarely needs to be rebuilt from scratch: the edition and modules are installed, data has accumulated, and integrations work.
That is why we start not with migration, but with an inventory — which modules are active, what has been added to the core, and where business processes live. Already here it is clear what can be changed safely and what pulls a chain of dependencies.
Compatibility testing runs on a staging environment. We copy the database and files, bring up a copy on the same edition, and only there enable the required module: we review the error log, agent conflicts, event handlers, and cache behavior. If the data and logic match, the change is allowed into the production environment.
Additional configuration without downtime is built on phased changes. We connect modules one at a time, move settings into the administrative section, and put logic into a custom module or event handlers instead of editing the core.
Then platform updates do not overwrite customizations, and any change can be disabled with a single setting.
Data migration proceeds in separate passes: first the structure — information blocks, properties, sections, then users, groups, and permissions, then content and links.
The migration is repeatable: it can be run again and the number of records compared so that discrepancies surface before the switch.
Before each stage — a backup and rollback point, with recovery taking minutes. We schedule work for minimum load, spread heavy operations across windows, and after the switch maintain enhanced monitoring of errors and response speed for a day.
Technical questions before work begins
Before configuring the modules of the 1C-Bitrix Small Business edition, clients ask the same questions: will customizations fall apart when the platform is updated, will data be preserved, how much work will remain on their side, and what will happen to administrator permissions. We address each one — briefly and to the point.
Will platform updates break our settings?
We do not edit the core or built-in modules — changes live in a separate layer and in custom modules.
The edition update runs on a staging environment: we assemble a copy of the production site, run the update, check key scenarios, and only then transfer it to the production environment. If something conflicts, rollback takes minutes.
Will data be lost during customizations?
Before any work, we take a full backup — files and database — with restoration verification on staging. We perform schema migrations with reversible scripts, not manually through the admin panel. Any change can be rolled back without losing orders or user accounts.
How much work will remain on our side?
We cover module configuration, access permissions, and integrations. The site administrator is left with approving changes, working with content, and starting scheduled backups according to the checklist. We grant access by roles: the contractor has no extra permissions, and you have a full action log.
Let's discuss the task: what to send for an estimate
An estimate for such a task consists of two parts: what is already deployed on the project and what needs to be changed.
The more accurately the contour is described — edition, module composition, integrations, load — the fewer assumptions remain in the work plan and the more realistic the stage timelines look. Below is what to attach to the task description.
- Type and edition: a site on "1C-Bitrix: Site Management" in the "Small Business" edition or a portal on 1C-Bitrix24, license status.
- Module composition: what is enabled, what changes were made previously, and what exactly stopped working.
- Integrations: 1C exchange (catalog, prices, stock, orders), payment systems, delivery, notifications.
- Infrastructure: where the project is hosted, server parameters, access to the repository and backups.
- Data volume: number of products and catalog sections, number of users, peak order load.
- Access and materials: administrator in the control panel, hosting, database, account for 1C exchange.
- Constraints: what cannot be changed, external deadlines, procedure for stopping work.
This is enough to come back with an estimate of the scope, a breakdown of work by stage, and a plan with checkpoints. If some data is closed, we record assumptions separately and remove them on the first call.