Bitrix website maintenance: what breaks without a maintenance policy
The absence of a maintenance policy does not show up gradually but all at once: the site goes down after an update that no one tested in a staging environment.
Modules accumulate unapplied updates for months, then are installed in one batch and conflict with customized templates and components where changes were made directly in the code.
Rollback is possible only from a backup, and either there is none or it was taken before the manual changes.
The second bottleneck of a website is permissions. Over the years, user groups, extra administrators, open write access to files and folders, and access to information blocks and modules "just in case" accumulate in the system.
One compromised account with such permissions turns into content edits and injection of malicious code, and it is not noticeable from the appearance of the pages.
The third cause is manual edits directly on the production server. Changes in templates, service files, and redirect rules do not make it into the repository, so there is no change history and it is impossible to understand what changed and when.
The cache is not always cleared, and some pages still serve the old version, while the next update overwrites everything that was edited by hand.
All of this is addressed not by heroic recovery but by a planned maintenance policy: a staging environment, staged installation of updates, a verifiable rollback scheme, a permissions review, and moving customizations into the repository.
Let's look at how this is structured in website maintenance on 1C-Bitrix and what regular Bitrix website support provides.
What planned maintenance provides: stability and speed
Planned website maintenance is a policy, not on-call duty "as long as it opens." It includes: monitoring availability and application errors, backups with regular restore testing, updates of the 1C-Bitrix core and modules in a staging environment before rollout to production, access permission control, and closing known vulnerabilities.
The point is to eliminate entire classes of failures. An untested module update, a disk filled up by cache and logs, a scheduled task that stopped running, an expired certificate — all of this is caught by the policy, not at the moment a customer visits.
Website downtime decreases not because of heroics during an incident, but because of a pre-defined rollback: the previous version of code and data is restored from a backup predictably.
Page load speed is maintained by routine, not by one-time optimization. Composite cache is configured by section, heavy database queries are covered by indexes, static assets are served through a content delivery network, and images are converted to modern formats.
After each release, the same metrics are captured as before it — degradation is visible before users complain.
Website fault tolerance is a property of the configuration: multiple application nodes, a separate database, node health checks, and automatic failover.
The result of regular work is recovery from a failure in minutes instead of hours and a clear basis for comparison: what it was, what it became, and what exactly changed.
Work models: one-off edits, a maintenance policy, a dedicated team
The cooperation model is chosen not by the number of edits but by the class of failures it addresses. One-off requests solve a specific task, a maintenance policy removes planned risks, and a dedicated team is responsible for development and load.
The options can be combined: you can keep a maintenance policy on the main environment and engage one-off work for a separate launch.
| Option | When it fits | Limitations |
|---|---|---|
| One-off work by request | A specific edit or incident investigation is needed, and there is no in-house team | Priority depends on the contractor's current workload, knowledge about the project accumulates slowly, and preventive maintenance is not performed |
| Planned maintenance under a policy | A production website needs updates, backups, monitoring, and an agreed response time | Work follows an approved list; urgent tasks outside it are handled separately |
| Dedicated support team | Multiple websites, integrations with an accounting system, ongoing improvements and development | Requires onboarding at the start and regular synchronization on tasks |
| In-house specialist | There is a person who knows the product and processes from the inside | One person is a single point of failure: vacation, illness, or resignation stops the work |
Emergency work is possible in any model, but with one-off requests, recovery time depends on the contractor's workload, while under a maintenance policy and with a dedicated team it is fixed in advance.
Therefore, the model is chosen based on acceptable downtime and the criticality of the environment, not on the volume of edits.
Implementation procedure: audit, scheme, setup, verification, handover
We start work not with edits but with an inventory: what actually runs on the production website, which modules and external integrations are involved, where backups are stored, and who has access.
A website audit provides a dependency map — it shows which core or module update breaks a template, form, or integration with the accounting system.
Work procedure
- We capture the current state: composition of components, third-party modules, scheduler tasks, backup depth, and account permissions. The output is a list of bottlenecks with a risk assessment.
- We deploy a staging environment that replicates the production environment in configuration and data. Updates and edits go through there first.
- We write an update policy: sequence, maintenance window, rollback criteria, and who approves release to the production website.
- We configure backup and rollback: full and incremental copies of the database and files, off-server export, and retention of multiple generations.
- We test the recovery plan in a clean environment — the scenario is considered working only if it has been completed step by step and fits within the target downtime.
- We connect monitoring: availability, errors, database growth, free space, and certificate expiration. We set up on-call duty and the escalation procedure.
- We hand over documentation, access credentials, and policies to your team, or keep on-call duty with us.
After handover, what remains is not a set of one-off settings but a working environment: updates are released according to the policy, backups are taken automatically, and recovery has been tested in practice, not described in theory.
Handover artifacts: access, policies, documentation, diagrams
Website maintenance on 1C-Bitrix ends not with a work report but with a set of documents that your team can use to work independently or hand the project to another contractor without digging through the server and reading code.
We keep this set up to date — with every configuration change, we update the diagram and policies rather than putting them "on the shelf" after launch.
- Infrastructure diagram: environments — production, staging, and export environment; what is behind the load balancer, where the database is, where the queues are, where backups come from, which external services are involved, and at which addresses.
- Access policy: roles and their permissions, where keys are stored, the procedure for granting and revoking access, including the scenario for an employee with administrative rights leaving.
- Website documentation: a map of templates and components, which modules are used and what each is responsible for, where standard logic is edited, and what is overridden in custom code.
- Update policy: the update window for the core and modules, mandatory testing in the staging environment, the criteria for "we roll back," and the procedure for returning to the previous build.
- Instructions for editors: how to add a page, product, or banner, and configure a menu; what is prohibited to change in the markup, and where to go if content does not save.
- Backup policy: what is copied, how often, how long it is retained, how and how regularly restore is tested, and who performs it.
- Change and limitations log: history of configuration edits, known code bottlenecks, and a list of tasks intentionally deferred with justification.
Such a set removes the main risk of maintenance — dependence on a specific engineer. Any new specialist deploys the environment from the diagram, and an editor does not break the layout due to a missing instruction.
Case study: how online store downtime after migration was resolved
The store ran on 1C-Bitrix and moved to a new environment: the database, files, and settings were migrated, and the storefront opened.
A couple of weeks later, it turned out that the migration had only covered the move — under load, the site began going down during peak hours, and recovery each time took half a working day.
What the investigation showed
The task scheduler ran with errors, some handlers were left over from the old environment, and module updates had not been installed for months: each one broke the customized template.
The backups contained archives that had never been tested for recovery, so rollback was done manually from files and logs.
What was changed
Custom modifications were moved into a separate layer so that core and module updates would not affect the template and checkout logic.
Monitoring of availability, queues, and application errors was configured with alerts to the on-call engineer, and backups began to be tested by full restore in the staging environment — once a week, according to the policy.
What the result was
Recovery time dropped from several hours to 20–25 minutes: an alert triggers, the on-call engineer brings the service up according to the instructions rather than searching for the cause from scratch. Emergency callouts went from three or four per month to zero or one.
Unapplied updates — zero: they are installed on schedule in a night window, with prior testing in the staging environment and the ability to roll back.
This mode is maintained not by administrator heroics but by the policy: it is clear who does what during a failure, what exactly is being updated, and how to return to the previous state.
Common technical questions about support and updates
Before handing a website over for maintenance, customers ask the same engineering questions: what will happen to customizations after module updates, to whom and with what permissions should admin access be granted, and is it really possible to bring the site back up after a failure.
Below are short technical answers without general words about "transparency" and "care."
What will happen to customizations after module updates?
We update on a copy — a staging environment with the same settings and data. If a manually edited module or template breaks, that is visible before deployment, not on the production website. Before release, we take a full snapshot of the database and files, so rollback takes minutes.
How do you handle access permissions?
We separate roles: administrator, content manager, developer — each gets the minimum permissions for their tasks. Access is personal, admin logins are recorded in the log, and when an employee leaves, access is revoked precisely, without changing passwords for the whole team.
What do you do for website security?
We install critical patches out of turn; the rest — as a package with compatibility testing. Typical entry points — forms, file uploads, public scripts — are closed or restricted.
We store backups separately from the production server: the site can be brought up even if hosting is unavailable.
How quickly do you respond to a failure?
Incidents have priority: first website unavailability and domain hijacking, then errors in orders and payments, then cosmetic issues. We record the cause of each case in the log — a repeat failure does not require finding the solution again. This is how regular website maintenance works, not one-off edits on a phone call.
Let's discuss the task: we will get back with an estimate and work plan
An estimate for website work should be based on facts, not assumptions.
Therefore, we start with an analysis of the current state: server configuration, version of the 1C-Bitrix core and modules, error logs, backup scheme, and the state of the database and third-party integrations.
Based on the results, we come back with a work plan — what we address first, what can wait, and which risks we remove in the first month of maintenance.
Project handover and the start of maintenance follow one scenario: inventory, access, policy, assigned engineer. As a result, you receive:
- a phased work plan with priorities and clear completion criteria;
- an infrastructure map: servers, domains, DNS, certificates, email, external services;
- an access matrix and the procedure for granting and revoking it, including for contractors;
- an update policy for the core and modules with maintenance windows and rollback points;
- a backup scheme with restore testing, not just backup creation;
- an incident handling procedure: communication channel, response time, responsible engineer.
Describe the task and how the website currently runs — we will get back with an estimate, scope of work, and timelines. If during the analysis we see something urgent, we will say so directly, before work begins.
How planned maintenance differs from work by request
The difference between the models is visible at the starting point of work: with work by request, we engage only after a request; with planned maintenance, according to the policy and before a customer notices a failure.
What differs is not response speed but the response mode: who discovers the problem first and how long it remains unnoticed.
The Bitrix website maintenance policy defines frequency and scope: daily checks of availability and error logs, weekly verification of backup integrity, updates of the core and modules first in the staging environment, and monitoring of domain and certificate renewal deadlines.
Each procedure leaves a trace — a report with the result, so the website's state is known from history, not from memory.
The reactive model shifts the cost of failure to the customer: downtime consists of the time until detection, diagnosis, and recovery. If the website accepts orders or requests, lost inquiries accumulate while the investigation is underway.
A separate risk is skipped updates: jumping across several major versions of the core and modules at once is more difficult and riskier than sequential installation.
Work by request is appropriate where the website is stable: rarely changing content, no integrations with an accounting system, and no payment acceptance.
Here, a permanent maintenance policy is excessive, and modifications are handled as one-off tasks without ongoing maintenance.
In practice, a hybrid more often works: preventive maintenance under a policy plus one-off requests for improvements and new sections. The choice is determined by how much an hour of unavailability costs and how critical the data collected by the website is.