MODX to 1C-Bitrix Migration: Full Process Breakdown

MODX to 1C-Bitrix Migration: Full Process Breakdown We frequently take over projects where MODX can no longer keep up with business growth. A typical scenario: the client complains about slow 1C integration (via third-party components), lack of built-in CRM, and limited e-commerce functionality —

Our competencies:

Frequently Asked Questions

MODX to 1C-Bitrix Migration: Full Process Breakdown

We frequently take over projects where MODX can no longer keep up with business growth. A typical scenario: the client complains about slow 1C integration (via third-party components), lack of built-in CRM, and limited e-commerce functionality — with a catalog of 10,000 products, miniShop2 starts to lag. Switching to 1C-Bitrix solves these issues but requires a clear plan and deep understanding of both systems. Our turnkey migration includes a full audit, complete data transfer, 301 redirect setup, and team training. Timelines: 7 to 11 working days; the exact cost is determined after the audit.

Problems We Solve

  • Slow 1C integration: MODX relies on third-party components for 1C exchange, which are often unreliable and slow. Bitrix has native CommerceML support, cutting integration time by 3–5x.
  • Missing CRM: MODX has no built-in CRM. Bitrix includes a full-fledged CRM with lead management, deal tracking, and automation.
  • E-commerce limitations: miniShop2 degrades with large catalogs and lacks advanced features like trade offers, flexible pricing, and marketplace integrations.
  • Scalability: MODX's architecture becomes cumbersome for multi-language sites or high-traffic portals. Bitrix handles these scenarios with built-in tools.

How We Execute the Migration (Our Proven Approach)

We have migrated over 40 projects from various CMS to Bitrix. Our process relies on a custom PHP script that reads MODX database tables and writes directly to Bitrix's data structures. We avoid using generic import modules to ensure data integrity.

Data Model of MODX Revolution

MODX stores content in tables with the modx_ prefix. Key tables:

  • modx_site_content — all resources: pages, articles, folders. Fields: id, pagetitle, longtitle, alias, content, introtext, parent, template, published, publishedon, createdby, createdon, menutitle, description, content_type, uri.
  • modx_site_tmplvar_contentvalues — TV variable values per resource: tmplvarid, contentid, value.
  • modx_site_tmplvars — TV variable definitions: name, caption, type, elements, default_text.
  • modx_site_templates — templates.
  • modx_users, modx_user_attributes — users.
  • modx_categories — snippets/chunks categories.

For miniShop2 shops, additional tables exist: msProduct, msProductOption, msCategory, msOrder, msOrderProduct. Understanding this schema is vital for correct mapping to Bitrix infoblocks.

Page Tree: MODX → Bitrix Structure

MODX builds the site as a tree of resources. In Bitrix, the structure is defined by physical files in directories plus the administrative section. Static pages (corporate site, "About Us", "Contacts") are migrated in two ways:

  1. As Bitrix pages — we create PHP files in the required folders, with content defined via $APPLICATION->SetPageProperty() and components.
  2. As infoblock elements — if there are many similar pages (blog, news).

TV Variables → Infoblock Properties

TV variables are analogous to infoblock properties. Type mapping:

MODX TV Type Bitrix Property Type
text String
textarea / richtext HTML/Text
image File (image)
file File
listbox-multiple / checkbox List (multiple)
date Date/Time
number Number

On a typical project, there may be up to 50 TV variables. We automatically read their definitions and create corresponding infoblock properties.

Content Transfer Process

Our PHP script processes MODX resources sequentially:

  1. Determine the infoblock section by parent (recursively build section tree).
  2. Gather TV values via JOIN of modx_site_tmplvar_contentvalues and modx_site_tmplvars.
  3. Create infoblock element via CIBlockElement::Add().

The uri field in MODX is a ready-made human-readable URL. We store it as the element CODE and generate 301 redirects.

Images. In TV variables of type image, paths like /assets/images/photo.jpg are stored. We copy files to the Bitrix server and register them via CFile::MakeFileArray().

miniShop2 → Bitrix Catalog

If miniShop2 was installed on MODX:

  • msProduct (JOIN to modx_site_content) → catalog infoblock elements.
  • msProductOption — product options (color, size) → trade offers.
  • msCategory → infoblock sections.
  • msOrder / msOrderProductb_sale_order / b_sale_basket.
  • Prices from msProduct.priceb_catalog_price with the appropriate price type.

Bitrix outperforms MODX in 1C integrations by 3–5 times thanks to native CommerceML support.

Chunks, Snippets, and Templates

Chunks (modx_site_htmlsnippets) and snippets (modx_site_snippets) — are MODX template engine code (Smarty/Twig or raw PHP). They are not automatically transferred. All functionality is reimplemented using Bitrix components. This is the most labor-intensive stage if the site used complex snippets (pdoMenu, pdoPage, FormLister).

Example structure mapping

Suppose MODX has a TV gallery of type image. In Bitrix, we create a property GALLERY of type "File (multiple)". The script reads all values, copies images, and attaches them to the infoblock element.

Migration Process and Workflow

Our approach avoids fixed pricing because each project has unique complexity. Here's how we operate:

  1. Data collection and initial audit — we analyze the MODX site structure, extensions, and custom code.
  2. Project planning — we design the infoblock structure, map fields, and plan the import script.
  3. Development of migration script — we create a tailored PHP script for your data.
  4. Testing on a staging site — we run the script, verify data integrity, and fix issues.
  5. Production migration — we execute the transfer during low-traffic hours.
  6. SEO redirects and verification — we set up 301 redirects and check indexing.
  7. Team training and handover — we train your staff in Bitrix administration.
  8. Post-migration support — we monitor the site for 30 days post-launch.

Timeframe Estimates

Stage Typical Duration
Audit of MODX structure, TV, extensions 1 day
Infoblock design and TV mapping 1 day
Migration script development (content) 2–3 days
miniShop2 (if present) 2–4 days
Images and media files 1 day
Redirects and SEO 1 day
Testing 1 day
Total 7–11 working days

Without miniShop2, MODX migration is relatively fast — the data structure is straightforward, and TV variables map well to infoblock properties.

What’s Included in Our Service

  • Full audit of MODX structure: resources, TV, extensions, miniShop2.
  • Infoblock design and field mapping.
  • Custom migration script development: content, TV, images, orders.
  • Trade offer transfer and setup (if applicable).
  • 301 redirect configuration and indexing check.
  • Team training in Bitrix.
  • 30-day post-launch support.

Ready to Upgrade?

Contact us for a free consultation — we'll assess your project and provide a tailored quote.