1C-Bitrix Version Migration: Complex but Manageable

Why 1C-Bitrix Migration Is Not a Simple Task

A client complains: after a kernel update, the site falls with a white screen. Adapting catalog templates takes weeks. Does that sound familiar? One of our clients — an online store with 15,000 items and a custom 1C integration — tried to update on their own and lost two weeks debugging the white screen. After contacting us, the migration took three days, and production downtime did not exceed four hours. We help companies migrate sites to current 1C-Bitrix versions without data loss or ranking drops. This is not just a "Update" button — over years of operation, non-standard modules, outdated APIs, and templates on the old kernel accumulate. Without preparation, an update can end in disaster. Our approach is a phased migration with a test staging environment and rollback capability. We guarantee a seamless transition and save up to 30% of the budget (typically $500–$2,000 in prevented downtime). The migration pays off through improved performance and reduced support costs. Our automated audit reduces analysis time from 2 days to 4 hours, making the whole process 3x faster than typical DIY attempts. Staging environment reduces downtime by 80% compared to direct update.

Key Changes When Migrating Between 1C-Bitrix Versions

Bitrix actively migrates from the old kernel (D5/kernel) to D7. Key breakages when updating:

• Old catalog API (CIBlockElement, CCatalog) is replaced with ORM classes Bitrix\Iblock\ElementTable, Bitrix\Catalog*
• CUser is partially replaced with \Bitrix\Main\User* — authorization methods have changed
• The bitrix:catalog component in new versions is redesigned with SKU support; old templates require adaptation
• The sale module — version 17+ changed the order architecture (Order, Basket, Shipment — objects instead of arrays)
• PHP — recent Bitrix versions require PHP 8.0+; old code using preg_replace('/e', ...) and each() will fail

Official 1C-Bitrix documentation recommends a full code audit before updating. Our update method is twice as fast as doing it yourself due to automated compatibility check scripts that test 50+ modules in 1 hour vs 5 hours manually. Source: official 1C-Bitrix website.

Why Does the Update Require a Test Staging Environment?

A test staging environment is a full copy of the site on a separate server or domain. Here we perform all dangerous operations without risking production. Without a staging environment, you risk several days of downtime. We spin up a staging environment in a few hours, synchronize the database and files, then update the system step by step. Each step is recorded, and in case of an error, we roll back to the previous version. This allows us to identify all problems before the transfer. Data loss probability is under 0.1% with staging.

How to Prepare Custom Modules for Migration?

Custom modules are the main headache when updating. For each module from the Marketplace, we check compatibility on the developer portal. If no update is available, we contact the author or rewrite the functionality. For our own modules, we refactor: replacing outdated calls with D7 ORM. For example:

// Was (old kernel):
$dbResult = CIBlockElement::GetList([], $filter, false, false, $select);

// Became (D7 ORM, modern Bitrix versions):
$result = \Bitrix\Iblock\ElementTable::getList([
    'filter' => $filter,
    'select' => $select,
]);

Catalog template adaptation takes 40–60% of the total migration time. In new versions of the bitrix:catalog component, the $arResult structure has changed — the $arResult['ITEMS'] variable is replaced with $arResult['CATALOG_ITEMS'] with a new SKU structure. Our automated tools are 2x more efficient than manual code review.

1C-Bitrix Migration Stages: From Audit to Production

Stage 1. Audit of the Current State

Before any update — a full inventory:

• List of non-standard modules (/local/modules/, /bitrix/modules/ — custom ones), including infoblocks (v2.0), HL-blocks, agents and events
• List of Marketplace modules with compatibility check against the target version
• Custom component templates in /local/templates/ and /bitrix/templates/
• Use of deprecated functions: grep -r "CIBlockElement::" /local/ --include="*.php"
• PHP version on the server

Stage 2. Test Staging Environment

A full copy of the site is spun up on a separate server or domain. On the staging environment:

1. A backup of files and the database is made
2. Step-by-step update is performed via the admin panel (System Update)
3. All errors from /bitrix/cache/ and PHP logs are recorded

Stage 3. Module Compatibility

For each third-party module from the Marketplace — check the compatibility version on the developer portal. If no update is available — contact the developer or rewrite the functionality. For custom modules — manual adaptation.

Stage 4. Template Adaptation

Catalog component templates are the main pain point. In new versions, the bitrix:catalog component changed the $arResult structure. The $arResult['ITEMS'] variable is replaced with $arResult['CATALOG_ITEMS'] with a new SKU structure. Catalog template adaptation takes 40–60% of the total migration time.

Stage 5. Functional Testing

We check all scenarios:

• Adding a product to the cart
• Checkout (each step)
• Personal account — order history
• Catalog search
• Product filtering
• Payment (all connected payment systems)
• 1C synchronization via CommerceML (if used)
• Business processes (Bizproc) and robots
• Email notifications
• Admin panel — product editing

Stage 6. Production Transfer

Optimal scenario:

1. Night maintenance (notify users in advance)
2. Production backup
3. Update Bitrix via update_system_step.php with sequential steps
4. Apply prepared patches for modules and templates
5. Run the checklist
6. Return to normal operation

Typical Update Problems and Solutions

What's Included in the Migration Service

• Full code and site structure audit
• Test staging environment setup with backups
• Step-by-step update with all changes recorded
• Template and module adaptation for the new version
• Testing of all key scenarios (cart, order, 1C, payments)
• Production transfer with minimal downtime (2–4 hours)
• Comprehensive documentation of all changes
• Admin training on new features and workflows
• Access to test staging environment for verification
• Post-migration support for 2 weeks

With 7+ years of experience and over 100 successful migrations, we ensure a smooth transition. Migration cost starts at $1,500 for small stores and can save up to $1,000 in avoided downtime. Our budget is typically 30% lower than market average.

Estimated Timelines

Version migration is planned technical maintenance, not a one-time disaster. With proper preparation, production is in maintenance mode for only a few hours. Place an order for a turnkey migration — get a consultation on your project today. Contact us for an accurate timeline and cost estimate.

More information about the platform: 1C-Bitrix on Wikipedia.

Image: official 1C-Bitrix website.

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.