Migrating CS-Cart to Bitrix: where data and SEO get lost
Migrating a store from CS-Cart to 1C-Bitrix breaks not the engine but the connections between entities: addresses, product properties, and stock.
The section tree, URL templates, and catalog structure are designed differently on the platforms, so a direct database export leaves part of the store nonfunctional.
The first gap is addresses. In CS-Cart, a human-readable URL is built from the category tree and SKU, while in Bitrix it is built from section symbolic codes.
Without a 301 redirect map, old links return 404, and accumulated link equity is lost: broken links after migration are recorded in Webmaster Tools within the first day of crawling.
The second is product properties. Characteristics that in CS-Cart were stored as one set in Bitrix split between catalog properties and trade offers: sizes, colors, configurations.
Without a mapping matrix, filters lose some items, and product pages return to search results without titles and descriptions.
The third is stock desynchronization. Until the exchange with the accounting system is configured, the site shows availability from an outdated snapshot, and the customer places an order for an item that is not in stock.
At the same time, search results decline: duplicates from pagination and filters without canonical URLs, and a sitemap with old links.
The gaps appear not on launch day but in the second or third week, when search engines crawl the new site. That is why migration is built around an address map, a property mapping matrix, and a stock exchange procedure — we look at how to close this before switching the domain.
Migration effect: catalog speed, orders, and roles
Catalog speed, unified order accounting, and predictable recovery are not promises that "it will get better" but parameters that we record at the start and verify after migration. Below are four effects that the customer sees in the first weeks of working on the new platform.
The catalog stays responsive on large datasets
Sections, properties, and trade offers are migrated so that filters and sorting work by indexes rather than by brute force.
On a sample of tens of thousands of items, a category listing is served in fractions of a second instead of seconds — this is the difference between browsing and leaving. Catalog caching is configured so that price and stock uploads do not reset it entirely.
Orders converge in a single environment
Order placement, payment, and statuses stop living separately from warehouse accounting: an order is created on the site and immediately visible in the accounting system with the same items and prices.
The share of orders processed without manual correction by a manager grows, and discrepancies in stock and repeat inquiries due to abandoned carts decrease.
Recovery fits within the procedure
Backup is divided into levels — files, database, configuration — with verification of copy integrity, not just the fact that it was created.
Recovery time after a failure is reduced from hours to tens of minutes, and rollback to the previous state is performed according to a proven scenario rather than improvised.
A class of failures that lingered for years is gone
On the old platform, failures were caused by extension modifications and updates that broke compatibility. After migration, the logic lives on the platform core with predictable extension points, so updates are installed without stopping the store. It was this departed class of failures that most often was the hidden cost item in maintenance.
Migration options: one-time, phased, parallel
The migration mode is chosen based on two parameters: how closely the catalog is tied to the accounting system and how many hours of storefront downtime are acceptable.
The first step is common to all options — a staging environment with a copy of the database, media, and current address structure, where the transfer of the catalog, properties, and trade offers is tested.
| Option | When it fits | Limitations |
|---|---|---|
| One-time transfer | Small catalog, off-season, there is a downtime window | The storefront is unavailable at the moment of switching; errors are fixed on the live site |
| Phased migration | Catalog is tied to 1C, control is needed at each wave | Longer timelines; for part of the period, two systems run with synchronization |
| Parallel, without stopping sales | High traffic or season, orders cannot be lost | More complex: dual order intake circuit, stock synchronization until switching |
Migration without stopping sales is built on a dual circuit: the old storefront continues to accept orders, and they are transferred to 1C-Bitrix in batches, with stock reconciled until the very switch.
On the staging environment, redirect rules and the address map are checked in advance — otherwise accumulated search traffic goes to 404 on the very first day.
The phased option is chosen when the catalog is large and tied to accounting: sections, groups, and trade offers are transferred in waves, and after each wave prices, stock, and image associations are reconciled. The price of this mode is a longer timeline and the need to maintain both systems simultaneously.
One-time migration remains a workable solution for compact catalogs: it is cheaper in resources and ends with a single switch. We look at which mode will suit your traffic and seasonality.
Migration stages: from catalog audit to launch
Migration from CS-Cart to 1C-Bitrix breaks not during product transfer but on stock, page addresses, and connections with the accounting system.
That is why the work follows a fixed sequence: first we describe the current state, then transfer to a closed environment, and only then switch the live site.
- Catalog audit — we export sections, products, trade offers, properties, prices, and warehouses, and count duplicates and items without a category.
- Data transfer map — we map entities: sections to information blocks, product variants to trade offers, warehouses to warehouses; define rules for prices and units of measurement.
- Receiver setup — we assemble information blocks, price types, and output templates before loading, so data lands directly in the target structure, with no edits afterward.
- Transfer and verification on staging — we reconcile the number of items, totals, and associations using control samples. Separately, we check stock by warehouse and behavior at zero stock: this is where figures most often diverge from the accounting system.
- Addresses and metadata — we build a redirect map from old addresses to new ones, preserve titles and descriptions, update the sitemap so traffic does not drop.
- Switchover — we change addressing in an agreed window, stop catalog edits on the old engine, and keep the exchange under observation for the first day.
- Project handover — access, exchange scheme, procedure for updating prices and stock, instructions for editors, and a rollback point to the previous version.
Data map, access rules, and migration procedures
After the migration is delivered, the customer is left not only with a working site but also with a set of documents according to which their team can develop the resource without a contractor.
We assemble this set during the migration from CS-Cart to 1C-Bitrix, rather than reconstructing it from memory at the end: otherwise some decisions remain in correspondence and leave with the contractor.
- Data schema — mapping of entities: products and trade offers, catalog properties, warehouses and stock, discounts and cart rules, order statuses, links to accounting system reference data.
- Access rules — roles in the admin panel, rights to catalog sections, separation of text and price edits, procedure for granting and revoking access for external contractors.
- Migration procedure — export order, window for stopping order acceptance, sequence of steps, and rollback points to the previous state if reconciliation does not match.
- Administrator guide — typical operations with notes on where an action is irreversible: product publication, return processing, exchange with the accounting system, manual stock synchronization.
- Reconciliation protocol — control numbers for the catalog, categories, orders, users, and page addresses before and after migration, with discrepancies for each item.
- Address map and merge rules — correspondence of old addresses to new ones, handling of duplicates, filter parameters that must not enter the index.
- Backup and update procedure — backup frequency, storage location, recovery procedure, and verification of platform update compatibility with modifications.
Such a set removes the main risk of contract development — dependence on a single contractor. A new administrator figures things out from the guide rather than by trial and error, and an outside team gets involved using the data schema.
Case study: migrating a store with 40,000 SKUs
The project is an electronics store with 40,000 SKUs, some with trade offers by color and volume. The catalog served a category page in 3-4 seconds, and stock arrived from the accounting system once a day: managers confirmed orders for items that were no longer in stock.
Starting point
A selection by three filters was recalculated on every request — 40,000 items and 120,000 offers. Up to 6-7% of orders failed with an error at the confirmation step, and carts were lost along with them.
During sales peaks, the catalog was finished off by load: some pages returned a server error. Metrics before and after were taken from application and accounting system logs, not by eye.
Catalog migration and switchover
Products, properties, and offers were exported through an intermediate layer and reassembled into 1C-Bitrix information blocks with separate indexes for filterable properties. Page addresses were matched one-to-one and covered by a redirect map, so search traffic did not drop. The catalog migration took three weeks with two test runs on a full export.
The exchange with the accounting system was made regular — stock updates every 15 minutes. Catalog response with filters is fractions of a second instead of 3-4, and the share of orders without checkout errors is 99.5%.
The switchover was done in a night window, about four hours, with rollback to the old site available for a week.
What to do with customizations that are not on the new platform?
Short answer: code is not transferred line by line. First comes an inventory — a list of all non-standard customizations and extensions on the old platform. For each item, we record not "how it is written" but what task it solves in the process and what data it uses.
The first group is customizations that existed only because of the limitations of the old system. Discount logic, delivery rules, catalog storefront, promotions — on the new platform these are covered by built-in mechanisms, and the code does not need to be transferred at all. Such an item leaves the register with the note "closed by configuration".
The second group is truly unique logic: exchange with the accounting system, non-standard calculation, a personal account for a specific process. We transfer it not by modifying the core but through extension points — a custom module, event handler, or separate component.
The compatibility of solutions rests precisely on this: a platform update does not overwrite the customization.
The third group is what is consciously not transferred: accumulated patches, duplicates, workarounds for the old version. Third-party extensions without an equivalent are covered either by our own implementation or by a suitable service with data exchange. Each such decision is agreed separately — this is already a process change, not a migration.
The result is a register of customizations with a verdict for each item and a set of test scenarios. Only value-creating logic moves to the new platform; the technical debt of the old system stays behind.
Technical doubts before migration: frequently asked questions
The doubts voiced at the start of a migration are almost always technical: will the data survive the move, and will positions drop in search? We address the ones that come up most often — before work begins, because the scope and order of stages depend on the answers.
The logic is simple: we do not migrate "however it turns out" but according to a pre-built mapping.
First we record the structure of the catalog, properties, addresses, and orders on the current site, then reproduce it on the new platform — after switching, nothing has to be recreated manually.
Will product properties and trade offers be transferred completely?
We transfer property reference books, their types, multiple values, and links to sections, as well as trade offers with stock.
The platforms' data models differ, so we reconcile disputed entities using a mapping table and show it before migration — you see in advance where each field will go.
Will page addresses be preserved? Will positions drop?
We build an "old address → new address" map and configure permanent redirects; address templates repeat the previous structure. After migration, we run the list through a crawl and compare it with the original — discrepancies are found before a search bot sees them.
What about order history and the customer database?
Orders, statuses, item composition, and links to customers are transferred; old numbers are preserved so support can find them by the usual identifier. Personal data is transferred in a closed environment, and access to it remains limited to a small group of employees.
Let's discuss the task: what to send for an accurate estimate
An accurate migration estimate comes not from inspecting the storefront but from data: the fuller the snapshot of the current store, the fewer assumptions in the work plan and the fewer surprises in the middle of the project.
Below is a list of what is enough to send to discuss the task substantively. If something is missing, it is not critical — we will collect part of it ourselves using access.
- access to the admin panel and database (or a fresh dump) — from it we see the actual catalog volume, property structure, and depth of order history;
- product export with sections, characteristics, prices, and stock — it is needed to design category mapping in advance and not lose trade offers;
- orders for a relevant period with statuses, payment, and delivery methods — this is transferred by separate logic, not "however it turns out";
- list of modules and customizations of the current system — the most common reason for underestimating migration scope;
- list of addresses that currently bring search traffic, and a table of current links — based on them we build redirect rules so positions do not drop;
- description of integrations: warehouse, accounting, delivery services, newsletters, personal account;
- your inputs: timelines, readiness to go in stages and work on a copy in parallel with the production site.
Describe the task in any convenient form — a link to the site and a short message with inputs already give us a basis for estimate data. We will come back with a migration estimate, a staged work plan, and a list of risks that should be closed before launch.