A Bitrix update is complete when the website still performs its jobs, not when the installation progress bar disappears: receiving enquiries, showing correct prices, exchanging data and letting editors work. Preparation exposes incompatibilities on a copy and provides a clear recovery route. This guide gives owners a way to brief and accept the work without running dangerous commands on a live server.
Define exactly what is being updated
The platform, third-party solution, custom modules, PHP and server environment are different layers. Changing them simultaneously without testing makes a failure hard to locate. List current version, target version, reason, owner and dependent components. Do not replace this with “update everything to the latest”.
Confirm update entitlement for the CMS and paid extensions. Their periods and rules may differ. The platform manufacturer describes current licence and renewal terms; a ready-made solution’s developer confirms its compatibility. Buying renewal provides the relevant updates but does not test your custom website code.
Record what is already broken. Search may have long failed to find discontinued products, or email may already land in Spam. These are separate defects; otherwise you cannot distinguish a regression from an existing issue after the update. Save reference pages and scenario results before intervention.
Step 1. Test the backup, not just the archive’s existence
You need a consistent copy of the database, code, uploaded files and required settings. Keep an external-dependency list separately: payment service, email, CRM, schedules and file storage. Do not put passwords or keys in a shared report; give the responsible specialist access through private storage.
Check creation time, contents, every archive part and storage location. A database-only backup cannot recover deleted photographs; a files-only backup cannot recover editorial changes or orders. A copy on the same failed disk may be unavailable with the site. Keep at least one accessible copy outside the current installation and define retention.
The official backup creation lesson explicitly explains the limitation of archive integrity checks: successfully checking a file is not the same as restoring a website. Perform a trial restoration in an isolated environment. Record its duration, operator and which scenarios could be opened.
Do not test restoration over the live website. For encrypted backups, ensure the responsible person has the password. Multipart archives require every part. Another specialist should be able to understand the recovery instructions: the updater’s absence must not make restoration impossible.
Step 2. Make the test copy safe
Restrict access to the copy; an indexing prohibition alone is not protection. Immediately check its domain, database and directories: testing must not write to production data. After deployment, disable real emails, payments, CRM messages and exchange jobs until they are deliberately configured for testing.
Retain ways to test integrations through sandboxes, training accounts or agreed stubs. “Everything disabled” protects customers but does not prove payment-handler compatibility. That component needs a separate test scenario. Production secrets must not appear in public files or accompany screenshots.
The copy’s environment should be close enough to production: PHP version, extensions, database, web-server settings and background-job execution. Record differences. Testing another environment is useful, but “works on my laptop” does not prove it will work on the host.
Step 3. Build an acceptance matrix
Select scenarios by business risk. A service website and an online store should not receive the same generic checklist. For each check, specify the expected result and where to see it. “Form opens” is weaker than “Training enquiry is saved and linked to a test CRM record”.
| Area | Action | Verify |
|---|---|---|
| Enquiry | Submit a training form | Record and delivery |
| Catalogue | Select product and variant | Price and availability |
| Editor | Change test copy | Saving and display |
| Integration | Send a training event | One result without duplication |
Also check search, login, account recovery, file uploads, mobile navigation and different role permissions. For a store, add ordering, delivery, discounts and test payments. For a site using 1C, test separate price and stock changes. Do not present real orders or payments as safe tests without an agreed process.
For public pages, save URL, title, canonical, response status and indexing rules. Compare important redirects. The test domain must not enter live links, nor should an accidental indexing prohibition migrate from staging to production. Check pages in the middle of the catalogue too: the home page alone does not represent the whole structure.
Step 4. Update the copy
Follow the manufacturer’s instructions for the chosen version and dependencies. Before each significant stage, record state and installer messages. Do not hide errors by disabling security checks or modifying the core. If a third-party module blocks the update, establish a compatible version or agree a replacement separately.
After installation, inspect application and server logs for the maintenance period. A blank page may correspond to an error entry; a normal-looking page may coexist with background exchange failures. A report needs the time, component, short description and resolution result. Do not publish full traces containing paths, keys or personal data.
Run the scenario matrix on the copy first, then estimate the work duration. If custom code needed changes, include those in the deployment plan. Do not limit deployment to updated files: dependent database changes, settings and migrations also need accounting for.
Training example: the form opens, but enquiries are not saved
Imagine a service site with a custom form. Before updating, training enquiry demo-17 was saved and sent to a training CRM. Afterwards the home page and form look normal and the button reports success, but no new record exists. This is a training example, not a client-project account.
Screenshot-only acceptance would miss the defect. A full-route test finds the discrepancy at the storage stage. The specialist examines the form request and logs for that time, fixes the handler incompatibility on the copy and repeats the scenario. They then test invalid input and repeated clicks so the fix does not introduce another problem.
Production deployment proceeds after successful retesting. A reassuring “We will call you” message or an assumption that an email probably arrived cannot compensate for a lost record. If the form is the main order channel, its failure is sufficient reason to reject the update.
Step 5. Plan the production window and new data
Choose a period accounting for actual enquiries and background operations. Assign the implementer and the person deciding whether to continue or roll back. Define stop conditions, such as unsaved enquiries, incorrect prices or failed login. Set an investigation time limit so maintenance does not expand indefinitely.
Create a fresh recovery point immediately before the change. If updating requires restricting new writes, decide beforehand how visitors will understand the temporary restriction and where to contact you. Avoid a hidden state in which a form promises success while the database is unavailable.
If the site continues taking orders during maintenance, plan how to preserve them on rollback. New enquiries, payments, statuses and files may appear between backup and rollback decision. They do not disappear from the real business when the database returns to yesterday’s state. This requires separate reconciliation, sometimes with external systems.
What a correct rollback means
Restoring files without the matching database may create an incompatible installation. Restoring the entire database may remove new data. A specialist must choose after analysing the changes: restore a consistent set, fix forward or restore selected data while checking relationships. No universal button is safe for every project.
The official backup restoration lesson describes native methods and archive differences. Use it to prepare a procedure on a copy, not as a reason to immediately restore the live database. Service installers and externally accessible archives must not remain on the site afterwards.
After rollback, repeat critical scenarios and reconcile new data. Check schedules: a temporarily paused exchange is easy to forget to resume. Ensure old and new workers are not running in parallel. Record the reason for rollback and conditions for the next attempt, or the team may repeat the same experiment.
Post-release acceptance and avoiding unnecessary purchases
On production, check key pages, one agreed form, administration login and background jobs. Observe the site immediately after switching and after the next scheduled exchange or other important cycle. Compare errors and availability with the baseline. “It did not crash today” is too vague without verified scenarios.
Do not change hosts solely because an update exposed a custom-module error. Do not buy a higher edition for an incompatible function before checking the actual dependency. Do not indefinitely defer necessary security fixes: safe preparation means an organised window and verification, not abandoning maintenance.
A regression breaks a previously working function; staging is an isolated test copy; a migration changes structure or data during a version transition; a recovery point is a consistent file-and-database state. The final report should include before-and-after versions, backup and restoration results, test matrix, discovered defects and remaining limitations. Use the worksheet independently or attach it to a website support task.
Apply this to your own project
Prepare a verifiable update window: versions, restoration, copy isolation, functional checks, stop conditions and preservation of new data on rollback.
Bitrix update plan and acceptance matrix: open the worksheet · Download the CSV to complete. Free access, no registration. Use it independently or pass it to your contractor.