How to choose a 1C-Bitrix edition for your website

Choose a Bitrix edition by what your website needs to do: store content, receive enquiries, take orders or calculate customer-specific prices. Page counts and attractive designs do not determine the edition on their own. This guide helps you document requirements, check a contractor’s proposal and decide whether you need to buy now. The outcome is a short, justified edition choice with stated limitations, rather than guessing how much spare capacity to buy.

First separate the website, CRM and ready-made solution

Quotes often combine three purchases. 1C-Bitrix: Site Management is the website platform. Bitrix24 is a separate product for running a business, including customer management. A ready-made Marketplace solution is an additional product with its own terms and requirements. Including CRM in a project does not mean it is included in the chosen CMS licence. Buying a template does not replace the platform licence if the template requires one.

Ask for the quote to separate the platform, solution, implementation, hosting, external services and maintenance. Each line should identify the licence owner, what is included and subsequent expenses. This makes clear what is being sold and which costs cover work versus software. A single “turnkey Bitrix” line does not provide that information.

Step 1. Describe visitor actions

List five to ten scenarios in the form “who — does what — receives which result”. For example: a visitor chooses a service and submits a brief; a procurement officer downloads a specification; a regular customer sees their contracted price; a buyer pays for an order and receives confirmation. Do not start with module names: that comes next.

“We need a catalogue” is insufficient. In one project it means photographs and specifications with an enquiry button. In another it means SKUs, reservations, discounts and multiple sales terms. Pages may look similar while requiring different data models and platform capabilities.

Separate launch requirements, an already agreed next phase and undated ideas. What matters is a real commitment rather than a notional annual plan: who uses the feature, when it is needed and whether implementation resources exist. An edition bought for an unspecified future dealer account will not create that account by itself.

Step 2. Match requirements to editions

On the verification date, 22 October 2026, the manufacturer’s Russian comparison lists Start, Standard, Small Business, Business and Enterprise variants. Check module availability and limitations in the current manufacturer comparison. The following is a selection process, not a promise that every function works automatically after installation.

• For a site containing services, articles and case studies, check whether a lower edition is sufficient. Record search, form and ready-made-solution requirements separately.
• For a native product catalogue and order processing, begin by comparing commerce editions. The manufacturer describes store functionality and 1C exchange in Small Business.
• For complex sales terms, check price-type, warehouse and required-module limitations for each candidate edition. “Wholesale” alone is not a technical requirement.
• For a large distributed system, first describe load, infrastructure and resilience requirements. An Enterprise-level solution needs its own architecture estimate, not a choice based on employee count.

Put every mandatory requirement into a matrix: native capability, additional solution, custom development or not yet confirmed. The last status is useful: it identifies a question to resolve before buying. Do not replace it with “Bitrix can do anything”.

Step 3. Check solution and exchange compatibility

If a ready-made solution supplies the design and some features, open its listing and documentation for the specific version. Find its minimum CMS edition, environment requirements, restrictions and update terms. Save the link and verification date. Written confirmation from the solution developer is better than a seller’s verbal promise, particularly for a nonstandard pricing model.

For a 1C exchange, record the 1C configuration and version, exchange module, data transferred and direction. “We have 1C” does not establish compatibility. Exporting products, prices, stock, orders and order statuses are separate tasks. Each needs a source of truth and a testable example: for instance, a particular SKU’s price change must reach the site within an agreed period.

Do not confuse displaying a price with permission to see it. A wholesale price may exist in the data without being intended for every visitor. Clarify access rules, authentication and what enters the cache. These requirements affect implementation and acceptance even after the edition has been chosen.

Training example: an equipment catalogue without a basket

Suppose a company wants 300 equipment pages, articles, certificates and a configuration enquiry form. A salesperson agrees prices; the website creates no order; there is no online payment, reservation or customer account. A 1C exchange has not been approved. The number 300 is illustrative: this is a training scenario, not a SignM case study.

The first option to investigate is an informational catalogue on a lower edition, provided the chosen solution and required modules support it. If a contractor proposes a commerce edition, ask which mandatory scenario cannot otherwise be delivered through the chosen native approach. “You will need it later” becomes a separate future phase with a budget and date.

Now change the requirement: customers must order and pay, while the site receives prices and availability from 1C. This is a different model. Compare commerce editions and confirm the exchange design. Building custom replacements for all commerce mechanisms on a lower edition may cost more than the standard solution. Compare total ownership cost, including maintenance.

Step 4. Calculate the first year and next phase

Calculate two amounts: what is required to launch and what is needed to keep operating. Include licences, setup, migration, testing, the server, backups and integration support. A paid module may have an update period different from the CMS. Do not enter zero for an unanswered item: mark it for clarification.

The edition’s price is not the website’s price. Conversely, expensive development does not prove that an expensive edition is necessary. Ask which tasks are handled natively, which are charged separately and what documentation the owner receives. For custom code, agree source-code handover and recovery instructions in advance.

We do not fix licence prices here: before payment, compare your invoice with the official purchase and upgrade page. For a standard CMS edition upgrade, the manufacturer states that the existing licence changes rather than a new one being issued; active updates are required, and the upgrade does not extend their period. Other products and special programmes may have different terms.

When to postpone a purchase or edition upgrade

Do not buy a second licence until you know who owns the existing one and which installation uses it. Do not upgrade to fix a broken form, slow image or incorrect email template: diagnose the problem first. Do not assume a future free NFR licence is a guaranteed way to cover a commercial purchase; its issue and use are governed by separate terms.

If mandatory functions are unclear, testing one scenario prototype is more useful. For example, send a training enquiry to CRM or show different prices to two test users. This reveals limitations before a complete launch. On an existing project, run experiments on a protected copy with real messages and payments disabled.

Accept the choice and move editions safely

Before payment, retain the product and edition name, mandatory scenarios, confirmation of solution compatibility, licence ownership arrangements and future-cost estimate. Check whether the invoice is for a new licence, renewal or upgrade. These are different items; a shared logo does not make them interchangeable.

For an existing website, first plan the upgrade on a copy. Record versions, back up files and the database, verify restoration, then test new modules and existing scenarios. After deployment, check forms, search, permissions, commerce operations and exchange. Seeing the new edition in the administration panel does not mean the business task is complete.

A rollback plan must account for database changes and new visitor data. Restoring only old files may be incompatible with the updated database; restoring the whole old database may lose new enquiries. Agree the recovery point, maintenance window and preservation of new data before making changes. See the update verification guide for the procedure.

Short glossary and the outcome

• Edition: a platform package with a particular set of capabilities.
• Module: part of the platform or an additional extension; its presence does not replace configuration.
• Product offer / SKU: a specific variant, such as size and colour, that may have its own price and stock.
• Edition upgrade: changing an existing licence’s edition under the manufacturer’s terms.
• Source of truth: the system whose data is authoritative for a particular field.

Complete the requirements worksheet and leave unconfirmed items visible. A choice is justified when every mandatory scenario has an implementation method, a test and a clear cost. Compare specific packages in the Bitrix products section, but bring your requirements matrix to that discussion.

Apply this to your own project

Create a matrix of mandatory scenarios and compatibility evidence, justify the edition and separate licence purchases from implementation and ongoing costs.

1C-Bitrix edition selection matrix: open the worksheet · Download the CSV to complete. Free access, no registration. Use it independently or pass it to your contractor.