Features of Migration from Shop-Script to 1C-Bitrix

We often face the task of migrating from Shop-Script (Webasyst) to 1C-Bitrix. This solution is suitable for companies that have outgrown the capabilities of a lightweight eCommerce platform and need full-fledged integration with 1C, complex logistics, or extended functionality. In this article, we will explain how to transfer products, orders, and customers with minimal risks. Contact us to evaluate your project — turnkey migration takes from 2 weeks to 4 months depending on data volume. Our experience: over 10 years and 50+ successful migrations, we guarantee correct data transfer.

Why Migrate to 1C-Bitrix?

Shop-Script is an excellent solution for small stores, but when scaling a business, its capabilities often fall short. 1C-Bitrix offers built-in integration with 1C, trade offers, caching mechanisms, and a flexible permission system. According to our tests, on catalogs over 10,000 products, Bitrix with tagged caching is 3–5 times faster than Shop-Script. Additionally, the marketplace module and support for Federal Law 54-FZ make it the preferred choice for serious eCommerce.

Webasyst/Shop-Script Data Structure

Webasyst uses tables with the shop_ prefix (in MySQL database). The main ones:

• shop_product — products: id, name, url, summary (announcement), description, price, status
• shop_product_skus — SKUs: variations with price and stock
• shop_product_features — product characteristics (analog of infoblock properties)
• shop_product_features_values — characteristic values
• shop_category — categories
• shop_order — orders
• shop_order_items — order items
• shop_customer — customers (linked to the contact table of the Webasyst framework)
• shop_product_images — images

Webasyst also has a REST API through which data can be obtained without direct database access.

Retrieving Data via Shop-Script API

// Example request to Webasyst API
$url = 'https://yourstore.ru/api.php';
$response = file_get_contents($url . '?method=shop.product.getList&access_token=' . $token);
$products = json_decode($response, true)['response'];

The API returns products with a full set of data, including SKUs and characteristics. This is the preferred method if direct database access is not available.

Product Characteristics Mapping

Shop-Script supports typed characteristics: string, number, color, select, date. The structure maps to Bitrix infoblock properties:

Characteristics with type "color" in Shop-Script have special rendering — in Bitrix, the analog is implemented via visual editing of an L-type property with HTML color code.

SKU and Variations

Shop-Script stores trade offers in shop_product_skus with fields: id, product_id, name, price, count, sku (article). Linking to characteristic-variants is through shop_product_skus_features.

In Bitrix, these are trade offers of the catalog module. Each SKU from Shop-Script → a separate trade offer with corresponding properties.

Customer Base and Orders

Buyers in Webasyst are stored in two tables: contact (common, for the entire framework) and shop_customer (extended for Shop-Script). In contact there are: name, email, address fields.

SELECT
    c.id,
    c.name,
    ce_email.value AS email,
    ce_phone.value AS phone
FROM contact c
LEFT JOIN contact_data ce_email ON c.id = ce_email.contact_id AND ce_email.field = 'email'
LEFT JOIN contact_data ce_phone ON c.id = ce_phone.contact_id AND ce_phone.field = 'phone'
WHERE c.id IN (SELECT contact_id FROM shop_customer);

Buyers are created in Bitrix via CUser::Add(). Passwords are not transferred — only email and profile data. On first login, a password reset is offered.

Integration with Webasyst Applications

If the site uses other Webasyst applications (Blog, Photos, Helpdesk) — their data is migrated separately: blog → infoblock, photo galleries → Bitrix photo gallery or infoblock with images.

How We Perform Migration?

Our process consists of three stages: analysis and prototyping, development and testing, deployment and support. First, we prepare a technical specification, agree on the data schema, and set up the environment. Then we develop transfer scripts with verification on a test database. After successful testing, we deploy, configure integrations with 1C and payment systems. Finally, we conduct training and provide one month of warranty support.

What's Included?

• Audit of current database and data structure
• Development of a migration map (table and field mapping)
• Transfer of products, SKUs, characteristics, categories, orders, customers, images
• Setup of 301 redirects for SEO preservation
• Integration with 1C (exchange via CommerceML) and payment gateways
• Testing of data integrity and performance
• Training for administrators and delivery of documentation
• 1 month warranty support

Typical Timelines

The site template is developed from scratch on Bitrix — Webasyst themes are not compatible. Get a consultation — we will evaluate your project in 2 days and offer an optimal migration plan.

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.