Migration of a site from Drupal to 1C-Bitrix

Website Migration from Drupal to 1C-Bitrix

Drupal is a powerful CMS with developed entity/field architecture. Often chosen for complex portals, government sites, multilingual platforms. Switch to Bitrix usually driven by corporate requirements: 1C integration, unified ecosystem with Bitrix24, or need for Russian-certified CMS. Migration from Drupal technically harder than from most other CMS due to flexible but non-standard data storage model.

Drupal Data Model

In Drupal 7, content stored via Field API system. Each node field stored in separate table named field_data_{field_name} and field_revision_{field_name}. Main tables:

• node — basic record: nid, type, title, uid, status, created, changed.
• node_revision — revision history.
• field_data_body — material body: body_value, body_summary, body_format.
• field_data_{custom_field} — arbitrary fields, one table per field.
• taxonomy_term_data, taxonomy_vocabulary — taxonomy (categories, tags).
• file_managed — media files.
• users, users_roles, role — users.

In Drupal 8/9, architecture similar, but storage via Doctrine DBAL and configs in YAML. Tables: node__body, node__field_{name} (one table per field, all revisions in node_revision__*).

Structure Design in Bitrix

Each Drupal content type becomes iblock in Bitrix. Taxonomy — iblock sections or "List" properties. Node fields mapped to iblock properties.

Before writing script, create mapping table:

Migration Script

Drupal 7: script reads data via PDO from Drupal MySQL database. For each node:

SELECT n.nid, n.title, n.created, b.body_value, b.body_summary
FROM node n
LEFT JOIN field_data_body b ON b.entity_id = n.nid AND b.bundle = 'article'
WHERE n.type = 'article' AND n.status = 1

Then for each field — separate JOIN or subquery. Result — data array for CIBlockElement::Add().

Media files. In Drupal files registered in file_managed with uri field format public://photos/image.jpg. Physically file in sites/default/files/photos/image.jpg. Copy files, register via CFile::SaveFile(), attach to element.

Taxonomy. Taxonomy terms (taxonomy_term_data) transferred as iblock sections or "List" property values. If Drupal had multiple terms from one vocabulary for one material — create "Multiple" property in Bitrix.

Multilingual Support

Drupal has built-in multilingual support via i18n modules (Drupal 7) or built-in Content Translation (Drupal 8+). Translations stored in field_data_* with different language values. Bitrix supports multilinguality via infoblocks with LANGUAGE_ID or via different sites in one installation. If site multilingual — this stage requires separate design.

Views and Blocks

Drupal Views — dynamic content lists with filtering and sorting. In Bitrix their analog is bitrix:news.list component with filter parameters. No direct Views transfer exists: each View analyzed manually and implemented as component or custom code.

Drupal Blocks (region/block) — in Bitrix these are areas ($APPLICATION->ShowPanel()) and components in template. Page structure transferred when developing design, not during data migration.

Drupal Modules Without Analogs

Webform → forms via bitrix:form. Commerce (Drupal Commerce) → catalog + sale modules. Rules → Bitrix business processes or event handlers. Feeds (import) → agent or cron task.

Timeline

Drupal is one of most complex CMS for migration precisely because of non-standard storage structure and abundance of possible modules. Actual timeline always clarified after audit of source database.