Complete Data Transfer: Moving Your Store from Magento to 1C-Bitrix

A Magento 1 store owner faces the need to migrate due to end of support and 1C integration requirements. Magento (especially version 1.x) uses the EAV model (Entity–Attribute–Value), where product attributes are scattered across dozens of tables. This complicates maintenance and slows queries for catalogs over 10,000 products. Bitrix with infoblocks v2.0 and ORM provides a flatter and faster structure, especially with tagged caching. Our expertise in ecommerce data migration ensures a smooth transition. We have completed more than 30 migration projects from Magento to Bitrix and guarantee data integrity at every stage. Typical project costs range from $2,000 to $20,000 depending on complexity.

Why Magento isn't always the best choice?

Integration with 1C via CommerceML is built into Bitrix, while Magento requires a third-party module or hacky synchronization. This reduces the total cost of ownership after migration. Moreover, in Magento 1.x, the EAV model requires JOINs across 5-6 tables to get full product data. In Bitrix, data is stored in a single infoblock table, accelerating queries. Bitrix is 4-8 times faster for product listing pages than Magento.

Problems we solve during migration

EAV model and performance

With catalogs over 10,000 products, Magento starts to lag on typical queries. In one project (an online clothing store with 12,000 products and variations), catalog page generation time reached 8 seconds. After migration to Bitrix with tagged cache, pages loaded in 1-2 seconds. This is critical for conversion.

Configurable products

In Magento, a configurable product is a parent with child simple products linked via catalog_product_super_link. In Bitrix, this hierarchy translates to the catalog infoblock (parent) and trade offers (children). Variation attributes (size, color) become SKU properties. We preserve all links and prices for each variation.

Orders and customers

Magento's customer base (table customer_entity) maps to Bitrix users. Orders migrate via CSaleOrder::Add() with reconstruction of order items and statuses. Order history in the personal account is restored — critical for B2B clients. In one project, we transferred 50,000 orders in 3 days without loss.

How we transfer data without loss

Export products from Magento

The standard Magento CSV export does not include media files and pricing for different customer groups. For a full export, SQL is more reliable:

-- Get products with name and price (Magento 1)
SELECT
    p.entity_id,
    pv.value AS name,
    pt.value AS description,
    pd.value AS price,
    p.sku,
    p.type_id
FROM catalog_product_entity p
JOIN catalog_product_entity_varchar pv
    ON p.entity_id = pv.entity_id AND pv.attribute_id = 71 AND pv.store_id = 0
LEFT JOIN catalog_product_entity_text pt
    ON p.entity_id = pt.entity_id AND pt.attribute_id = 72 AND pt.store_id = 0
LEFT JOIN catalog_product_entity_decimal pd
    ON p.entity_id = pd.entity_id AND pd.attribute_id = 75 AND pd.store_id = 0
WHERE p.status = 1;

attribute_id values must be determined for the specific Magento installation via the eav_attribute table.

Transfer categories and section tree

Magento categories are stored in catalog_category_entity (EAV). Hierarchy is defined by the path field (e.g., 1/2/5/12). In Bitrix, we recreate infoblock sections with corresponding nesting, preserving metadata and display settings.

Prices and customer groups

Magento supports tier pricing (by volume) and customer group pricing. In Bitrix, this is implemented via price types (b_catalog_price_type) and discount rules. We map Magento customer groups to Bitrix user groups and configure corresponding price types.

Our work process

1. Audit the source Magento database: catalog structure, attributes, products, orders, customers.
2. Write migration scripts in PHP accounting for the EAV model.
3. Transfer products with attributes, images, and relations.
4. Transfer orders, customers, addresses, and history.
5. Configure prices and customer groups.
6. Develop a new template on Bitrix (Magento design is not transferred).
7. Test all functions: catalog, cart, checkout, personal account.
8. Train administrators to work in Bitrix.
9. 30-day post-launch support.

Every project includes: documentation of data mapping, access to a staging site, training for your team, and 30 days of post-launch support.

Estimated timelines

Concurrently with data transfer, the Bitrix site template is developed.

Our experience and guarantees

We are certified Bitrix specialists with over 30 migration projects. We guarantee that all data (products, orders, customers, prices) will be transferred without loss. After launch, we provide documentation and 30-day support. Contact us for a project evaluation to determine the optimal migration plan. Get a consultation on your project to learn exact timelines and cost.

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.