Optimizing 1C-Bitrix import: where the export breaks
An export from 1C breaks not on volume, but on the nature of the data. While the catalog items flow in a steady stream, the exchange with 1C looks healthy: the agent runs on schedule, positions are updated.
As soon as thousands of trade offers, stock recalculation across warehouses, and price re-linking appear in the export, the import starts failing by timeout in the middle of a batch.
Part of the catalog is updated, part holds old prices, and the site sells based on data that no longer exists in 1C.
The second bottleneck is catalog locks. An import that writes products one at a time within a single transaction keeps tables open for the entire duration of its work: product pages won't open, the cart waits, search returns empty pages.
In parallel, garbage accumulates — duplicate positions, orphaned trade offers, broken links to sections — and the next import processes an already bloated catalog, running into the same timeout.
Optimizing 1C-Bitrix import starts with analyzing exactly where time is lost: in parsing the file, in writing to information blocks, or in recalculating related entities.
Then batch loading splits the stream into portions with progress checkpointing, so that a failure doesn't roll back the entire exchange, and locks are eliminated through deferred recalculation of prices and stock. Duplicates and orphaned records are cleaned out before they enter the next cycle.
The result is measured not by "import speed," but by how the catalog behaves under load: the exchange fits within the schedule window, prices and stock match 1C by the time the store opens, product pages don't hang during the export, and a failure of a single batch doesn't leave the catalog in a half-parsed state. Let's break down how this is resolved on a specific setup.
What changes after optimizing the exchange with 1C
Before optimization, the exchange with 1C is a batch export of the entire catalog on a schedule: each synchronization re-transmits tens of thousands of items, even if prices for five products have changed.
A full export stretches over hours, comes in waves, and at its peak takes resources away from the site — the storefront responds more slowly exactly when the exchange is running.
Incremental exchange changes the logic: 1C sends only the changed objects, and the server applies them pointwise, without rebuilding the catalog in full.
The export speed after rebuilding the exchange is determined not by hardware capacity, but by the volume of transmitted data.
When the full exchange runs not across all items, but across a delta slice, import time is reduced many times over: a typical scenario is from several hours to minutes on an increment and up to tens of minutes on a full export.
The catalog stops "freezing" during synchronization, and the load on the server is distributed evenly, without the peaks that used to fall in the nighttime window.
Catalog stability is the second measurable effect.
Incremental exchange with change accumulation and correct handling of deletions eliminates desynchronization: prices, stock levels, and availability statuses on the storefront match the accounting system within a single exchange cycle.
A class of failures goes away in which some products disappeared from the catalog after a failure in the middle of an export — the exchange becomes idempotent and survives a connection drop without manual re-uploading.
Server load during the exchange is also reduced separately.
Instead of processing the entire array in parallel, the server applies changes in portions, and heavy operations — reindexing, cache reset — are performed pointwise on the affected sections rather than on the entire catalog.
This is what delivers predictable import time: the exchange stops being an event that the whole team waits for and becomes a background process with a clear schedule.
Exchange methods: batch loading, incremental, queues
Exchange with 1C is not about "turning on synchronization" but about choosing a mode for the catalog size and the frequency of edits.
A full upload re-reads the entire reference book and overwrites cards in their entirety: with tens of thousands of items, that means hours of work and a high load on the database.
Incremental import picks up only the objects changed since the previous session — the same result with less work, but it requires a reliable change-tracking mechanism on the source side.
Batch loading solves a different problem — not "what to load" but "how not to bring down the server." Data comes in portions with progress being committed: if a session is interrupted midway, the next one starts from the last successful portion rather than from scratch.
Exchange queues decouple the source and the receiver in time: 1C unloads into the queue and does not wait for the site to process the packets, while the handler picks them up as they become available. This removes peak locks and makes behavior predictable during spikes.
| Mode | When it fits | Limitations |
|---|---|---|
| Full upload | Initial population, infrequent updates | Slow, high load, catalog downtime during the session |
| Incremental import | Frequent pinpoint edits of prices, stock, properties | Requires change markers and correct handling of deletions |
| Batch loading | Large catalogs, unstable channel | Requires progress storage and idempotent writing |
| Exchange queues | High frequency, multiple receivers | Harder to maintain, requires queue congestion monitoring |
In practice, modes are combined: initial population via full upload, then incremental on top of batch loading, while queues provide decoupling in time.
We fix the choice based on the size of the reference book, the frequency of edits, and the acceptable time of data divergence between 1C and the site.
How we implement import optimization: stages of work
We start with an audit of the exchange: we take real measurements — how long a full and partial upload takes, at which steps the exchange fails or hangs, how the database behaves under load.
At this stage it becomes clear where the bottleneck is: in data selection on the 1С side, in the structure of queries to the catalog, or in the processing logic itself. Without measurements, any optimization turns into guesswork.
Next, we design the target import scheme and configure the upload so that the exchange runs in batches and does not block the site's operation.
- Exchange audit. We record the current metrics: duration of full and partial exchange, volume of transmitted data, failure points. We build a map of dependencies between reference books, products, prices, and stock.
- Designing the import scheme. We determine what to load incrementally and what — in a full cycle, how to split the flow into packets, where to cache intermediate results.
- Configuring the upload on the 1С side. We rewrite the selections so that the source returns only changed records, not the entire catalog. We remove unnecessary database calls inside the loop.
- Optimizing processing on the site. We restructure queries, indexes, and the order of operations so that the import does not compete with live visitors for resources.
- Integrity check. We reconcile checksums and record counts before and after the exchange, catching discrepancies in prices, stock, and section assignments.
- Exchange regulations. We describe the schedule, launch procedure, behavior on failure, and rollback points — so that support can reproduce the process without us.
- Handover and support. We hand over the documentation, conduct training for the customer's team, and stay in touch during the period of the first independent launches.
Each stage ends with a measurable result: reduced exchange time, no site blocking at the moment of upload, relieved database load. Only after the exchange runs stably for several cycles in a row do we hand over the support regulations.
Access policies, roles, and exchange structure
An import that accesses the database under an administrator account will sooner or later block what it shouldn't: a catalog update holds tables, and meanwhile order checkout crashes or the export to 1C hangs.
The cause is not the volume of data, but the fact that the exchange and production traffic use the same access and the same tables. We separate them at the level of permissions and structure.
- A separate exchange account — a service user with rights only to the required information blocks and catalog sections, without access to orders, payments, and settings. Compromising the exchange key does not expose customer data.
- Roles by areas of responsibility — a content manager edits descriptions but does not touch prices and stock; the integration user writes only to the fields that 1C manages. Overlapping permissions are the main reason why manual edits get overwritten by the next export.
- Separating flows by data type — nomenclature, prices, stock, and counterparties go through different jobs with their own schedules. A heavy catalog export does not drag along a stock recalculation.
- Isolating the import from the storefront — the exchange writes to buffer sections, and data reaches the site only after an integrity check. A visitor never sees the catalog in an intermediate state.
- Limiting the frequency and windows of the exchange — jobs are launched during low-load hours, with overlap control: a repeated run does not start until the previous one has finished.
- Logging for each flow — you can see which exchange ran, when, how many records it processed, and where it failed. Incident analysis takes minutes instead of searching through a shared log.
This structure eliminates the main class of failures: the exchange stops being a source of site degradation. Next, we look at how this fits into the support regulations and what remains on the 1C side.
What the client receives after the work
After the work, the support team leaves behind not "magic in the contractor's head," but a set of artifacts that allow data exchange to be maintained and developed without us.
The foundation is the exchange schema: which entities are synchronized and in which direction, where the source of truth is for each field, which events trigger export and which trigger import.
From it, a new engineer understands within an hour what comes into the catalog, prices, and stock, and from where.
Separately, we hand over the import configuration — working export profiles, field mapping, rules for matching categories and product variants, batch processing settings, and conflict behavior.
Alongside it is the export regulation: the schedule and launch conditions, the procedure for full and partial synchronization, what to do when quantities diverge, and how to roll back an unsuccessful run.
To this we attach a maintenance guide for your team: how to read the exchange log, which messages to respond to immediately, how to safely change matching rules and add new fields without risk to the catalog.
In the documentation, we record extension points and typical scenarios — the appearance of a new item, a change in category structure, the connection of an additional source.
All of this is in your environment, with access for your specialists. We remain on support, but the handover is structured so that the team handles routine operations itself and reaches out to us for development, not for every failure.
How does incremental import differ from full import?
A full export re-reads the entire catalog on every exchange: if the database has 80,000 items and 12 have changed, the system will still run all 80,000 through comparison and writing.
Incremental import takes only what has changed since the last synchronization — by timestamp, record hash, or change log on the source side.
Hence the difference in behavior: full mode creates peak load on the database and holds it for the entire pass, while incremental spreads the same work across short intervals and is almost invisible to site visitors.
The exchange speed differs not by a factor of a few, but by an order of magnitude. A full export on a large catalog takes tens of minutes, and all that time the site runs on outdated stock and prices — if the exchange fails midway, some cards are left with incomplete data.
An incremental pass fits into minutes, and with streaming synchronization — into seconds, so the price and availability on the storefront match the accounting system almost immediately.
The risks of the modes are also different. Full import forgives desynchronization: it overwrites everything each time, so any error in the data is cured by the next run.
But it is also dangerous for related entities — trade offers, properties, bindings to sections: if the import fails between stages, some relationships remain broken until the next full pass.
Incremental mode requires discipline: you need to reliably record the reference point, otherwise changes will be lost silently, and the discrepancy will accumulate for weeks.
On the other hand, it is safer for the database — short transactions do not hold locks and do not bring the site down under load.
In practice, the choice is not "either-or" but a combination: incremental exchange on a schedule for prices, stock, and statuses, full export — at night or once a week as insurance against accumulated discrepancies.
Separately, the handling of deleted items and unpublished products is configured: this is where discrepancies between the storefront and the accounting system most often surface.
We analyze the exchange structure on your project and determine where incremental mode covers the task and where a full export is indispensable.
Case study: we sped up catalog exchange with 1C several times over
What it was before
The client is a distributor with a catalog of several tens of thousands of SKUs; the exchange with 1C on 1C-Bitrix was launched on a schedule and did not always manage to finish by morning.
A full export took about 4 hours, the exchange agent regularly crashed on timeout at the stage of recalculating prices and stock, and managers started the day with manual reconciliation: some products were stuck with old stock, some with outdated prices.
Worst of all, the failure was not always noticeable right away: the exchange finished "green", while the data in the catalog remained incomplete.
What we changed
We broke the exchange down stage by stage and found three bottlenecks: the recalculation rebuilt the entire catalog instead of only the changed items, database queries went one at a time without batch processing, and heavy operations ran in the same thread as catalog page delivery.
We switched the exchange to incremental mode — only items changed since the previous export are processed, while full synchronization remained as a nightly integrity check. Heavy steps were moved into separate jobs so they would not compete with visitor traffic.
What it became
The full export was reduced from 4 hours to 40-50 minutes, and the incremental exchange fits within 5-7 minutes.
The class of failures "the exchange crashed on timeout and nobody noticed" is gone: now every step is logged, and an unfinished exchange does not leave the catalog in a half-finished state — changes are applied atomically.
The load on the database during the exchange dropped so much that the catalog stopped "lagging" for visitors in the morning hours.
We also separately addressed observability: the customer now has a report for each exchange — how many items were updated, how many were skipped, where an error occurred.
Previously, problems were learned about from managers; now they come from the report, before it reaches buyers.
Common technical concerns about 1C import
Import from 1C almost always comes down not to the exchange itself, but to four engineering questions: version compatibility, behavior under load, rollback capability, and channel security. Below are the most frequently asked questions at the evaluation stage, with substantive answers.
1C and Bitrix compatibility: will the exchange have to be rewritten?
The standard exchange via CommerceML works with typical 1C configurations and the current Bitrix branch without modifications on the accounting system side.
If you have a non-standard configuration or custom attributes, we describe the field mapping and, if necessary, add an intermediate layer — then changes in 1C are minimal, and the logic is moved to the site side.
What about the load on the site during import?
A full exchange head-on blocks the catalog and tanks response times. We split the stream into batches, synchronize only changed items, and move heavy operations to background jobs. The catalog remains available to customers, and the server does not go into overload at peak.
Can the import be rolled back if data came through with an error?
Yes. Before writing, a snapshot of the affected entities is taken, so a failed exchange rolls back to the previous state without manual restoration from a backup. This is especially important during bulk updates of prices and stock.
How secure is the exchange between 1C and the site?
The channel is closed, access is role-separated, and the exchange runs over a secure connection with source verification. Exchange credentials are stored separately from user credentials and do not end up in logs.
If your question about compatibility, load, rollback, or exchange security is not covered — describe the task, and we will get back to you with an estimate and a plan.
Let's discuss your import optimization task
To come back with an estimate and a plan, rather than generalities, we need a brief technical snapshot of your import. Describe the task — the catalog size, where the data is loaded from and to, how often, and what you've already tried to speed up. That's enough to understand the class of the problem and propose a realistic path.
It helps to attach what you already have on hand:
- an export from 1C or a sample exchange file — structure matters more than volume;
- the current full import time and at which stage it "stalls";
- a log or error report if the import fails or loses items;
- a relationship diagram: products, trade offers, prices, stock, warehouses;
- a description of the server environment — where the site and database run;
- a list of integrations tied to the catalog: marketplaces, CRM, search, analytics;
- what's critical in terms of timing: the nightly window, downtime under load, the update schedule.
Based on this data, our engineers will analyze the bottlenecks: redundant database queries, recalculation of sections and prices, lack of batch processing, heavy events when updating elements.
Then we'll come back with an import estimate and a work plan — by stages, with the expected effect at each one.
Optimizing 1C-Bitrix import is not a one-time fix, but a mode of operation for the exchange. That's why the plan also accounts for how the solution will behave as the catalog grows: where new bottlenecks will appear and how to eliminate them in advance.
If it's more convenient to start with a conversation — we'll discuss the task by voice, and an engineer will ask clarifying questions about your exchange schema. The engineer's consultation here is about not wasting time on obviously dead-end options.