Migrating an online store from Bitrix to WooCommerce without data loss

When an online store is migrated from Bitrix to WooCommerce, the products usually make it into the new store in full. Customers with their passwords and the order history get lost much more often: the built-in WooCommerce import only loads products, and a single order in Bitrix is spread across at least five database tables. Below is the step-by-step process for migrating a store from Bitrix to WordPress and WooCommerce: an audit of the old website, the catalog, customers without a password reset, orders, Google rankings and checks before the switchover.

Audit: what the website has now

The move starts with an inventory of the website: by launch day, every page, feature and group of data should have a decision attached (migrate, change or remove).

List of all URLs

The full list of URLs is collected from three sources, and each one shows something different:

• sitemap.xml: pages that Bitrix included in the sitemap according to its settings;
• a crawler (a program that goes through a website by following links, such as Screaming Frog): everything that has internal links pointing to it, including images and PDFs;
• Google Search Console, the “Performance” report by page: the URLs people actually arrive at from search, including old promotions and discontinued products that have long been gone from both the menu and the sitemap.

In a Bitrix store, the list includes URLs the owner usually does not remember: pages ending in index.php, pagination like ?PAGEN_1=2, smart filter pages with /filter/…/apply/ and files from the /upload/ folder (photos, price lists, manuals). All of them will later go into the redirect map.

Export clicks and impressions by page from Search Console right away, for at least a year: after launch, you will need something to compare traffic against. For a large catalog, exporting through the Search Console API is more reliable.

Also save the “Links” report: the list of websites that link to yours. Check these URLs in the redirect map first, and after the move, ask the owners of the most valuable websites to update their links to the new ones.

What the website does besides the storefront

List all of the website’s features: data exchange with the accounting system, online payment, shipping cost calculation, exports to marketplaces and price aggregators, emails to customers, the customer account, discounts and coupons, request forms. For each one, decide whether to migrate it as is, change it or drop it. Now is the easiest time to drop a feature that nobody uses.

What is migrated and how

Store structure on WordPress

The structure of the new store is designed before the import: if you load the products and think about URLs and the filter later, half of the work will have to be redone.

Page URLs

By default, WooCommerce builds URLs like this: a product is /product/product-name/, a category is /product-category/category-name/. In Bitrix, the catalog is usually structured differently, for example /catalog/section/product/. The base part of the URL is changed under “Settings → Permalinks”; reproducing Bitrix nested paths exactly sometimes requires custom code.

Our view: if categories and product pages bring noticeable search traffic, it is worth keeping the URLs. That means fewer redirects and fewer reasons for ranking fluctuations. If the old website’s structure is confusing and search engines barely value it, the URLs can be changed, but the redirect map must cover every old URL.

Specifications and the filter

Product properties from Bitrix end up in WooCommerce either as attributes or as custom fields. Attributes are used in the filter and in product variations, while custom fields are simply displayed on the product page.

A typical situation: the old filter has 20 specifications, customers use three or four of them, and some products have half of their values empty. The move is a convenient moment to clean this up: decide which properties will become attributes, which will stay as text on the product page and which are not needed at all. Check that values are consistent: “Blue”, “blue” and “Blue ” with a trailing space will become three different filter values after the import.

Staging copy

The new store is built on a staging copy or a subdomain that is closed to indexing. The old website keeps taking orders all this time, so right before the switchover a final incremental sync is run: orders, new customers, changed passwords and stock that appeared after the first migration. For those hours, catalog edits on the old website are frozen.

Before launch, the indexing block is removed: Google specifically warns that a forgotten noindex or a block in robots.txt prevents the new website from being indexed.

If you are still choosing how your future store will be built, see what is included in online store development on WordPress.

Migrating products to WooCommerce

When the standard import is enough

The built-in CSV product import creates simple and variable products, loads attributes, pulls images by URL into the media library and updates products found by ID or SKU. The limitations are described in the same documentation:

• you cannot assign your own ID to a new product: WooCommerce will give it the next available number;
• the import does not add or update image alt text;
• if the old website’s hosting does not serve an image by its direct URL, the image will not load and will have to be added manually.

For a catalog of simple products with a few specifications, CSV import is usually enough: export from Bitrix, convert the columns to the WooCommerce format, import, check.

When you need a script

A migration script is needed if the catalog has at least one of the following:

• product offers with their own prices, stock and photos;
• several price types (retail, wholesale): in Bitrix, prices are stored in a separate table and tied to types;
• related products, bundles, product documents, reviews;
• descriptions with links to other pages of the website: the links need to be rewritten to the new URLs, otherwise each one will go through a redirect.

In the Bitrix documentation, product offers are described as SKUs, “stock keeping units”. In WooCommerce, they correspond to the variations of a variable product: each gets its own SKU, price and stock, and the size or color values become attributes.

Keep the old identifiers. A product in Bitrix has an ID, an SKU and an “External code” field (XML_ID): the store is usually linked to the accounting system through the external code, and the old ID will be needed when migrating orders. Write all three values into the fields of the new product.

Images

Product photos in Bitrix are stored in the /upload/ folder, and their URLs change during the move. Google advises including the URLs of images, videos and files in the migration plan. If images brought traffic from image search or there are many of them, it is more reliable to copy the files directly and record “old path to new path” pairs in the same redirect map. Uploading by URL through the import works when there are few photos and they bring no traffic.

Customers and passwords without a reset

Customers

A customer in WooCommerce is a WordPress user with a billing address and a shipping address. When users are migrated from Bitrix to WordPress, the migration carries over the login, email, name, phone number, addresses from customer profiles and the registration date.

The main obstacle is duplicate emails. In Bitrix, the email uniqueness check at registration is disabled by default, and over the years one person accumulates two or three accounts with the same address. WordPress will not create a second user with the same email and will return the error “Sorry, that email address is already used!”. Before the migration, decide what to do with duplicates: usually the accounts are merged into one, and all orders are linked to it.

Passwords

Bitrix does not store passwords in plain text; the database only holds a hash, an irreversible “fingerprint” of the password. The system uses the hash to check the password entered, but the password itself cannot be recovered from it. So “migrating passwords” means migrating the hashes and teaching WordPress to check them.

According to the Bitrix core source code (the Bitrix\Main\Security\Password class), there are three kinds of hashes. Which one a given customer has depends on the Bitrix version and the server settings at the time the password was saved:

1. Modern SHA-512 format: the string starts with $6$ and is about 106 characters long.
2. Old format: a salt plus MD5 of the salt and the password.
3. Very old format: MD5 of the password without a salt.

Starting with version 6.8, WordPress checks passwords as follows. A hash of up to 32 characters is compared as a plain MD5, so the third Bitrix format works without any changes. A hash that is not in its own format is checked by WordPress with the standard PHP function password_verify(). It is compatible with crypt(), and Bitrix creates SHA-512 hashes precisely through crypt(), so the first format also works out of the box. For the second format, a small handler is written on the official check_password filter: it repeats the Bitrix algorithm and tells WordPress that the password is correct.

From there, WordPress takes over: after a successful login, it rehashes a password with a foreign hash format into bcrypt (with the $wp$2y$ prefix) and saves it to the database. This behavior is described in the announcement of the WordPress 6.8 switch to bcrypt. The customer enters their old password and logs in without noticing the move, and the Bitrix hashes gradually disappear from the database.

A password reset will be needed in three cases:

• the customer logged in through a social network and has no password;
• the website had a non-standard authorization module that stored passwords in its own way;
• after duplicates were merged, the account kept the password of one of the old accounts, and the customer remembers a different one.

For these customers, the usual “Forgot password?” link is enough. Before launch, check that emails from the new website are delivered and do not land in spam. We do not recommend a mass “change your password” email: it scares people and looks like phishing.

An export of customers with password hashes is personal data. Transfer the file over a secure channel and delete it from the servers right after the import.

Migrating order history

Why order history gets lost

In Bitrix, an order is stored in parts: the header in the b_sale_order table, line items in b_sale_basket, the full name, phone number and address in b_sale_order_props_value, payments in b_sale_order_payment and shipments in b_sale_order_delivery. A CSV export does not carry this structure, and the WooCommerce import does not load orders at all. What remains is a script that assembles each order from all the tables and recreates it in WooCommerce.

In new WooCommerce stores, since version 8.2 (October 2023), orders are stored in their own tables by default (High-Performance Order Storage, HPOS). The WooCommerce documentation requires working with orders through WooCommerce’s own functions, so the script creates orders through the WC_Order object, without writing directly to the database.

Pitfalls

• Dates. Through the WooCommerce REST API (an interface for external programs), you cannot set the order creation date: the field is read-only, so all orders would get the import date. The script writes the original date without restrictions.
• Stock. WooCommerce reduces stock when an order moves to the “Processing”, “On hold” or “Completed” status, regardless of how the order was created. So the script marks historical orders in these statuses in advance as having already reduced stock; otherwise the new store’s inventory will go negative. Canceled and failed orders must not be marked this way: based on the mark, WooCommerce will return to stock products that were never deducted, and the stock levels will be inflated.
• Emails. When the status changes, for example to “Completed”, WooCommerce emails the customer. If you do not turn off notifications for the duration of the import, customers will receive emails about long-closed orders from all the past years.
• Numbers. By default, the order number in WooCommerce matches its internal ID. Customers and managers remember the old numbers, so the old number is kept and displayed instead of the new one.
• Statuses. In Bitrix, order statuses are configured for each store. WooCommerce has a standard set: “Pending payment”, “Processing”, “On hold”, “Completed”, “Cancelled”, “Refunded”, “Failed”. You need a mapping table.
• Deleted products. Old orders contain products that are no longer in the catalog. The order line item still keeps the name, quantity and amount.
• Guest orders. Orders placed without registration are migrated without being linked to a user.

Migrate everything or archive it

If customers come back, log in to their account and repeat orders, the history is migrated to WooCommerce in full. If the history is only needed by managers for reference and reports, it is sometimes more sensible to export it to a separate archive: this costs less, but customers will not see their old orders in their account.

Accounting system, payment, shipping

The exchange with the accounting system that worked on Bitrix will not move to WordPress: it is a Bitrix module, and its settings, schedule and field mapping stay on the old website. On WooCommerce, the exchange is set up again, either with a ready-made plugin if one exists for your accounting system or with custom development. What fits depends on what the accounting system can send and receive; this is found out during the audit. The saved SKUs and external codes help here: the accounting system uses them to find the new website’s products without manual matching.

The following are reconnected and tested:

• payment systems (a test payment and refund on a real card);
• delivery services and shipping cost calculation;
• product exports to marketplaces and price aggregators;
• customer email templates and manager notifications;
• analytics counters and goals.

Redirects and SEO during the move

The main document on the subject is Google’s guide on moving a site with URL changes. Below is what applies to a store.

The 301 redirect map

A redirect map is an “old URL → new URL” table for every URL on the list collected during the audit. Google’s rules:

• Permanent server-side redirects, status code 301 or 308. Web server rules and a redirect plugin in WordPress are equally server-side for Google.
• No chains: the old URL leads straight to the final one. Chains appear unnoticed: the old website already had redirects from http to https and from www to the domain without www, and new ones are added on top. Google follows no more than three hops.
• Not to the home page. Google may treat a mass redirect of old pages to the home page as a “soft 404”: the server responds that the page is fine, but Google considers it an error and removes it from the index.
• A 404 or 410 code for everything you deliberately do not migrate. If a discontinued product has a direct replacement, the redirect leads to it.
• Images and files are also part of the map.
• At least a year. Google advises keeping redirects for as long as possible, generally at least a year. We do not remove them at all as long as they cause no problems.

Plan URLs with parameters separately: ?PAGEN_1=2 turns into /page/2/, and smart filter pages that brought traffic lead to the closest matching category or to the same filtered list on the new website.

Meta tags, canonical URLs, sitemap

• Title, description and H1 are migrated for every page that was in the index.
• Each new page points to itself in the code as the main version (the rel="canonical" tag). If the website has language versions, their cross-references (hreflang markup) are switched to the new URLs.
• Image alt text is written by a script, since the standard import does not transfer it. Product markup (price and availability in Google results) is checked with Google’s Rich Results Test.
• Internal links in menus, texts and product descriptions lead to the new URLs directly, without a redirect.
• The new sitemap.xml contains only the new URLs and is submitted to Search Console.
• The new website’s robots.txt blocks only service pages: the cart, checkout and the customer account.

Launch day

If the domain stays the same, you do not need the Change of Address tool in Search Console: it is only for changing domains. If the hosting changes, Google advises lowering the TTL of DNS records (the time providers cache the website’s IP address) to a few hours a week before the move and making sure that Search Console ownership verification survives the move. For example, the HTML verification file needs to be moved to the new server.

After the switchover, check the redirects: individual URLs with the URL Inspection tool in Search Console, and the full list from the audit with a script or a crawler. Then submit the new sitemap.

What happens to rankings

In the first weeks, rankings may fluctuate. Google says it plainly: search visibility changes temporarily during a move, and this is normal. On small and medium-sized websites, most pages move within a few weeks; on large ones, it takes longer. A promise that “rankings will not change for a single day” contradicts Google’s documentation.

In practice, a move with no loss of rankings means a move with no long-term loss. If traffic has not returned to its previous level after a few weeks, there is almost always an error: missed redirects, lost texts or a forgotten noindex.

After launch, keep an eye on four things:

• the “Pages” report in Search Console: 404 errors and pages excluded from the index;
• clicks by page compared with the export saved before the move;
• rankings for the main queries, once a week during the first month or two;
• 404 errors in the server logs: they include URLs that no crawler found.

Checklist before launch

Go through it on the staging copy once the data migration is complete.

Data

• [ ] The number of products, variations, customers and orders matches the old website (taking into account what was deliberately excluded).
• [ ] Variations have the correct prices and stock, and the photos are in place.
• [ ] Logging in to the customer account works with old passwords for each of the three hash formats.
• [ ] Old orders with their original dates and numbers are visible in the customer account.
• [ ] Duplicate emails are merged, and orders are linked to the right accounts.
• [ ] Orders, registrations and stock changes made on the old website during the work have been loaded.

Store

• [ ] A test order goes through the whole flow: cart, checkout, payment, email to the customer and the manager.
• [ ] The exchange with the accounting system has completed at least one full run.
• [ ] Shipping cost calculation and marketplace exports work.
• [ ] Emails from the website are delivered and do not land in spam.
• [ ] The catalog and product pages open no slower than on the old website (the causes are covered in the article “Why WooCommerce is slow”).

SEO

• [ ] Every URL from the audit returns 200, a 301 to the final URL, 404 or 410, without chains.
• [ ] Title, description and H1 are migrated, and the canonical points to the page itself.
• [ ] noindex is removed, and robots.txt does not block the catalog.
• [ ] The new sitemap is ready to be submitted to Search Console.
• [ ] The export of clicks and impressions from Search Console made before the move is saved.

Rollback

• [ ] Fresh backups of the old website and database exist; the old server is not shut down until the new one has run without failures.

How RIVERIT helps with the move

We offer migration of websites and online stores from Bitrix to WordPress. We migrate virtually any data, including customers and order history; what cannot be exported with standard tools, we migrate with scripts. We have already done moves from Bitrix to WooCommerce, and examples of Bitrix to WordPress migrations are collected in our case studies. After launch, we provide WordPress technical support for the store: technical SEO (sitemap, robots, redirects, indexing errors), updates, backups, website monitoring and response to requests within one hour during business hours.