Selection and installation of the 1C-Bitrix Standard edition

Why 1C-Bitrix Standard Hits the Project Ceiling

The choice of a site edition is usually made once and by inertia: Standard is familiar, covers a business card site, a corporate website, and a catalog with several hundred items — it seems that this is enough.

Mistakes when choosing a license are laid exactly here: people focus on today's volume, not on the growth model — how many products there will be, whether a second site will appear, whether real-time exchange with an accounting system will be needed.

When the catalog grows and traffic comes to filters and faceted search, it becomes noticeable that the edition cannot handle the load.

Some acceleration tools — composite cache, storage for large catalogs — are not included in it, and tasks begin to be closed with workarounds: filters are assembled manually, exchange with the accounting system is moved to a night window, caching is bolted on top of templates, and the number of items per page is limited.

The site's bottleneck shifts from the server to the platform: catalog response time grows, exports no longer fit into the allotted window, and failures appear at the peak of a sale.

Each workaround lives in the page code, breaks during an update, and requires more support than the site itself. This is the edition's ceiling — not an accident, but the limit of available tools.

The ceiling manifests not on launch day, but at a specific volume of catalog and traffic, so it is calculated in advance, not based on the fact of failures. Below we analyze how to determine this moment and move to a higher edition without rewriting the site.

What a Properly Chosen Edition and Load Headroom Provide

The 1C-Bitrix edition defines what the platform can do out of the box and what will have to be bolted on via workarounds.

A mistake at this step does not manifest immediately: the storefront grows, the catalog begins to serve pages noticeably slower, background tasks compete with visitors for resources, and recovery after a failure turns into a multi-hour operation with manual data reconciliation.

The effect of changing the edition is visible in metrics, not in a list of features.

Load headroom appears: some pages are served from the composite cache, search moves to an index, heavy operations are moved to queues — the catalog withstands the seasonal peak without an urgent migration in the middle of a sale, and the share of manual operations when updating content drops because exchange with the accounting system runs on a schedule.

Recovery predictability is addressed separately.

When the edition supports backup with a replica and a clear rollback procedure, site recovery time is measured in tens of minutes instead of hours, and the class of failures "after an update the storefront is unavailable" goes away along with the ability to return the previous state in one step. For an online store, stability is exactly the cost of downtime that you stop paying.

1C-Bitrix Standard and Higher Editions: Comparing Options

The Standard edition is designed for one site with one domain: multi-site support, branch subdomains, and separate permissions by company structure are not supported in it.

Exchanges with the accounting system are also cut down — the catalog is exported, but two-way exchange of orders, stock, and statuses requires a higher edition.

Before changing the license, it is worth checking whether the project is hitting the edition or the configuration: some bottlenecks are removed by caching, composite mode, and redistribution of requests.

Three Paths and Their Limits

Editions should be compared by the list of required exchanges and the permission structure, not by the number of modules in the description.

Transfer between editions happens without rebuilding the site: data, templates, and settings are preserved; the set of available features changes.

The update is first run on a copy of the project, where exchanges with the accounting system, subdomain operation, and branch permissions are checked, and only then transferred to the production environment.

Implementation Stages: From Audit to Handover to Support

Implementation of an edition begins not with installation, but with an inventory: what already works, which modules are involved, how integrations are arranged, and where the environment hits the ceiling.

Without this map, any migration plan turns into transferring accumulated problems along with the data. Therefore, we first record the current state, then design the target one, and only then touch the production site.

1. Audit of the current environment. We collect the composition of the server environment, catalog structure, database volume, list of used modules, external integrations, and load profile from logs. The output is a dependency map and a list of bottlenecks.
2. Target configuration diagram and migration plan. We determine the edition and set of modules, role placement scheme, caching rules, and order of work. The plan directly answers: what we transfer as is, what we clean up, what we rewrite.
3. Environment preparation and edition installation. We deploy a separate environment, configure permissions, backups, the scheduler, and email notifications. The production site receives traffic until the switchover.
4. Content and data transfer. We transfer sections, files, properties, users, reference data, and operation history. Scripts count records before and after, integrity of links is checked automatically — discrepancies are resolved before switchover.
5. Acceptance checks. We run scenarios along critical paths: authorization, checkout, payment, forms, search, exports, role permissions. We separately look at behavior when external services are unavailable.
6. Handover to support. We show the content editor how to publish, and the administrator the settings and logs. We provide documentation: environment diagram, access credentials, backup policy, and list of scheduled tasks.

We perform the switchover in a low-load window, with a rollback point to the previous environment. Then comes the support period: adjustments based on operation and incident analysis according to a pre-agreed procedure.

What You Keep After the Edition Launch

An edition is not considered implemented until its state is described in such a way that another engineer can reproduce it.

Therefore, we hand over not only access credentials but also working documentation: from it, one can restore the exchange logic, deploy a copy of the staging environment, and explain to the editor where their permissions end.

• Site documentation: structure of sections and information blocks, binding of properties to templates, list of used components and caching settings.
• Integration diagram: which systems exchange data, in which direction flows go, on what schedule exchanges are launched, and what happens in case of failure.
• Access policies: role matrix for administrators, editors, and contractors, two-factor authentication rules, and the procedure for granting permissions during work.
• Maintenance policy: backup frequency, database integrity checks, core and module updates, error log monitoring, and backup storage location.
• Editor instructions: step-by-step scenarios for publishing pages, uploading images, working with SEO fields, and rules of behavior when an error appears on a page.
• Administrator instructions: starting and stopping exchanges, recovery from a backup, update rollback procedure, and escalation contacts.
• Environment passport: correspondence of development, testing, and production environment addresses, list of external services and keys that must be replaced during migration.

All of this is stored next to the project and updated with every configuration change — otherwise, six months later even a routine update turns into a post-mortem.

Describe the task: we will come back with an assessment and a plan in which the set of delivered artifacts is fixed in advance.

Case Study: Changing an Online Store's Edition Without Losing Orders

An online store with a catalog of 12,000 items and exchange with an accounting system was running on a lower edition of the platform.

On sale days, catalog response went beyond 4–5 seconds, the cart and checkout fell off, and price and stock exports were launched manually and blocked exchange for hours.

Some customers saw an error at the last step and did not return — this is exactly the order loss that is not visible in reports.

What Was Changed

We moved to 1C-Bitrix Standard using a zero-downtime migration scheme: we raised a copy of the environment, transferred the catalog, trade offers, prices, and warehouses, and reconciled discrepancies using control samples.

The switchover was done in a night window: the catalog and cart remained available, and orders placed at the moment of switchover were written to a queue and loaded into the database after the work was completed. The prepared rollback to the previous environment was not needed.

Metrics Before and After

• catalog response under peak load: 4–5 seconds → 0.8–1.1 seconds;
• manual operations during exports: 40+ operator actions per day → 4 scheduled tasks;
• recovery after an exchange failure: up to 3 hours → up to 15 minutes;
• failure rate during peak sales: 7% → less than 0.3%, no lost orders.

Two months after the switchover, the team never once opened the catalog manually or stopped exchange during peak hours. Next, we analyze how to choose an edition for your load and exchange with the accounting system so that such a transition is planned, not emergency.

What Is the Difference Between an Edition Upgrade and Migration to a New Platform?

An edition upgrade is a change of the module set within one platform: the core, data structure, and operating logic remain, and you get the functionality of a higher edition on top of an already working site.

Migration is fundamentally different: the platform changes, and with it the data model, templates, integrations, and admin-side logic.

The engineering advantage of an upgrade is reversibility and preservation of the accumulated environment: the catalog, orders, users, link structure, and search history remain in place.

The main risk is inherited customizations: if the 1C-Bitrix core was modified directly or modules were written bypassing standard mechanisms, some of them will stop working after the edition change.

Therefore, an upgrade begins with an inventory of modifications and a run on a test environment — incompatibility becomes visible before deployment to the production site.

Migration is justified when the limitation is not in the edition but in the platform itself: catalog scenarios or integrations are insufficient, it cannot handle the load, or the content workflow structure gets in the way.

The gain from changing the platform is real, but the trade-off is a separate migration project: data transfer, template rebuilding, reconfiguration of integrations, and finding analogues of modules that simply do not exist for some tasks. Timelines and risks here are an order of magnitude higher than for an upgrade within the platform.

The selection criterion is simple. If the task is solved by moving to a higher edition — upgrade: it is shorter, less time-consuming, and reversible.

If the project is already deployed and hits an architectural limitation of the platform — migration is planned as a standalone project: audit of the current environment, list of custom modules with portability assessment, phased transfer with preservation of the link structure, and a backup environment for rollback.

Common Technical Doubts Before Installing an Edition

Engineers and tech leads rarely doubt the edition itself — questions before implementation concern five practical things: downtime during an update, preservation of settings, headroom for growth, environment requirements, and the ability to quickly find a bottleneck. Below is how we address each of these doubts when installing 1C-Bitrix Standard.

Will settings be preserved during transfer?

Module settings, access permissions, user fields, and exchange rules are exported separately from content and transferred one-to-one.

Before work, we record control snapshots of the structure; afterward, we compare: if there is a discrepancy, it is visible immediately, not a week later in production.

Will there be enough headroom for growth?

We design the data schema with a view to a higher edition: this way, catalog growth and an increase in requests do not require rewriting the logic. Moving up comes down to a license upgrade and targeted module configuration, not content migration.

What are the environment requirements?

We capture requirements before installation: interpreter version, DBMS, disk space for cache and backups, memory limits for heavy scripts. We select a configuration with load headroom so that the seasonal peak does not turn into a failure.

How do you find a performance bottleneck?

Performance diagnostics begins with profiling: slow query log, page generation time, cache state, missing indexes. The results show what to optimize — queries, caching, or the environment — and this is confirmed by measurements before and after, not guesses.

Let's Discuss the Task and Come Back with an Assessment and Work Plan

To come back with a work assessment and implementation plan, we need a short set of initial data — usually it is gathered in one meeting and a couple of emails.

The more accurately the process on the customer's side is described, the fewer assumptions in the assessment and the fewer revisions during development.

• Task statement: what result is needed and by what criterion the customer will understand that it has been achieved.
• Current state: which 1C-Bitrix edition is used now, where the site is hosted, who owns the domain and access credentials.
• Integrations: 1C, CRM, payments, delivery, external services — what already works, what needs to be connected.
• Constraints: security requirements, windows for deploying changes, peak loads on the site.
• Materials: section structure, layouts, texts, access to analytics and ad accounts.
• Roles: who on the customer's side approves changes and makes decisions on disputed points.
• Acceptance: how the result will be checked and by what criteria the stage is considered closed.

In response, you receive a written scheme: implementation stages, composition of tasks for each stage, timeline estimate, and implementation options — from the basic scope to the extended one.

The scheme is agreed before work starts; any scope change afterward goes through the same procedure, so timelines do not “slip” in the middle of the project.

Describe the task in free form — we will come back with an assessment and work plan.