1C-Bitrix core update: audit, staging, 30-day warranty

Why a 1C-Bitrix core update breaks a working site

A 1C-Bitrix core update rarely fails on its own — the wizard reports success. What breaks is the desynchronization: the core moves to a new branch, while some modules remain on the previous one because an update for them has not yet been released or is not covered by the license.

This leads to module conflicts after the update — the admin panel opens, but public pages return an error.

The second source is edits in the source code. While the site is live, templates, components, and handlers are modified directly, including inside the core.

The update overwrites these files: customizations disappear, and if a file survives but relies on a changed internal interface, the site will not open after the update — a white screen or a 500 on everything, including checkout.

Version incompatibility manifests more quietly and is therefore more expensive.

An outdated third-party module, a custom component template, integration with 1C — all of this can survive the update but break in a pinpoint way: emails stop being sent, cart items are duplicated, the integration does not pick up new orders. This is noticed a day later, when some of the inquiries have already been lost.

The cost of a breakdown is not hours of downtime, but the orders that did not happen during those hours, and pages that dropped out of search while the site was returning an error.

A rollback without a saved copy and a set of compatible versions is already impossible: the database has run on the new core. Below we break down how this is addressed — from module inventory and a test environment to a rollback plan.

What planned platform maintenance delivers

Planned maintenance is a work schedule instead of reacting to a failure. Core and module updates for 1C-Bitrix are rolled out in batches, each batch goes through the test environment on a copy of the production database, so the site remains available to customers. Below is what exactly changes in measurable metrics.

Downtime duration: minutes instead of days

We schedule work in a low-traffic window, checking the backup and rollback scenario in advance. An update on the production environment takes 15–30 minutes, whereas emergency recovery after an unsuccessful manual update usually stretches into hours or days. An agreed window eliminates late-night firefighting and downtime during sales hours.

The eliminated class of failures

The bulk of failures after an update are incompatibility of custom handlers, outdated calls in templates, and conflicts of cache and access permissions.

These cases are caught in the test environment: first we run the batch on the copy, compare error logs, and only then transfer it to the working site. What goes to production is a version that has already run under load and passed checks of key pages.

Sales stability

We separately check the customer journey: catalog, cart, checkout, payment, customer account. An error here costs not reputation but revenue, so after each batch these scenarios go through the same set of checks. The share of orders completed without failure stops depending on the next release.

Predictable timelines and reversible rollback

Work follows a quarterly plan: it is known what and when we update, how long it takes, and who is on duty. Every step is reversible — returning to the previous state takes minutes rather than requiring manual untangling of the consequences. At the end, the customer receives a report with a list of changes and a log of checks.

Comparison of approaches: wizard, manual installation, copy

A 1C-Bitrix core update can be performed in four ways, and the choice between them determines not the speed of work but the risk class.

The standard wizard is suitable for projects without core edits, manual patch installation for pinpoint fixes, a test copy for sites with integrations and traffic, and phased migration for large releases that cannot be rolled out in a single window.

What we use as a guide when choosing

We look at the share of modified core files, the presence of automated tests, and the allowable downtime window. If there are no core edits, the standard wizard run on a copy is sufficient.

If the project has grown over with integrations and data exchange with an accounting system, there is only one safe path — a test copy with phased migration and state capture before and after each step.

How the core migrates to a copy: work stages

A 1C-Bitrix core update rarely goes "in one click" on a live project: edits in the template, third-party modules, and data exchange with the accounting system hook into internal calls that may no longer exist in the new branch.

That is why the migration proceeds step by step, and each step has a point of return to a working state.

1. Audit of edits and modules. We compare the core files with the reference distribution, record modified components, child templates, and module dependencies — we get a map of what the update will affect.
2. Migration scheme. We set the order: what is updated together with the core, what separately, where manual intervention is needed. Rollback points are also defined here.
3. Building the copy. We deploy the project on a separate server — database, files, settings, scheduler jobs. Mailings and integrations are disabled so that checks do not go out to live customers.
4. Installation on the copy. We update the core and modules, transfer edits to the new code, and resolve conflicts.
5. Checking on the copy. We run critical scenarios: ordering, authorization, payment, data exchange with the accounting system, admin panel. We compare error logs and response time before and after.
6. Transfer to the production environment. We work in a maintenance window: a snapshot of the database and files before the start, the update in the same sequence, monitoring logs in the first hours.
7. Rollback procedure. We describe the return to the previous state, hand over the edit map and instructions for future updates.

This way, an update stops being a lottery: changes are verified on the copy, and the decision to roll back is made according to a document.

What remains with you: configuration, schemes, procedures

After the update, the team keeps not only a working site but also a set of artifacts that make the next update predictable — without digging through logs and questioning those who "changed something by hand." We hand everything over in your repository and as readable documents; access remains with you.

• Core version map — what is installed on the production and test environments, which modules have been updated, which are pinned and for what reason.
• List of edits — changes in the core, templates, and handlers linked to tasks: on the next update it is immediately clear what needs to be transferred again.
• Recovery points — snapshots of the database and files before each step, indicating what exactly is rolled back and in what sequence.
• Update documentation — the order of steps, checks after each stage, known limitations, and workarounds.
• Maintenance procedure — frequency of updates, coordination of the work window, what is checked before and after, and in which cases the update is postponed.
• Acceptance checklist — scenarios by which functionality is confirmed: orders, payment, forms, data exchange with the accounting system.
• Configuration change log — affected settings, access rights, and email templates.

Case study: migrating to a new branch without stopping sales

What it was before

A site with a catalog of several thousand items, a B2B customer account, and order export to 1C was updated once every year to a year and a half; the 1C-Bitrix core lagged several branches behind.

Each installation took a night window from 23:00 to 5:00 — six hours during which the storefront, cart, and data exchange with the accounting system were unavailable.

Of the nine previous updates, four ended in a rollback: catalog component templates, custom event handlers, and the 1C exchange broke.

What we changed

We brought the production site and the test environment to a single state: a snapshot of the database and files is transferred to the copy in full, together with orders and exchange settings.

The update is rehearsed on the copy — conflicts in custom catalog edits are recorded, and a regression set is assembled from the paths that broke most often: checkout, export to 1C, payment integration, customer account. The work was split into two passes — first the core, a week later modules and templates.

What the result was

The work window was reduced to 40 minutes instead of six hours, and storefront downtime to 10 minutes for traffic switching: the rest is checked on the copy.

There have been no failures after installation in the last four updates, whereas previously almost every second pass failed. If a rollback is still needed, it returns the previous release and database snapshot by switching, not by restoring the site piece by piece.

What to do if edits were made directly in the source code

Edits made directly in core files are the most common source of failures during an update.

The core overwrites the modified file with the reference version, and the customization disappears silently: the update goes through, but a few days later the order form stops working or the export to the accounting system breaks.

The longer the edits lived in the core, the more expensive it is to restore the logic — no one remembers from the code why it was changed.

First we capture the full picture: we compare the file versions of the working site with the reference core of the current branch — line by line, not by modification date.

This separates stock code from customized code, and a list appears of places where the logic diverges from the core. We describe each divergence: what it does, which process it supports, and what will happen if the reference version is restored.

Next we move the changes outside the core — to where the update will not affect them. Most customizations come down to event handlers, a custom module, component templates in their own namespace, and overriding output templates.

What cannot be moved out we formalize as a conscious patch: with a description, version binding, and a note in the log.

Protecting customizations is a procedure plus automation: integrity control of core files on the test bench and on the working site, a ban on edits in the core directory for developers, and an inventory of patches before each update. A core update stops being a risk: changes are either already moved out or are known in advance.

Concerns about compatibility, rollback, and the work window

Before a core update, the customer keeps three risks in mind: third-party modules, the absence of a way back, and downtime. The concerns are not abstract — they account for the majority of incidents during an update. We explain how each of them is addressed before work even starts.

Separation of environments removes most of the risk in advance: a full copy of the production environment with the same modules, permissions, and 1C exchange is updated first and goes through a full cycle of checks.

How is the rollback plan structured?

It is written in advance: a checkpoint of the database and files, the order for returning the core and modules, conditions for triggering a rollback, and the person responsible for the decision.

This is a numbered procedure that returns the environment to its original state in minutes, not in hours of searching for the cause.

What work window will be required?

The main part is preparation, which proceeds without stopping the site. Downtime is needed only for deployment: we agree on a window at minimum traffic, and it lasts tens of minutes. For 24/7 projects, we split the deployment into stages while maintaining availability.

How do you verify the result after the update?

The re-check follows a checklist: user scenarios, admin panel, 1C exchange, access rights, error log, and response. We compare with control points taken before the work, and a few days later we go through the logs a second time — this is how rare scenarios are caught.

Let's discuss your task: estimate, work plan, guarantee on changes

To discuss the task substantively, a full audit is not needed — what you already have is enough.

The more specific the inputs, the more accurate the work estimate: when updating the 1C-Bitrix core, we look not at wishes but at the actual project configuration, third-party modules, and edit history.

At the start, send us:

• an archive of the site or access to the test environment: core, template, custom modules, database dump;
• a list of customizations that modified the core, components, or templates directly;
• error and slow query logs for recent weeks — they show what will surface after the update;
• description of integrations: 1C, CRM, warehouse, payments, external services;
• work window constraints: allowable downtime, peak load hours, who confirms the release.

In response, we will come back with an estimate and work plan: a module dependency map, update order with rollback points, and a breakdown by stages and labor costs.

We discuss the access transfer procedure separately — through a secure channel, recording who has access to what and when it is revoked.

The work is accompanied by a guarantee on changes: if after a core update a defect appears because of our edits, we fix it within the agreed period, without a separate round of approvals. Describe the task — we will come back with an estimate and a plan.