Safe CMS and plugin updates: protocol with backup and rollback

Why a CMS update breaks a working site

A CMS update looks like one button, but it's not the core that breaks the site—it's the bundle: core, extensions, and theme depend on each other. An extension relies on internal core calls and writes to its own tables; the theme overrides output templates.

While versions are aligned, this isn't visible—the mismatch manifests exactly at the moment of update.

Most common failure—extension conflict after update. The core changes internal interfaces, the plugin continues to call the old method and returns a white page or server error where it outputs its block: in a form, product card, feed. The rest of the site works, so the breakage isn't noticed immediately.

Second scenario—layout broke after edits. Changes made directly to template files are overwritten by the update with the theme package: only what is moved to a child theme remains. Custom markup, added fields, and editor modifications go away with these files.

Third—orphaned tables from an updated or removed extension. Old data remains in the database, the new version writes to its own structures, and pages show duplicates, empty blocks, lost relations.

This is the error on pages after update that people look for in layout, though the cause is in data.

All this is exposed only on a live site: a copy rarely reproduces the full set of extensions, cache, database volume, and accumulated markup.

That's why we build zero-downtime CMS update not around "click update" but around a database and file snapshot, checking key scenarios on a copy, and a ready rollback—we explain how this is covered.

What a managed release pipeline on a site delivers

A controlled change pipeline is the same route for every edit: a separate branch in Git, automatic build of a copy, staging check, scheduled transfer to production. What the client gets as a result—we list in measurable terms, not promises.

Reducing the scheduled maintenance window

• Transfer of changes takes minutes instead of hours of manual deployment: the artifact is built automatically, no human participates in this step.
• Scheduled work is placed in a low-traffic window and doesn't stretch all evening: if a check fails, repeated transfer follows the same route.
• Rollback to the previous build takes seconds, so switching doesn't turn into a separate operation with downtime.

Eliminating an entire class of failures after edits

• An edit to a separate block, page, or template doesn't affect the rest of the site: the boundaries of changes are visible before transfer.
• The failure class "a section broke after an edit" disappears—staging checks catch it before production transfer.
• Restoring from a copy takes a few minutes, not hours of searching for the cause, so repeat emergency visits for the same issue don't remain.

Together, these effects produce predictable site releases: the share of changes reaching production without after-the-fact fixes grows, and the number of emergency rollbacks falls.

The pipeline is documented and repeated with each CMS update—a new engineer enters the same process rather than inventing their own.

CMS update formats: comparison of approaches

A CMS update is not one button but a choice of mode in which the site lives on. The difference is who transfers changes to production: an engineer using a checklist, a semi-automatic pipeline with a log, or a procedure that doesn't touch the core.

Manual mode with testing on a copy

A test copy of the site is raised from a snapshot of the database and files—the update is run on it, not on production. The engineer walks through the scenarios that most often break a CMS update: forms, search, authorization, connections to external services. Before transfer, a snapshot is taken for quick rollback.

Automatic mode and its boundaries

The automated update pipeline keeps a version log and rolls back itself if key checks fail after an update. The boundaries are simple: it handles security patches without an engineer, while major core versions and plugin conflicts are brought to manual review.

Freezing component versions is a separate mode: it is useful as long as the update list is controlled, and dangerous when it turns into refusing them.

Work stages: from audit to handover of the procedure

Engineering work on an update rarely begins with the update itself—first you need to understand what you're updating and what you're risking.

A site audit before work answers three questions: which components and versions are installed, where data lies, what depends on outdated extensions. Without this step, running changes becomes a matter of luck.

Audit and inventory

1. Inventory: list of core, extensions, themes, and third-party libraries; we note what hasn't been updated for years and where core version requirements diverge.
2. Backup scheme: a full snapshot of files and database; configuration and routing rules separately. For large storages we add incremental capture so the snapshot takes minutes. We verify the copy by restoring it: an unchecked archive does not count as a copy.

Testing on a copy and rollback conditions

• We raise a test copy in an isolated environment—its own address, database, and access keys—so the production environment isn't affected.
• Run changes on the copy: we update the core and extensions one by one; after each step we read error logs and check compatibility.
• Checking key scenarios: login and roles, forms, payment, search, catalog output, exchange with external services.
• We define rollback conditions in advance: return point, recovery time, and signs of failure. If a scenario fails—we return to the previous version without dealing with consequences for live users.
• Handover of the procedure: what and how often we copy, in what order we update, by what signs we trigger rollback.

Documentation and artifacts you retain

After each release you retain text artifacts by which your engineer can perform a CMS update without us. The documents live in the repository next to the code—not in a separate folder that becomes outdated in a month.

Procedures and instructions

• Maintenance documentation — which modules we update on schedule, in what order, what we check before and after.
• Site extension map — list of extensions and links between them: it shows what updating one node will pull along.
• Backup scheme — what goes into a copy (files, database, configurations), how often, where it is stored, and how recovery is verified.
• Scheduled work procedure — update window, run on a copy, transfer to production, point of no return.
• Change rollback instructions — step by step: which artifact to restore, with which command, by what signs to confirm the site is up.
• Work acceptance checklist — forms, login, order placement, external integrations: paths that are walked manually after each update.

Access and permission separation

• Control panel access policies — administrator, editor, and contractor roles, minimum required permissions, separate accounts instead of a shared one.
• Access rotation procedure — what to do when an employee leaves or the team changes: revoke keys, reissue, login log.
• Access recovery — where backup codes are stored and who to contact if the panel is unavailable.

Case study: how we reduced downtime during scheduled work

The client handed us support of a site—an online store on 1C-Bitrix with a catalog of several thousand items.

Module and core updates were installed "as they were released," without a fixed window: edits went to production during business hours, and if something broke, the cause was sought on the live site.

Over a quarter, five repeat requests accumulated for the same breakdowns—we treated the symptom, not the cause.

What it was like before

The share of edits that went into rollback held around one third: the update was installed directly on production, and on a dependency conflict the site was restored from the last backup. The copy was taken manually and not always—if it wasn't made, recovery stretched for hours.

The scheduled maintenance window took 4-6 hours, and all that time the catalog and order placement were unavailable.

What changed after implementing the procedure

We introduced a mandatory sequence: snapshot of the database and files, deployment on a copy of production, run of order and payment scenarios, and only then deployment. Rollback became an operation of a few minutes—return to the previous snapshot without manual assembly. Repeat requests for the same breakdown stopped: each was closed with the cause recorded.

What to do if the site breaks after an edit

The first action on a breakdown is to stop edits, not make new ones. While the site returns an error, every next patch on top of the broken state erases evidence: logs are overwritten, cache warms up, the cause blurs.

We record the state: take a copy of the database and files, save server and application logs for the last 24 hours, write down the list of changed files with edit time. If there is a maintenance mode—enable it so visitors see a neat placeholder instead of errors.

Next we look for the last known working state. Usually this is a restore point from a backup before the edit, less often the previous release in the version control system.

We compare it with the current one: a difference in several files points to the direct cause, a difference in the database schema—to an incompatible migration.

We restore from backup not on production but on a separate copy: this way we see that the breakdown goes away, and we can still retrieve data that managed to be written to the broken version.

We isolate the cause by dividing: revert changes in half and see on which half the failure returns. At the same time, we check the adjacent layers most often to blame in edits—cache, redirect rules, file permissions, extensions.

The error log speeds up the search for the cause of the failure: a line with a fatal error and edit time almost always points to a specific file.

After recovery we analyze the incident on the site: why the problem didn't appear on the test environment, why monitoring signaled not immediately, how the edit got to production bypassing the procedure.

Based on the results we change the workflow—a copy before every edit, rollback check before publication, a test environment with a database copy, and a ban on direct editing on production.

Common technical concerns about the work procedure

Concerns relate not to the procedure itself but to its boundaries: what exactly is affected, what remains untouched, and how quickly the previous state can be restored. Below are the questions most often asked before starting CMS update work.

How is compatibility of site extensions checked?

We compile a list of extensions and compare it with the target core branch, then install everything on staging and walk key scenarios. Incompatible ones are replaced or left on the previous version until a working one appears.

What are backup retention periods?

A copy is taken before each update and lives until the stability of the next step is confirmed: database, files, configuration. Then—according to the retention policy: latest points in fast access, monthly snapshots kept longer.

Is partial updating of components possible?

Yes, core, theme, and extensions are updated separately—this reduces risk. One limitation: some extensions require a minimum core branch, so the order of steps is determined in advance.

What access and permissions are needed?

A separate technical account with permissions only for the required sections, access over a secure channel, and an action log. Permanent admin access to the production panel is not required.

Let's discuss the task and get back with a work plan

To base the estimate on facts rather than assumptions, it helps to send site inputs—this is enough to understand scope and risks. Below is a list of what removes most questions at the start.

• Site and environment description: platform and its current branch, web server, database, where the project is hosted—own server or cloud, how backup is currently arranged.
• Composition of extensions and themes: which modules are third-party, which have long been unsupported, where manual edits were made to the core or templates.
• Current edit workflow: who and how makes changes, whether there is an intermediate environment, how the result is checked before deployment to production.
• Availability requirements: whether a short maintenance window is acceptable, what hours it is possible, which site scenarios cannot be stopped at all.
• Problems that have already occurred: what broke after past updates, whether unresolved errors and incident notes remain.
• Access and desired work window: repository, hosting panel, test environment, and deadlines by which the CMS update needs to be performed.

Send what you have: part of the data is usually restored during analysis. Describe the maintenance task—we'll get back with an estimate and a site maintenance work plan: stages, order of core and extension updates, rollback points, deployment windows, and responsible persons.