Migrating 1C-Bitrix Start to Standard: where development hits the ceiling
The junior Bitrix edition — Start — is designed for a storefront with a few dozen items and one administrator. While the site works as a landing page with a price list, these capabilities are enough.
As soon as inventory accounting, a second manager, or integration with an accounting system appears, the limitations of the Start edition begin to slow down every task — migrating 1C-Bitrix Start to Standard becomes a matter of the site's operability, not convenience.
The first thing development hits is integration with 1C. Start does not have full two-way exchange of catalog, stock, prices, and orders: data is transferred manually, and discrepancies between the site and accounting accumulate until the first reconciliation.
This point most often hinders site development — prices become outdated, the manager has to check with the warehouse, and the customer receives an order for an unavailable item.
Second — catalog size and structure: the number of information blocks is limited, there are no multiple properties or flexible filtering, and the product range has to be packed into a flat list.
Third — role separation: the content manager, order operator, and administrator work under one account, and editing content can affect site settings.
Changing the 1C-Bitrix edition is not a reinstall but a project migration: content, structure, template, and accumulated settings are preserved; only the license level changes. Below we break down what exactly Standard covers and what steps are needed for the migration.
What is removed after the edition change: the effect in numbers
The Standard edition in 1C-Bitrix removes two technical ceilings: built-in exchange with an accounting system and role-based access rights at the catalog section level.
While these are absent, the catalog is maintained manually and access is granted as "everyone gets everything" — hence the main share of manual operations in support.
Uploading the catalog from the accounting system stops being a one-time event: the exchange runs in batches and transfers only changed items. A catalog with several thousand products synchronizes in minutes, not overnight, and price and availability come from a single source. Manual card creation is reduced to isolated exceptions.
The class of failures during exchange also changes. The session records checkpoints: an interrupted upload continues from the break point instead of restarting the entire catalog, and discrepancies are visible in the log, not from customer complaints. The load on the catalog stops being peak — a full synchronization does not block the storefront.
Role-based access rights are configured once: the content manager edits descriptions, the manager edits prices and availability, and the contractor edits only their own section.
A new role is granted by changing one setting, not through back-and-forth in a messenger, and onboarding an employee into the system takes minutes instead of hours.
We measure the effect of the edition change by three metrics: the share of manual operations during exchange, the time of a full catalog upload, and the number of access requests. We check them immediately after the migration — on the production catalog, not on demo data.
Migration options: comparing approaches and limitations
The Start edition is cut down in the number of sites, catalog handling, and performance tools — sooner or later these limits start to get in the way.
In 1C-Bitrix, migration to Standard can be done in four different ways, and the choice is determined by the state of the database and how long the site can be unavailable.
| Option | When it fits | Limitations |
|---|---|---|
| In-place update | Clean database, no core modifications, a couple of hours of downtime acceptable | Inherits old errors and extra modules; rollback only from a backup |
| Migration to a clean copy | Many layers, old core, need a controlled result | Longer: modules, rights, and template are configured anew, data is transferred in full |
| Phased migration by sections | The site cannot be stopped, functionality is separated by section | Some sections live by the old logic, compatibility between stages must be controlled |
| Two parallel environments | Need a trial run and comparison of results before switching | Double administration and risk of data divergence, the longest preparation |
An in-place update saves time, but it carries into the new edition everything accumulated in the old one. A clean copy gives a predictable result, but requires a full migration and reconfiguration of rights.
We first raise a test copy and run the migration on it — this shows which option actually fits within the project's constraints. Then we state the timeline, scope of work, and rollback points.
Work sequence: from configuration audit to handover
Changing the edition is not a reinstall but a migration of a live configuration: some modules that in Start were connected as separate solutions work natively in Standard, but the template, information block properties, and customizations have to be rechecked. That is why the work follows a fixed sequence — each stage is closed with a verifiable result.
- Site configuration audit. We take inventory: modules, components, template, information block properties, third-party code. We separately note customizations that in the new edition are replaced by a native mechanism or conflict with it.
- Data migration scheme. We fix the composition and order: information blocks and sections, products with prices and stock, orders and statuses, users with access groups. For each object — a matching rule and what we do with discrepancies.
- Standard edition setup. We deploy the environment on a copy, enable the required modules, migrate the template, and differentiate rights by role. We separately go through caching and performance settings.
- Checking integration with the accounting system. We reconcile products, prices, stock, and order statuses after each upload cycle. We resolve discrepancies down to zero so that repeated synchronization does not create duplicates.
- Regression on the test environment. We run key scenarios: search, cart, checkout, payment, personal account, forms. The criterion is that the result matches the site's previous behavior, not whether it "clicks."
- Project handover to the customer. We provide access, the exchange scheme, a description of the structure and settings, instructions for the content manager, and a backup policy. Then follows an observation period, when edits are already made on the production environment.
This sequence eliminates the main risk of migration: discovering that part of the data or rights was not transferred after the switch.
Set of documents, accesses, and settings on delivery
We close the migration to the senior edition not by issuing accesses but by handing over a working environment: using it, your administrator or a third-party contractor will be able to develop the site without us.
Below is the set that remains with the customer: configurations, schemes, policies, and instructions are described so that they can be acted on, not guessed at.
- Configurations and exports — settings of modules, template, information block properties, and processing rules; stored in a version control system, so changes are comparable between releases.
- Integration map — a list of external systems, exchange direction, data format, launch frequency, and the place where exchange most often breaks.
- Access rights matrix — user groups, roles, what each sees and changes, who is responsible for granting and revoking access.
- Data exchange policy — what is synchronized with the 1C accounting system and how often, behavior on discrepancy, and the procedure for restarting after a failure.
- Settings documentation — which parameters to change for a task, where they are located, and what will stop working if the value is incorrect.
- Site administrator instructions — typical operations: publishing a page, editing the catalog, managing users, taking a backup before changes.
- Change log and rollback plan — what changed and when, and how to return to the previous state in one step.
Case study: removing limitations on an existing project
The project is a distributor of industrial automation: a main site, a separate channel for partners, and a catalog with stock from the warehouse.
On the Start edition, the system hit a ceiling: the partner site lived as a separate 1C-Bitrix installation, which meant the catalog and access rules had to be maintained in two places, and managers reconciled stock manually.
Before the work, we recorded baseline measurements so that after the migration we could compare numbers, not impressions.
| Parameter | Before (Start) | After (Standard) |
|---|---|---|
| Sales channels | Two separate installations, edits were duplicated | Two sites on a shared core, a single catalog |
| Stock updates | 6-8 manual uploads per week | Native scheduled exchange |
| Granting access to an employee | Up to two days of back-and-forth | 15-20 minutes via user groups |
| Downtime due to exchange | Up to four hours with manual reconciliation | Auto-retry and log, up to fifteen minutes |
The main failure class removed is not an individual error but the very dependence of the storefront on a manual operation: until an employee started the upload, partners saw outdated stock.
After the migration, exchange runs on a schedule, with logging of each session, auto-retry on disconnection, and notification to the responsible person on discrepancy.
We measured recovery separately: previously, after an exchange failure, someone had to manually determine which items diverged and reload the data — that is what caused hours of downtime.
Now the divergence point is visible in the log, and a retry is initiated without analyzing uploads, taking minutes. Access rights have ceased to be a bottleneck altogether: access is described by a role, not by a set of files.
What to do if the site is already deployed on the junior edition?
Yes, the migration is performed on a live project — the edition changes at the level of the license and the set of connected modules, not by reinstalling the site.
The database, files, template, catalog, and all customizations remain in place, so a site on the junior edition moves to the senior one without rebuilding the structure or refilling content.
The procedure for a live project begins not with the update but with recording the current state: we take a full backup — a database dump and the file part — and deploy it on a separate environment closed from indexing.
There we change the edition: it is visible which modules are enabled and how custom components and templates behave. Only after a successful run of key scenarios do we transfer the changes to the production site.
Preservation of customizations is ensured by the fact that user code lies in separate folders and is not overwritten when the edition changes.
Some custom solutions become redundant after the upgrade — native modules cover the same tasks more reliably and with less load on the server.
We do not break what works: first we migrate the project as is, and we replace customizations with native mechanisms in separate steps, when there is a gain in speed or stability.
Migration without stopping the site looks like this: on the production environment, the license is changed and modules are enabled, the cache is reset, and search is reindexed — this takes minutes, not hours.
During this interval, visitors can be served a copy or a short stub if the regulations require it. Page addresses, metadata, sitemap, and texts do not change, so accumulated search positions are preserved. If the catalog structure changes for the new modules, we close the old addresses with a redirect.
Technical doubts before changing the edition
Changing the edition is not a reinstall but a migration of the configuration to a different platform line. Before starting, we fix five points on which the customer and their engineers most often have questions — from the fate of content to the ability to roll back.
Will content and data survive the migration?
Everything is transferred in full: information blocks, products, orders, users, properties, and access rights. The structure and identifiers are preserved, so page addresses and external links remain the same — no search re-crawl or advertising campaign edits are needed.
Will the site have to be closed during the work?
The main scope — preparation and checks — happens on a copy, while the production environment keeps running. The switch takes one maintenance window during the night, when orders and inquiries are minimal. We announce the switch in advance and stay in touch throughout the period.
What will happen to customizations for the junior edition?
We check components, event handlers, and custom modules for compatibility. Some solutions that were previously written by hand are already included in Standard — we do not transfer them, so as not to duplicate logic. Only what is truly unique to your process remains, and it migrates without loss of behavior.
Will the template have to be redone from scratch?
The layout and template structure are transferred. Rework is needed in a targeted way — where the junior edition limited output: usually these are catalog, cart, and personal account blocks. We provide an estimate of the scope before the work starts, not along the way.
Is it possible to roll back?
Yes. Before the work, we take a full snapshot of the database and files, so returning to the original state is possible at any stage.
After acceptance, the snapshot is retained — if the new edition does not satisfy in some way in actual operation, rollback remains a real scenario, not a theory.
Let's discuss the task: what we need from you for an estimate
To estimate the migration of 1C-Bitrix Start to Standard, you do not need a forty-page document — the input data you already have is enough.
The basic set below covers almost all questions about the scope of work: we clarify the rest in a targeted way and come back with an estimate, work plan, and timeline.
- current edition, list of installed modules and third-party solutions that depend on it;
- access to the admin panel and a current backup of files and database — with them, the estimate stops being a guess;
- list of customizations: where the core was modified, which templates and scripts are tied to Start limitations;
- external integrations — with 1C, warehouse, delivery service, payment systems, newsletters;
- load: catalog size, number of orders per day, average and peak traffic;
- server configuration and availability of a test environment where the migration can be run before production launch;
- the date by which the updated site must be working, and periods when a brief access restriction is acceptable.
We select the project team based on this data: core migration, transfer of modules and template, checking integrations, and acceptance on the test environment require different sets of specialists.
Describe the task in a convenient form — we will come back with an estimate, the sequence of stages, and options for completing the migration with minimal downtime for visitors and orders.