Migrating a Website from Another CMS to 1C-Bitrix

Imagine: your online store on OpenCart lags with 10,000 products, and the integration with 1C hasn't worked for a month. You decide to migrate to 1C-Bitrix. But migration is not copying files. Data structures are fundamentally different: in OpenCart products are stored in oc_product, oc_product_attribute, oc_product_option, while in Bitrix — in b_iblock_element and property tables of information blocks. If you simply copy an SQL dump, you'll get broken URLs, lost orders, and traffic drop. Over 7 years we have performed more than 80 migrations to Bitrix without a single failure. We preserve SEO and customer data. Guarantee stable operation after launch. Migration through our ETL pipeline saves up to 40% of the budget compared to rewriting the site from scratch.

For example, in one project we migrated a catalog of 25,000 products from OpenCart to Bitrix in 4 weeks. We used streaming upload via CIBlockElement::Add with batches of 500 elements. This avoided timeouts and preserved data without loss. Before migration we conduct an audit: check DB structure, encodings, data volume. Then we write ETL scripts in PHP 8.1 using Composer and our own migration framework.

What needs to be audited before migration?

The first step is inventory of what needs to be transferred. Errors at this stage lead to data loss or weeks of rework.

Content:

• Static pages (count, URL structure)
• News, articles, blog (volume, tags, categories)
• Galleries and media files

Catalog (for stores):

• Number of products and SKUs
• Attribute/characteristic structure
• Prices and stock
• Product images

Users and orders:

• Customer database (emails, hashed passwords)
• Order history
• Bonus points and discounts

SEO:

• Current URLs and their structure
• Meta title/description for all pages
• Sitemap and robots.txt

Typical data mappings

WordPress → Bitrix (content):

OpenCart → Bitrix (catalog):

Migration script: approach

Migration is implemented via PHP scripts working with the Bitrix API. Direct DB table writes are used only for bulk data, with subsequent index rebuild.

Example product migration via API:

// Read product from source (OpenCart DB)
$ocProduct = $sourceDb->query("SELECT * FROM oc_product WHERE product_id = ?", [$productId])->fetch();
$ocDesc = $sourceDb->query("SELECT * FROM oc_product_description WHERE product_id = ? AND language_id = 2", [$productId])->fetch();
$ocImages = $sourceDb->query("SELECT * FROM oc_product_image WHERE product_id = ? ORDER BY sort_order", [$productId])->fetchAll();

// Create element in Bitrix
$el = new CIBlockElement();
$elementId = $el->Add([
    'IBLOCK_ID'         => CATALOG_IBLOCK_ID,
    'NAME'              => $ocDesc['name'],
    'CODE'              => \Bitrix\Main\Text\StringHelper::translit($ocDesc['name']),
    'DETAIL_TEXT'       => $ocDesc['description'],
    'PREVIEW_TEXT'      => $ocDesc['meta_description'],
    'ACTIVE'            => $ocProduct['status'] ? 'Y' : 'N',
    'IBLOCK_SECTION_ID' => getCategoryMapping($ocProduct['manufacturer_id']),
    'PROPERTY_VALUES'   => [
        'ARTICLE'  => $ocProduct['model'],
        'WEIGHT'   => $ocProduct['weight'],
        'BRAND_ID' => getBrandMapping($ocProduct['manufacturer_id']),
    ],
]);

// Upload main image
if ($ocProduct['image']) {
    migrateImage($elementId, $sourceImgPath . $ocProduct['image'], 'DETAIL_PICTURE');
}

// Upload gallery
foreach ($ocImages as $img) {
    migrateImageToGallery($elementId, $sourceImgPath . $img['image']);
}

// Set price
CCatalogProduct::Add(['ID' => $elementId, 'QUANTITY' => $ocProduct['quantity']]);
CPrice::SetBasePrice($elementId, $ocProduct['price'], 'RUB');

How to preserve SEO during migration?

This is the most commercially sensitive part. Losing search positions when changing CMS is a real risk.

URL preservation strategy:

1. Build mapping of old URLs → new URLs in Bitrix
2. Set up 301 redirects via .htaccess or nginx
3. In Bitrix, set symbolic codes (CODE) of elements and sections as close as possible to old URLs

# .htaccess — redirect old WordPress URLs
RewriteRule ^blog/(.+)/$  /news/$1/  [R=301,L]
RewriteRule ^product/(.+)/$  /catalog/item/$1/  [R=301,L]

Meta title and description are transferred to infoblock properties or via the Bitrix SEO filters module. A redirect map is a mandatory project artifact, exported to CSV for verification.

User transfer

Passwords from WordPress (bcrypt) cannot be transferred directly — the hashing algorithm in Bitrix is different. Options:

• Force reset — users receive an email to set a new password
• Temporary login by email — on first login after migration, only email is requested, then set new password
• Hybrid hash — on login, first check password with old algorithm, if success rehash to Bitrix format

The third option requires a custom authorization handler but preserves UX — users don't notice the migration.

Why migration via API is safer?

Direct database writes risk integrity violations. Bitrix API ensures data validation and correct handling of events. For example, when creating an element via CIBlockElement::Add, the events OnBeforeIBlockElementAdd and OnAfterIBlockElementAdd are automatically triggered. This is critical for systems integrated with 1C or CRM. API migration reduces the risk of data loss by 3 times compared to direct DB copying.

Testing and acceptance

After migration — data reconciliation:

# Reconciliation pseudocode
source_count = source_db.query("SELECT COUNT(*) FROM oc_product WHERE status=1")
bitrix_count = bitrix_db.query("SELECT COUNT(*) FROM b_iblock_element WHERE IBLOCK_ID=? AND ACTIVE='Y'", [CATALOG_IBLOCK_ID])
assert source_count == bitrix_count, f"Product count mismatch: {source_count} vs {bitrix_count}"

Checked: number of products, sections, users, orders. Randomly — content of 20–30 elements.

What's included in the work

We provide a full range of services:

• Detailed audit of the source CMS with a report
• Development of migration scripts
• Transfer of all data (content, catalog, users, orders)
• Configuration of 301 redirects and SEO preservation
• Integration with 1C, payment systems (YooKassa, Sber), delivery services (CDEK, Russian Post)
• Functional testing and data reconciliation
• Site administrator training
• 30-day warranty support after launch

Timeframes

Migration from another CMS is a full-fledged development project. The quality of the result depends on the depth of the initial audit. Assess your project — contact us for a free consultation. Migration cost is calculated individually based on data volume.

Sources: 1C-Bitrix on Wikipedia, CMS.

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.