Migrate from InSales to 1C-Bitrix: Data & SEO Safe

InSales is great for startups, but when business grows, SaaS limitations become a bottleneck: no direct database access, no custom code, complex external integrations. Migrating to a self-hosted CMS like 1C-Bitrix solves these issues. However, data transfer is tricky—data loss or SEO ranking drops are common. We have developed a methodology that eliminates these risks. In 8–10 working days, we move your store with full data integrity, minimal downtime, and guaranteed SEO preservation. Below are concrete steps and pitfalls gathered from over 50 projects. Automation via InSales API makes extraction 10x faster than manual export.

InSales Limitations and API Access

InSales is a SaaS platform. Data access is only through API or export formats—no direct SQL. The primary method is InSales REST API, with app key authorization and JSON responses. YML/CSV exports from the admin panel (products, orders) are also available.

Through InSales API, you can access:

• Products: GET /admin/products.json with variants, characteristics, images. Pagination of 100 records. Fields: id, title, body_html, vendor, product_type, variants[], collections[], images[], fields_values[].
• Variants (trade offers): contain sku, price, compare_at_price, quantity, weight, options.
• Categories: GET /admin/collections.json with parent_id.
• Orders: GET /admin/orders.json with line items, addresses, statuses. Date-limited.
• Customers: GET /admin/clients.json with addresses.

Data Collection Script

We write a PHP script that paginates through InSales API and saves data into intermediate format (JSON files or a temporary DB). We handle rate limiting: max 2 requests per second. For a catalog of 10,000 products (100 pages × 100 products), that's at least 50 seconds just for products.

GET https://{shop}.myinsales.ru/admin/products.json
Authorization: Basic base64(api_key:api_password)

Migrating Products, Variants, and Images

After collecting data, we build the import. Here is the field mapping table (InSales → Bitrix):

For variants: if a product has one variant, it's a simple product—price and stock go to the element. If multiple variants, we create trade offers in a separate info-block, with variant options becoming trade offer properties.

Images: API returns URLs to InSales CDN. We download via curl, save to server, register via CFile::SaveFile(). Important: after migration, InSales CDN may become inaccessible, so all images are physically copied. For further 1C synchronization, we use CommerceML.

Migrating Orders, Customers, and SEO

Step-by-step:

1. Fetch orders via GET /admin/orders.json.
2. Map statuses (new→N, confirmed→P, delivering→D, delivered→F, cancelled→C).
3. Create orders in b_sale_order via CSaleOrder::Add().
4. Create customers via CUser::Add(); for guest orders, either create without registration or create a user by email.

InSales stores SEO fields (seo_title, seo_description)—we extract them via API (fields fields_values or separate attributes). URLs in InSales follow /products/{handle} and /categories/{handle}. We set up 301 redirects from old URLs to new ones.

InSales API Limitations

Not all data is available via API. InSales does not expose order change history (only current status), product view history, or analytics. If detailed history is needed, we ask the client to export via InSales admin panel before decommissioning the store.

Why API Automation Matters

Manual export via InSales admin is time-consuming and error-prone. Automation via API cuts extraction time to 30% of manual effort. For example, a catalog of 10,000 products takes 1 hour via API vs. over 3 hours manually. Automation also eliminates human error in field mapping. Budget savings from automation can reach 40%, freeing funds for store development. Contact us to assess the savings for your project.

Migration Process

Phases and Timelines

InSales API rate limiting is the main bottleneck. A large catalog (50,000+ SKUs) may require several hours just for data collection.

Typical Migration Mistakes

What Is Included in the Work?

Turnkey migration in 8–10 days. Includes:

• Full documentation of transferred data and structure.
• Handover of all access credentials and further operation instructions.
• 2-week warranty support after migration.

The cost is determined after a detailed analysis of your data volume and integration complexity. Contact us for a personalized assessment.

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.