← Practice · November 14, 2026

Updating a customized 1C configuration: how to preserve your modifications

Updating 1C with customizations: an inventory of external data processors, a comparison against a clean standard configuration, and a risk map that AI helped put together.

7 min read1C

A customization in 1C can stop working after an update even if nobody touched it. Standard code somewhere else entirely can break it, and the built-in checks will not reveal the problem. Preparing to update a customized 1C configuration therefore involves more than comparing your own changes: you also need a map of what 1C is changing around them. Below, I describe how we prepared for this at a wholesale company with AI, what we have so far, and what remains to be done.

Standard, customized, and moving with your own furniture

A standard configuration is 1C as released by 1C Company. A customized configuration is the same program with the company’s own modifications. Updating a standard 1C configuration is almost automatic. A customized one is more complicated: it is like moving to a new apartment with your own furniture. The wardrobe is the same, but the layout is new, and it may not fit in its old spot.

The company runs 1C:ERP 2.5, with a move to ERP 2.6 ahead. It has a production database, a test copy, and a separate clean standard database for support requests to 1C.

The company makes its changes directly in the configuration and marks them in the code. It deliberately does not use 1C extensions—separate add-ons that modify the program without touching its core—for its own changes. The reason is simple: during configuration comparison and merging (the process 1C uses during an update to show where the new version differs from your changes and help combine them), a conflict is immediately visible, whereas in an extension it only appears at runtime. Three third-party extensions are installed for integrations.

There are quite a few customizations: 21 event subscriptions, 42 changes inside standard modules, and 49 added attributes—extra fields in documents and catalogs.

Nobody touched the customization, but it broke

A real incident after an update between 2.5 releases prompted this preparation.

There was an event subscription—a piece of code that 1C runs automatically at the right moment, for example when posting a document. When a sales plan was posted, it appended movements to a budget register. A register is a table where 1C stores accounting records, and movements are the records a document writes to it.

In the new release, standard code started rewriting the same register in a background job—work that 1C performs automatically, without user involvement. It wrote in replacement mode: it deleted the old records and put its own in their place. The movement appended by the subscription silently disappeared.

It is like the upstairs neighbors replacing their pipes, leaving you without water even though nobody touched your tap. Taking the tap apart over and over will not reveal the cause.

The built-in 1C configuration comparison showed nothing: the subscription itself had not changed; the code around it had broken its behavior. Debugging showed the opposite picture: while the developer was paused at a breakpoint, the transaction held a lock on the register, the background job timed out waiting for the lock to be released and failed—and the subscription’s movement remained in the register. The bug seemed to disappear as soon as someone started looking for it. The 1C specialist found the cause himself and said it “was a real ordeal.” AI later analyzed the code and confirmed the same cause.

First, we sorted out the storage cupboard

External reports and data processors are separate files that add custom reports and actions to 1C. They had accumulated in a shared folder over the years, often in multiple versions. There were 66 registered in the database, and the specialist could no longer remember which of the others were still needed. A familiar storage cupboard: everything is kept “just in case,” but before moving, you have to decide what to take.

The folder contained 765 files, including 437 external reports and data processors. AI compared them by content rather than filename: the same report appeared under different names, while different versions shared a name. There turned out to be 364 distinct reports and data processors.

To determine which were in use, AI found traces of them in saved user settings and matched those against users still active in the database. There were 61 data processors that had not been registered in the database but had been opened by active users. Another 237 had not been opened by any active user, and 233 of those had last been changed in 2021 or earlier.

The result was a table with a “decision” column for the specialist to fill in.

Nothing was deleted; everything is accounted for

The specialist made the decisions. He marked 298 data processors as unnecessary and 66 as needed: 10 third-party ones, which were left untouched, and 56 developed in-house. Of the 298 unnecessary ones, 25 were registered in the database—the specialist removed those registrations himself.

His rule for files was to delete nothing. Unnecessary files went into an archive with their subfolder structure preserved, and before a file was modified, its previous version went there too, marked “before modification.”

The needed files were put in order: 45 files were rebuilt, and all 45 were checked by opening them in the test database. The 28 registered ones were reloaded into the production database, and snapshots of their settings before and after matched. A total of 374 files went into the archive. Checksums—digital fingerprints of file contents—for all 419 moved and replaced files matched the inventory, with 0 errors.

AI changed nothing in the production database without the specialist’s instruction and checked changes in the test database first.

We looked for changes around the customizations

Next came the main task: identifying which standard code could affect the company’s customizations.

A trap emerged immediately. The production database and the “standard” one were on different release builds—slightly different builds of the same version. Comparing them directly would mix changes from 1C with customizations. AI therefore used the distribution packages to create clean standard databases for the required releases—separate file-based databases, leaving the production databases untouched.

It then identified what had been changed or added in the production configuration compared with the clean standard one and built an index of all standard code: which code writes to which register, whether it appends or replaces records, and whether this can happen in a background job or through deferred execution.

This produced the first version of the “Customizations and risks” report. Each row listed a customization, the registers it touches, the standard code that writes to the same registers, and the resulting risk. Red marked places where standard code could overwrite records appended by a customization in the background or through deferred execution. Yellow marked things worth checking after the update—for example, a register rewritten by version update handlers, or a custom dimension added to a standard register that standard code does not populate.

As a sanity check, the report flagged the place where the specialist had fixed the sales plan incident as high risk. But, as we later discovered, it was not directing attention to the most important place.

Where the specialist corrected the AI

The specialist noticed that a red flag on a change inside a standard module largely duplicated the built-in mechanism: that change would already surface during comparison and merging. The real danger is when a customization stays unchanged but standard code elsewhere that writes to the same registers changes. This led to a decision: the report’s main signal should be “standard code that writes to your registers has changed between releases.” Reworking the report around this logic is still ahead.

There was also a false alarm. The report marked one subscription yellow because a version update handler writes to the same register. The specialist asked what conflict could occur if nobody was working during the update. AI checked the code: the handler writes records for different documents, and it appends some of them rather than replacing them. The alarm was false, and it exposed a gap in the tool: it did not cross-check the documents or the write mode. The fix is on the task list.

One more correction has already been made. In another task, AI proposed a change to a print form that listed every field in an internal standard table. The specialist pointed out that the change would break if 1C changed the table’s structure. We reworked it to change only the required fields, and this is now the rule for all modifications.

What is done and what is ahead

Done: the inventory, classification, cleanup of external data processors, and the first version of the risk report. The move to ERP 2.6 itself has not started—the specialist postponed it. The report is being refined based on his feedback. For the migration, AI has so far produced only a plan: a database copy on 2.6, checking data processor code for references to objects that no longer exist, checking user permissions for new objects, a rehearsal, and a before-and-after comparison.

There is one lesson: when updating 1C with customizations, the danger lies not in what you changed but in what 1C changed around your customizations. Comparison shows the former; the latter requires a separate investigation. AI does this preliminary work—the inventory, code analysis, and cross-checking—while the specialist makes the decisions.

How to handle the update yourself

1. Start with an inventory of external reports and data processors. Compare their contents rather than their names, and check saved settings to see who uses them. In our case, 298 out of 364 were marked as unnecessary. Delete nothing: move files into an archive and verify their checksums.
2. Compare against a clean standard configuration from the same release and the same build. Otherwise, changes from 1C will get mixed in with yours.
3. Look for changes around your customizations. For every subscription and custom write to a register, list the places in standard code that write to the same register and check that list at every update—especially background jobs, deferred handlers, and writes in replacement mode.
4. In standard code, change only the fields your customization needs. Do not tie a modification to the structure of someone else’s tables, and mark its beginning and end so it is easy to find during merging.
5. After updating a test copy, post the documents that your customizations operate on, wait for background jobs to finish, and compare the movements before and after. These bugs may not reproduce during debugging.

What else AI can do in 1C—on the page about AI in 1C.