Bulk Product Transfer Between Sections in 1C-Bitrix: Automation That Works

Catalog Restructuring: How to Avoid Drowning in Routine

Imagine: the "Smartphones" section splits into subsections by brand — 800 products to distribute in just a few hours, otherwise the site goes idle. Or the supplier changed categorization, leaving 400 items hanging in wrong sections, search returns chaos, and managers spend hours manually updating. Doing this manually through the admin panel would take about two weeks of non-stop work for 800 products — just clicks, not counting errors. The only solution is automated bulk moves. For example, in one project we moved 1200 products from "Laptops" to "Ultrabooks" in 3 minutes using direct SQL — without errors or downtime. The client saved over 40 hours of manual effort.

Our method has been proven on 150+ catalogs with volumes from 300 to 50,000 products. Over years of working with 1C-Bitrix, we've developed efficient approaches that account for the internal structure of infoblocks, caching, and access rights. Below is a technical breakdown — from table structure to performance optimization — and at the end, a ready-to-use solution for your project.

Section Structure and Product Binding

Infoblock sections are stored in b_iblock_section. The element's link to a section is the IBLOCK_SECTION_ID field in b_iblock_element (main section). Additional binding to multiple sections is in table b_iblock_section_element: IBLOCK_ELEMENT_ID, IBLOCK_SECTION_ID, ADDITIONAL_PROPERTY_ID.

When moving a product, you must update both places:

1. IBLOCK_SECTION_ID in b_iblock_element — main section.
2. The record in b_iblock_section_element — for correct filter operation.

Moving via CIBlockElement::Update

The standard update method with section change:

\CIBlockElement::Update($elementId, false, [ 'IBLOCK_SECTION_ID' => $newSectionId, ]); 

After Update(), Bitrix automatically updates b_iblock_section_element. But this method is slow for bulk operations — each call goes through events, caching, access rights.

Why Direct SQL Update Is Better?

When working with catalogs of 500+ items, the difference becomes critical. CIBlockElement::Update loads Bitrix modules, checks rights, and fires events. In the background, this leads to hangs. Direct SQL bypasses these layers, but requires careful data integrity control. We use it in combination with transactions and backups.

Direct SQL update for speed:

global $DB; $elementIds = implode(',', array_map('intval', $productIds)); $newSection = (int)$newSectionId; $DB->Query(" UPDATE b_iblock_element SET IBLOCK_SECTION_ID = {$newSection} WHERE ID IN ({$elementIds}) "); $DB->Query(" DELETE FROM b_iblock_section_element WHERE IBLOCK_ELEMENT_ID IN ({$elementIds}) AND ADDITIONAL_PROPERTY_ID IS NULL "); foreach ($productIds as $id) { $DB->Query(" INSERT INTO b_iblock_section_element (IBLOCK_ELEMENT_ID, IBLOCK_SECTION_ID) VALUES ({$id}, {$newSection}) "); } 

Direct SQL is 50-100 times faster than CIBlockElement::Update() for bulk operations, but requires manual cache reset.

Comparison of Moving Methods

Common Mistakes in Bulk Moves

How to Reset Cache After Moving?

After a bulk move, catalog component caches don't expire immediately. Force reset:

\Bitrix\Main\Application::getInstance()->getTaggedCache()->clearByTag('iblock_id_' . $iblockId); // For specific sections foreach (array_unique(array_merge($oldSectionIds, [$newSectionId])) as $secId) { \Bitrix\Main\Application::getInstance()->getTaggedCache() ->clearByTag('iblock_section_' . $secId); } 

How to Automatically Distribute Products by Sections?

For automatic distribution based on properties — for example, by brand:

$brandSectionMap = [ 'Apple' => 125, 'Samsung' => 126, 'Xiaomi' => 127, ]; $res = \CIBlockElement::GetList( [], ['IBLOCK_ID' => $iblockId, 'IBLOCK_SECTION_ID' => $sourceSection], false, false, ['ID', 'PROPERTY_BRAND'] ); while ($item = $res->GetNext()) { $brand = $item['PROPERTY_BRAND_VALUE']; $targetId = $brandSectionMap[$brand] ?? null; if ($targetId) { \CIBlockElement::Update($item['ID'], false, ['IBLOCK_SECTION_ID' => $targetId]); } } 

For large volumes, this script runs via a Bitrix agent in batches of 100-200 items, saving progress in b_option.

How We Automate the Process: Step by Step

1. Structure Analysis — examine current sections, properties, access rights.
2. Script Development — write an SQL or API script tailored to your conditions.
3. Testing on a Copy — run on a staging copy, verify integrity.
4. Production Deployment — execute the migration during low-load hours.
5. Cache Reset — clear tagged caches and check frontend.
6. Documentation — hand over the procedure description for future reuse.

What Our Work Includes

• Consultation and analysis of the current catalog structure.
• Writing a migration script based on your conditions (brands, properties, prices).
• Testing on a staging copy.
• Production deployment and cache reset.
• Documentation of the procedure.
• 30-day guarantee support.

Our Experience and Guarantees

Over 7 years of Bitrix development experience, 150+ successful catalog migration and optimization projects. Certified specialists. Catalog administration costs can be reduced by up to 80% through automation. We stand by our quality, so we provide a script guarantee.

Contact us to assess your project and propose the optimal solution. Order bulk move setup — and forget about routine. Get an engineer consultation for your catalog.

Official 1C-Bitrix Documentation: Infoblock Table Structure