Safe Bitrix Module Update Procedure: Risks & Neutralization
A month before launching an online store on Bitrix, you need to update the sale module due to a vulnerability. You click "Update" in the admin panel — a minute later the cart stops working. Does this sound familiar? We've encountered this dozens of times across 200+ projects. We developed a procedure that eliminates downtime and data loss. Financial losses from a failed update can reach millions if you don't prepare. We guarantee stable operation after updates and a well-tested rollback mechanism. For example, in one project, an update of sale led to the loss of 50% of orders within an hour — we restored everything in 30 minutes thanks to a backup. In 95% of cases, issues are identified on staging. Our certified engineers accompany updates at every stage: from dependency analysis to post-deployment monitoring.
Problems We Solve
The main pain point is incompatibility of old code with new module versions. Typical scenarios:
-
Sale module. After update, discounts stop applying, orders drop. The reason: the call order of
OnSaleOrderBeforeSavedchanged, and the custom handler doesn't fire. We've seen this on projects with 10,000+ orders per day. - Catalog module. Faceted search breaks or the price displays incorrectly. This happens if a custom price provider doesn't match the new interface.
- Third-party modules from Marketplace. The developer released an update with breaking changes without a changelog. Or the module hasn't been updated for a long time and loses compatibility with the core. Before updating, we read the changelog — if there is none, it's a red flag.
How We Update Modules
Our stack: Bitrix (CMS), PHP 8.1+, MySQL/MariaDB. For each project, we use staging — an exact copy of production. We perform the update via console: php -f /bitrix/bin/console module.update --module=catalog. The console method is more reliable: no time limit, no browser dependency. According to official Bitrix documentation, console updates minimize the risk of errors.
Case from practice: we updated the sale module on a site with a custom delivery module. On staging, we found that the new code was incompatible with a custom handler of the OnSaleDeliveryServiceBuildList event. We rewrote the handler in 2 hours, and the update went smoothly. In 90% of cases, early detection of conflicts on staging eliminates production downtime.
Comparison of Update Methods
| Method | Reliability | Speed | Control | Failure Risk |
|---|---|---|---|---|
| Via admin panel | Low (depends on browser) | Fast | Minimal | High |
| Via console | High | Faster | Full | Low |
| Automatic (via updates) | Medium | Fast | None | Medium |
Our Work Process
- Analysis — study current modules, custom modifications, integrations (1C, acquiring, CDEK).
- Backup — database dump and copy of module files.
- Staging — reproduce the update and test critical scenarios: order placement, adding to cart, discounts, authorization.
- Production update — during quiet hours, in maintenance mode.
- Monitoring — after the update, check error log (
tail -f /var/log/php_errors.log) and site functionality.
Checklist Before Module Update
| Action | Importance |
|---|---|
| Full backup of files and database | Critical |
| Review module changelog | High |
| Staging testing | Mandatory |
| Notify team about possible downtime | Standard |
| Prepare rollback mechanism | Critical |
What's Included
- Full backup before the update
- Staging setup and testing
- Production module update per agreed scenario
- Monitoring for 24 hours post-update
- Documentation: list of changed modules, versions, identified risks
- 30-day guarantee on correct operation of updated modules
- Service price is calculated individually, depends on volume and complexity of custom code
Approximate Timelines
| Scenario | Timeline |
|---|---|
| Update 1-2 modules, standard site | 0.5-1 day |
| Update multiple modules + testing | 1-2 days |
| Update sale/catalog on a site with custom code | 2-5 days |
| Mass update after long downtime | 1-2 weeks |
Why Choose Us
We have been working with Bitrix for over 10 years, completed more than 200 module update projects, including complex integrations. All our specialists are certified. We provide a written guarantee on module operation after updates.
How to Roll Back a Module Update Without a Dump?
Rollback without a DB dump is practically impossible: updater.php scripts rarely have rollback logic. The only way is to restore module files from backup and the DB dump made before the update. Therefore, a DB backup is not a recommendation but a mandatory requirement.
Why Is Updating the sale Module the Most Risky?
The sale module handles order placement, discounts, and cart. An update can change events and methods that custom code depends on. Even a minor update can break discount calculation logic or create an order with an error. In our practice, an update of sale led to duplicate discounts due to a change in the call order of OnSaleBasketItemAdd.
Contact us — we will assess the risks of your project and offer the optimal solution. Get a consultation on Bitrix module updates. Order module updates today — we guarantee safety and stability.
Additional information: 1C-Bitrix (Wikipedia), Update documentation.