Website Migration to 1C-Bitrix Services

Website Migration to 1C-Bitrix

The first thing that breaks during a migration is the URL structure. WordPress generates /product/item-name/, OpenCart uses /index.php?route=product/product&product_id=123, and Bitrix defaults to /catalog/section/element/. If you don't set up a 301 redirect for every indexed URL — search engines register mass 404s, and within two weeks traffic drops by 50-80%. We start every migration by scanning the old site with Screaming Frog and building a complete redirect map before writing a single line of code.

Platforms We Migrate From

Over the years, we've migrated projects from dozens of systems:

CMS:

• WordPress / WooCommerce → 1C-Bitrix. Tables wp_posts, wp_postmeta, wp_wc_product_meta_lookup → infoblocks and highload blocks. Product variations (WC Variable Product) map to trade offers (b_catalog_product).
• OpenCart / ocStore → 1C-Bitrix. Structure oc_product, oc_product_description, oc_product_to_category moves to the infoblock hierarchy. OpenCart's multilingual setup → language-specific property values.
• Joomla / VirtueMart → 1C-Bitrix
• MODX Revolution → 1C-Bitrix. MODX resources with TV variables → infoblock elements with properties.
• Drupal, PrestaShop → 1C-Bitrix

SaaS:

• Tilda → 1C-Bitrix (business outgrew the builder, needs 1C integration)
• InSales, Shopify → 1C-Bitrix
• Wix / Squarespace → 1C-Bitrix

Custom-built engines — we migrate even without documentation. We reverse-engineer the database structure and reconstruct business logic from the code.

What Gets Migrated

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

E-commerce: products with variations (trade offers in Bitrix), prices in b_catalog_price (multi-currency via b_catalog_currency), warehouse stock b_catalog_store_product, discounts via b_sale_discount, order history from b_sale_order + b_sale_basket.

Users: customer database — b_user + UF fields. Each CMS hashes passwords differently: WordPress uses phpass, OpenCart uses SHA1+salt, Drupal uses SHA512. We write a custom CUser::LoginByHash with a fallback to the legacy algorithm — the customer enters their password once after migration, and the system immediately rehashes it to Bitrix's bcrypt.

SEO data: meta tags (title, description), alt tags, URL structure. The primary goal is to preserve all URLs or set up correct 301 redirects.

Media: images, documents, videos — with path preservation and optimization via CFile::MakeFileArray().

Migration Process

1. Audit (1-3 days). We scan with Screaming Frog: all URLs, status codes, meta tags, images. We analyze the database structure, custom modifications, and integrations. The output is a detailed map: what goes where and how. This is where you discover that the "simple WooCommerce store" has 47 plugins and custom pricing logic.

2. Architecture design (2-5 days). Mapping: content types → infoblocks, fields → properties, lookups → highload blocks. The architecture doesn't just accommodate old data — it makes it usable within Bitrix.

3. Migration scripts (3-10 days). No manual copying. PHP scripts read from the old database (or API), transform, and write via Bitrix API (CIBlockElement::Add, \Bitrix\Sale\Order::create). Automation enables repeated runs — critical for testing.

4. Staging (1-2 days). Full transfer to a test server. We verify integrity: product count, property preservation, URL correctness, filter functionality. We run a 50+ item checklist.

5. Design/templates (1-4 weeks). Redesign means new templates. Without redesign — adapting the markup to the Bitrix template engine (template.php, result_modifier.php).

6. 301 redirects. A complete map in .htaccess or nginx.conf. Every indexed URL from the old site → the corresponding page on the new one. Miss one — lose a page from the index. Generated automatically, verified by script after the switch.

7. Final migration (1 day). Delta import of fresh data (orders and content created after the test migration), DNS switch, real-time monitoring. Usually done overnight — minimal impact on visitors.

8. Post-migration monitoring (2-4 weeks). We track Google Search Console and Yandex.Webmaster: indexing, positions, crawl errors. We watch traffic and conversions in analytics. Any deviations — we react immediately.

Preserving SEO Rankings

Losing organic traffic is the primary fear, and a justified one.

• 1:1 URL mapping — where possible, via CUrlRewriter and infoblock SEO-friendly URL settings, we preserve the exact structure. Where we can't — 301.
• Auto-generated map — we parse the Screaming Frog export, match it to new element slugs, and generate an nginx config. Every redirect is verified with curl -I after the switch.
• Meta tags — title, description, h1 are carried over as-is into ELEMENT_META_TITLE, ELEMENT_META_DESCRIPTION properties.
• Canonical — rel="canonical" via the Bitrix SEO component settings. We eliminate duplicates: www/non-www, http/https, sort parameters.
• Sitemap — a new sitemap.xml via the Bitrix seo module, submitted to Search Console and Webmaster immediately after the switch.

Integration Migration

External integrations are a separate layer:

• Payment systems — reconnection via sale.paysystem with transaction history preserved
• Shipping — configuration of sale.delivery.handler
• CRM — linking to Bitrix24 or preserving the current CRM via REST API
• 1C — setting up exchange via CommerceML. Often the primary reason for migrating to Bitrix.
• Email marketing — subscriber and template migration. Webhook reconnection.
• Analytics — e-commerce tracking adapted to the new dataLayer structure

Timeline

Common Mistakes

Each one means lost rankings and customers. Here's what we see most often.

Lost URLs without redirects. The most destructive mistake. /product/123 instead of /catalog/item-name.html — without a 301, this means mass 404s and a traffic collapse. We generate the map automatically and verify every redirect after the switch.

Duplicate content. One product accessible with www and without, via HTTP and HTTPS, with filter GET parameters — five URLs instead of one. SEO weight gets diluted. We set up canonical, 301s for variations, and robots.txt with Disallow for parameters.

Broken images. Absolute URLs in content (src="https://old-site.ru/img/photo.jpg"), quality loss from re-compression. We replace with relative paths, transfer with structure preserved, and verify HTTP 200 for every file.

Lost meta tags and structured data. Title, description, Schema.org — may not transfer or may transfer incorrectly. Full mapping and verification on staging before the switch.

Broken forms and integrations. IDs changed, API keys expired, webhooks invalidated. We compile a registry of all integrations before starting and verify each one after.

Mobile version. Old m.site.ru → responsive Bitrix. Without redirecting mobile URLs — 404s for mobile users. Accounted for in the redirect map.

Checklist

1. Full scan: Screaming Frog / Sitebulb — all URLs, images, PDFs
2. SEO export: title, description, h1, canonical, hreflang
3. Baseline ranking positions for key queries — without this, you won't know what changed
4. File and database backup. Verify that recovery works — in practice, not in theory
5. Integration registry: payments, shipping, CRM, analytics, email campaigns, call tracking
6. Redirect map: old URL → new for every indexed page
7. Test migration on staging with full verification
8. Mobile version: all pages correct, mobile URLs in redirects
9. New sitemap.xml ready for submission
10. Rollback plan: DNS records saved, config documented, access to old hosting retained