Migrating content between 1C-Bitrix sites

Content Migration Between 1C-Bitrix Sites

Moving content between sites on the same platform seems trivial — until you discover that sections, infoblocks, and their types live in different tables, and relationships break when records are simply copied. In practice this is structural work involving the database and the file system simultaneously.

What Actually Gets Migrated and How It Is Stored

Content in 1C-Bitrix falls into several categories with fundamentally different storage mechanisms:

Infoblocks — the primary workhorse. Structure: the b_iblock table stores iblock type metadata, b_iblock_element stores elements, b_iblock_section stores sections, b_iblock_element_property stores property values. When transferring between sites (different SITE_ID), keep in mind:

• The iblock type may not exist on the target site — it must be created first
• IBLOCK_ID will differ between source and target; all internal references and links must be recalculated
• Properties of type "Element binding" store element IDs that will change after the transfer

Pages and site structure (b_iblock of type 'S' — static pages are not always used; more often this is the file structure under /bitrix/templates/ and physical .php files in the document root). Page content may be:

• Directly in .php files — transferred via rsync/FTP
• In components that connect to infoblocks — transferred via the iblock
• In the visual page editor (Landing) — a separate case, tables b_landing_*

Transfer Tools

Built-in iblock export/import — via the admin section "Import/Export Data" (XML format). Limitations: does not correctly transfer file-type properties when paths differ, and does not automatically handle related elements.

Bitrix Migrations — the bitrix.migrate module (included starting with the Business edition). Allows creating content snapshots and applying them to another site. Suitable for CMS content, but not for high-load infoblocks with tens of thousands of elements.

Direct database work — the most reliable method for large volumes:

-- Get all iblock elements with the required IBLOCK_ID
SELECT ie.*, ies.PROPERTY_1234
FROM b_iblock_element ie
LEFT JOIN b_iblock_element_property iep ON ie.ID = iep.IBLOCK_ELEMENT_ID
WHERE ie.IBLOCK_ID = 42 AND ie.ACTIVE = 'Y';

With direct SQL transfer, an ID recalculation script is required: create elements via API (CIBlockElement::Add()), save the mapping old_ID → new_ID, then a second pass updates all binding properties.

Transferring Files and Images

Properties of type "File" store a reference to a record in the b_file table. Physically, files reside in /upload/iblock/. During transfer:

1. Copy files to the /upload/ folder on the target site
2. Create records in b_file on the target site (or use CFile::SaveFile())
3. Update property values with the new FILE_IDs

If both sites are on the same server and share a common /upload/ folder (possible in a multisite configuration), the file-copying step is simplified, but the risk of filename conflicts increases.

Preserving SEO During the Transfer

When migrating between sites, page addresses may change. You must:

• Build a redirect map (old URL → new URL)
• Configure 301 redirects via .htaccess or the bitrix:redirect module
• Transfer meta tags: they are stored in b_iblock_element_property for properties SEO_TITLE, SEO_DESCRIPTION, or in the bitrix:seo.tags component

Typical Timelines

A full backup of both sites is mandatory before work begins. When migrating between different Bitrix versions, table structure compatibility is additionally verified.