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 — 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:

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 / msOrderProduct → b_sale_order / b_sale_basket.
• Prices from msProduct.price → b_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).

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

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.

Why URL Structure Matters in Bitrix Migration?

Skipping URL mapping during a website migration to Bitrix crashes organic traffic by 50–80% in two weeks. WordPress uses /product/item-name/, OpenCart uses /index.php?route=product/product&product_id=123, Bitrix defaults to /catalog/section/element/. Without a 301 redirect map, search engines index mass 404s. We start every migration with Screaming Frog scanning the old site, then compile a complete redirect map before writing a single line of code. Proper migration requires full URL mapping — every indexed page gets a correspondent.

Over seven years we have completed 50+ projects: landing pages, catalogs with 300,000 products, e‑commerce stores. Typical duration 2–8 weeks. Contact us for a free project estimate within one day.

How Migration Preserves SEO Positions

Losing organic traffic is the biggest fear, and it's justified. Here is how we avoid it.

• URL mapping 1:1 — where possible, via CUrlRewriter and infoblock SEF settings we keep the exact structure. When impossible — 301 redirect. Auto‑generation of redirect map: parse Screaming Frog export, match with new element slugs, generate nginx config. Each redirect verified with curl -I after switching.
• Transfer of meta tags — title, description, h1 moved into properties ELEMENT_META_TITLE and ELEMENT_META_DESCRIPTION. Canonical via Bitrix SEO component. Duplicates cut: www/non‑www, http/https, sorting parameters. Sitemap: new sitemap.xml generated by Bitrix seo module, submitted to Search Console immediately after DNS switch.
• Speed comparison — Bitrix processes a catalog of 100,000 products 3x faster than OpenCart due to tagged caching and query optimization for b_catalog_product.

What Data Gets Transferred?

Content — pages, articles, news → information infoblocks. Catalog: categories → sections, products → elements linked to b_catalog_product, properties → infoblock properties or highload directories. Images, reviews, FAQ.

E‑commerce — products with trade offers (SKUs), prices in b_catalog_price (multi‑currency via b_catalog_currency), stock balances b_catalog_store_product, discounts (b_sale_discount), order history (b_sale_order + b_sale_basket).

Users — client base b_user plus custom UF fields. Passwords are hashed differently: WordPress — phpass, OpenCart — SHA1+salt, Drupal — SHA512. We write a custom CUser::LoginByHash with fallback to old algorithm — client enters password once, system rehashes to Bitrix bcrypt.

SEO data — meta tags, alt attributes, URL structure. Main task: preserve every indexed URL or set 301.

Media — images, documents, videos — transferred preserving paths and optimized via CFile::MakeFileArray().

How to Plan a Successful Migration: 5 Key Steps

1. Audit — scan with Screaming Frog: all URLs, status codes, meta tags. Analyze DB structure, custom modifications, integrations. Create migration map.
2. Architecture design — map content types → infoblocks, fields → properties, directories → highload blocks. Architecture must be convenient for Bitrix administration.
3. Migration scripts — PHP scripts read from old DB (or API), transform and write via Bitrix API (CIBlockElement::Add, \Bitrix\Sale\Order::create). Re‑run during testing.
4. Staging — full migration to test server. Verify integrity: product count, properties, URLs, filters.
5. Final migration & switching — delta import, DNS switch, monitoring.

Typical Migration Mistakes and How to Avoid Them

Each of these errors has caused loss of positions and clients.

• Loss of URLs without redirects — the most destructive mistake. /product/123 instead of /catalog/item-name.html — without 301 this means mass 404s and traffic collapse. We auto‑generate the map and verify every redirect after switching.
• Content duplication — one product accessible with and without www, via HTTP and HTTPS, with GET filter parameters → five URLs instead of one. SEO weight dilutes. Set up canonical, 301 for variants, robots.txt with Disallow for parameters.
• Broken images — absolute URLs in content (src="https://old-site.ru/img/photo.jpg"), quality loss during compression. Replace with relative paths, transfer preserving structure, check HTTP 200 for each file.
• Loss of meta tags and microdata — title, description, Schema.org may not transfer. Do full mapping and verify on staging.
• Broken forms and integrations — changed IDs, API keys, webhooks. Compile integration register before start and test each after.
• Mobile version — old m.site.ru → responsive Bitrix. Without mobile URL redirect → 404 for mobile users. Include in redirect map.

Timelines and Cost Savings

Businesses typically save $3,000–$8,000 annually after migration — no old CMS license fees, reduced plugin and hosting costs. Annual hosting savings alone can reach $1,200. Add the affordable licensing cost of 1C‑Bitrix — it pays off quickly.

Contact us for a free migration estimate. We also provide a preliminary calculation within one day — request a consultation with our Bitrix specialists.