Migrating from Drupal to 1C-Bitrix is a task we tackle regularly. Clients come with complaints about complex 1C integration, lack of corporate tools (Bitrix24), or import substitution requirements. Migration from Drupal is technically more challenging than from most other CMS due to its flexible but non-standard data storage model. A typical scenario: an online store on Drupal Commerce that can no longer handle the load and requires 1C integration. Moving to Bitrix not only solves these issues but also reduces data exchange time with the accounting system by 2–3 times thanks to ready-made exchange modules. Our clients save up to 40% of development budget on integrations compared to customizing Drupal. Contact us for an audit of your project, we'll discuss the details of your move.
Why migration from Drupal is technically harder than from other CMS?
In Drupal 7, content is stored via the Field API. Each node field resides in a separate table named field_data_{field_name} and field_revision_{field_name}. Main tables:
-
node— base record:nid,type,title,uid,status,created,changed. -
node_revision— revision history. -
field_data_body— body content:body_value,body_summary,body_format. -
field_data_{custom_field}— custom 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, the architecture is similar but stores via Doctrine DBAL and configs in YAML. Tables: node__body, node__field_{name} (one table per field, all revisions in node_revision__*). According to official documentation, this structure provides flexibility but complicates direct migration.
Designing the structure in Bitrix
Each Drupal content type becomes an information block in Bitrix. Taxonomy becomes information block sections or list-type properties. Node fields are mapped to information block properties.
Before writing the script, we create a mapping table:
| Drupal | Type | Bitrix | Property type |
|---|---|---|---|
field_data_body.body_value |
text_long | DETAIL_TEXT |
— |
field_data_image.field_image_fid |
image | PREVIEW_PICTURE |
— |
field_data_field_tags |
term_reference | PROPERTY_TAGS |
List |
field_data_field_price |
decimal | PROPERTY_PRICE |
Number |
Migration script
Drupal 7: the script reads data via PDO from the 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, a separate JOIN or subquery. The result is an array for CIBlockElement::Add().
Media files. In Drupal, files are registered in file_managed with a uri field in the format public://photos/image.jpg. The physical file is in sites/default/files/photos/image.jpg. We copy files, register them via CFile::SaveFile(), and attach to the element.
Taxonomy. Taxonomy terms (taxonomy_term_data) are transferred as information block sections or as list-type property values. If one material has multiple terms from the same vocabulary, we create a multiple property in Bitrix.
How to migrate a multilingual site?
Drupal has built-in multilingual support via i18n modules (Drupal 7) or built-in Content Translation (Drupal 8+). Translations are stored in field_data_* with different language values. Bitrix supports multilingualism via information blocks with LANGUAGE_ID or via different sites in one installation. If the site is multilingual, this stage requires separate design.
Views and blocks
Drupal Views — dynamic lists of materials with filtering and sorting. In Bitrix, the equivalent is the bitrix:news.list component with filter parameters. There is no direct transfer of Views: each View is analyzed manually and implemented as a component or custom code.
Drupal blocks (region/block) — in Bitrix these are areas ($APPLICATION->ShowPanel()) and components in the template. The page structure is transferred during design development, not during data migration.
Drupal modules without analogues
Webform → forms via bitrix:form. Commerce (Drupal Commerce) → catalog + sale modules. Rules → Bitrix business processes or event handlers. Feeds (import) → Bitrix agent or cron job.
How to preserve SEO positions during migration?
Key element — 301 redirects. We create a mapping of old Drupal URLs to new Bitrix addresses. Additionally, we configure sitemap, robots.txt, and transfer meta tags from Drupal fields. For images, we preserve alt texts and file names.
How to perform the migration: step-by-step plan
- Audit of the Drupal database: analyze structure, content types, volumes.
- Design information blocks and field mapping: complete mapping scheme.
- Develop the migration script: PHP script using PDO, process all entities.
- Transfer media files: copy files preserving paths and attributes.
- Set up SEO redirects: generate .htaccess with 301 redirects.
- Test and verify data: compare element counts, check links.
- Documentation and admin training: transfer knowledge.
- Post-migration support: technical support for 2 weeks.
Timeline
| Stage | Typical duration |
|---|---|
| Content types and fields audit | 1–2 days |
| Information blocks design and field mapping | 1–2 days |
| Migration script development | 3–6 days |
| Media files transfer | 1–2 days |
| Multilingual (if present) | 2–3 days |
| SEO redirects | 1 day |
| Testing and fixes | 1–2 days |
| Total | 10–18 working days |
Drupal is one of the most difficult CMS for migration precisely because of its non-standard storage structure and abundance of possible modules. The actual timeline is always confirmed after auditing the source database. To estimate the workload for your project, get a consultation — we will conduct an audit and offer a turnkey migration plan. We guarantee quality and preservation of rankings.