Migrating a site from Magento to Bitrix: where data gets lost
Migrating a site from Magento to Bitrix is not copying the database and files, but rebuilding relationships between entities.
In Magento, a product, its variants, and property values are different tables linked by identifiers; in Bitrix, the same structure is assembled from information block elements, trade offers, and properties.
Until the mapping is described at the schema level, the online store migration passes formally successfully and falls apart on live traffic.
The first thing to go is the address. Magento's catalog serves human-readable paths, filters, and pagination as separate pages; brand landings live in other sections.
Without a transition map built before the switch, the product page gets a new address, and the old one returns an error — this is exactly what incorrect page addresses after migration are: categories drop out of the index, external links and ads lead nowhere.
Next are catalog migration errors. Characteristics such as color or size migrate as text without linkage to reference books: filters stop building, comparison shows empty fields. Multiple product assignments to sections collapse into one, and some landing pages disappear.
Separately, warehouse stock and order history diverge: items reference non-existent products, and the customer sees an order without contents.
Data loss during migration almost always means the migration started with products rather than the data model. We explain how this is closed: first the mapping schema, then the catalog, orders, and addresses, and only after reconciliation — the domain switch.
What stops breaking after catalog and order migration
Product catalog migration breaks not on volume but on relationships.
A product, its trade offers, and characteristic values are three datasets linked by identifiers; with a direct "straight" transfer, offers lose their link to the parent, and catalog filters start showing empty values.
That is why the order is strict: first characteristic reference books, then products, then trade offers — with integrity checks at each step.
Preserving order history is the second point of failure. An order stores not only status and amount but also contents linked to a specific offer at the time of purchase.
If the link is not restored, in the customer account the customer sees empty rows, and a repeat order from history cannot be assembled. We migrate orders with statuses and items, and for discontinued products we keep archival records — the history remains readable.
Order export to the accounting system stops being manual. Exchange runs on a schedule via matching nomenclature by external keys: orders go to accounting, statuses and stock come back, and resending does not create duplicates.
On the 1C-Bitrix side, this is done with standard exchange tools, without custom intermediaries that fall off at the first update.
The result is checked at acceptance: the share of items with complete characteristics, the number of orders that lost their link to contents, the volume of manual edits in the first weeks.
These indicators are the criterion that catalog and order migration has been brought to completion, not "mostly."
Methods for migrating catalog and orders: comparison of approaches
Catalog and orders are migrated with different costs of error. Products, properties, and section assignments can be rebuilt again, but order history cannot: payment statuses, cart contents, and customer links are restored only from the export.
Therefore the method is chosen along two axes — acceptable sales downtime and the volume of customizations accumulated on the Magento side.
Four working scenarios
| Method | When it fits | Limitations |
|---|---|---|
| Full database export with shutdown | Catalog of several thousand items, downtime window agreed with the business | Site is closed for the entire migration, orders from the window are lost, a restart begins from scratch |
| Phased migration by sections | Large catalog, each section needs verification before publishing | Longer on the calendar, need to catch edits that continue to be made in the old catalog |
| Parallel operation of two sites | Sales cannot be stopped, there is stock exchange with 1C | Two sources of truth for stock and prices — matching rules are needed, more expensive to support |
| Manual catalog reassembly | Catalog is small and cluttered, an assortment audit is needed | Orders and customers are still migrated by export, accumulated descriptions and internal linking are not preserved |
In practice, a combination is more often taken: the catalog moves by sections with interim reconciliation, orders and customers — in one export in a short window, and traffic is switched with permanent redirects from old addresses. We explain what stages this consists of.
Work order: from structure audit to access handover
Migration is arranged as a sequence where each next step relies on the artifact of the previous one: if one is skipped, discrepancies in relationships surface after launch, when catalog and orders begin to live separately.
We start with a site structure audit — we assemble a map of sections, page types, product attributes, and user properties, and separately record non-standard customizations. In parallel, we take a snapshot of real database queries to calculate load by fact, not by description.
- Data inventory. We export catalog, orders, customers, content, and files, and compare record counts for each type: a discrepancy of even a couple of items signals losses during export.
- Designing the relationship schema. We describe which destination entity corresponds to the source one, how multiple assignments, trade offers, and old addresses are migrated. The data migration schema is agreed before work — a correction at this stage is cheaper than rework after launch.
- Setting up migration and exchange with the accounting system. We match product and counterparty keys, set frequency and priority rules so that stock and orders are not duplicated during synchronization.
- Control reconciliation after migration. We compare not only volumes but also checksums by items, image attachments, and the correctness of addresses and redirects from old pages.
- Running scenarios on a closed environment. We go through search, filters, checkout, and customer account, and record deviations before opening public access.
- Handover of accesses and documentation. We hand over the mapping table, exchange regulations, export instructions, and a list of accounts with role separation — support then works without us.
What the client receives after migration completion
Migration is not only data moved to a new system. After acceptance, your team has a set that allows the site to be developed and maintained on its own: a catalog relationship map, redirect rules, configured exchange with the accounting loop, and operating regulations.
- Catalog relationship map — correspondence of sections, products, properties, and media between the old and new structures: it shows where each item came from and what happened to it during migration.
- Redirect rules — a table of old and new addresses with permanent redirects, including category and product page pages, so that search traffic does not decline after the platform change.
- Integration schema with the accounting system — which reference books, prices, stock, and order statuses are synchronized, in which direction and at what frequency, and where to view the exchange log if there is a discrepancy.
- Administrator access rights — roles with separation by admin panel sections: who edits the catalog, who edits prices, who edits orders, who has access to settings and exports.
- Backup regulation — what is copied, how often, how long it is stored, and in what order restoration is performed with verification on a test environment.
- Content manager instructions — step-by-step scenarios: add a product, arrange images, publish a page, update a banner without breaking the template.
- Site documentation — module composition, key settings, integration points, and change log, so that further development does not start with studying someone else's code.
We hand over the package not as a "folder on disk" but with acceptance: the engineer goes through each item together with your team, shows the settings in the interface, and answers questions.
A month after launch, we reconcile exchange logs and indexing — discrepancies are handled as part of warranty work.
Case study: migrating a store while preserving search positions
A store on Magento with 4,300 items and 620 catalog sections lived with nightly stock export and some duplicate pages.
The owner wanted a store migration case without losing accumulated search history — over the years of operation, the catalog had gained positions for 2,800 queries.
What we did
The work was divided into four passes: section schema and address map, then assortment migration, then attributes and prices, and finally orders and customer history.
Old addresses together with filter parameters were entered into a mapping table of 3,400 rules and reconciled with an export from the analytics system.
Catalog migration timelines — three weeks; another week went to reconciliation and correction of 118 discrepancies in characteristics. The old environment operated in read-only mode until reconciliation was confirmed, so that rollback would take hours.
Result in numbers
Pages with markup errors became 1.4% versus 18% before the migration; duplicates are closed. Order processing in the admin panel decreased from 40 to 9 seconds; stock updates run every 15 minutes instead of a nightly run.
Migration without traffic decline was confirmed: 94% of addresses retained positions in the top 10; the store returned to initial metrics two weeks after the switch. The assortment was migrated in full — barcode reconciliation revealed no losses for any item.
What to do if part of the catalog has already been migrated to Bitrix
If the catalog was migrated in parts or some pages were rebuilt from scratch, the data in the two systems diverges: the same product exists in both the old database and the new catalog, but with different prices, descriptions, and page address.
A repeat export in such cases does not update the item but creates a second card — this is how product duplicates in the catalog, lost addresses, and manual edits appear, the volume of which grows with each new run.
A partially migrated catalog is dangerous precisely because of this: it looks ready until you start adding to it.
First, the matching key is fixed. The name and page address are not suitable for this — they are changed during redesign and text cleanup.
A stable identifier is the SKU together with the external record code from the old engine; it is stored as a separate card property, even if it is not displayed anywhere on the site.
Then additional data migration proceeds in update-by-key mode: existing items are filled, new ones are added, and duplicates do not arise.
Then work begins with the legacy of the old engine. Some items there are already discontinued, some addresses lead to deleted sections, and reviews and external links have accumulated.
A mapping table is built for this: old URL — new one, discontinued product — parent section page or redirect. Without the map, the transition period leaves broken links and declined traffic for brand queries.
While both stores are alive, synchronization of the two sites is done one-way and by delta. Prices, stock, and availability statuses are exported from the old system to the new one on a schedule, and editor changes go only to the new catalog.
Two-way exchange in this situation almost always produces version conflicts and overwrites the manual work of content editors.
Before disabling the source, reconciliation is done: number of items by section, selective comparison of prices and properties, report on records without a pair. The exchange must be repeatable — a second run changes nothing if the data has not changed.
After reconciliation, there remains one entry point: the old address goes to a redirect, and the catalog lives in one place.
Common technical doubts before starting migration
Doubts before migration usually concern not the move itself but what breaks after the new site is enabled: addresses, customer login, exchange with the accounting system.
Below are engineering answers to the questions most often raised at the assessment stage: what we migrate automatically, where manual reconciliation is needed, and how rollback to the old site is arranged until the new environment confirms stability.
What will happen to page addresses after migration?
We build a mapping table "old address → new" for all sections, products, and articles, not only the top level.
On the new environment, we set up permanent redirects, a sitemap, and error monitoring in the log: in the first weeks we track which addresses are still requested from external sources and add rules.
This way accumulated traffic moves together with the catalog rather than being lost on broken links.
How are customer data and their orders migrated?
We migrate profiles, delivery addresses, order history, and linkage to discount groups in full.
Passwords are stored in irreversible form and cannot be migrated between platforms — we send customers a password change email, and during the transition we leave a soft access recovery scenario. We keep orders and statuses with their original dates so that reporting does not diverge.
Can the catalog be migrated in parts?
Yes, and on large catalogs this is more reliable. We split the migration by sections or brands, and run each block separately: properties, prices, stock, images. While part is still in progress, the old site continues to serve customers, and switching proceeds by ready blocks. This way an error in one section does not block the launch of the entire project.
What about characteristics and trade offers?
We analyze the property structure in advance: what will become a product characteristic and what will become a separate offer with its own price and stock.
We migrate multiple values, units of measurement, and filters together with the data, otherwise the smart filter on the new site will start showing empty results. We separately reconcile product — offer links, because catalogs most often diverge on them.
How will exchange with the accounting system proceed after migration?
On 1C-Bitrix, we set up exchange with standard tools: we determine what becomes the source of truth for prices, stock, and orders, set an export schedule, and log discrepancies.
We do a test exchange run before opening the site — it shows which product groups drop out and how the accounting system behaves under load.
Let's discuss your store migration task
To discuss the migration task substantively, we need access to the real picture of the store, not a retelling.
A database copy, catalog export, and list of extensions speak about the scope of work more accurately than any description: it is immediately clear where the logic relies on non-standard customizations and where everything is solved with standard tools.
From the client, the following set is usually enough for an estimate:
- Accesses to the admin panel and a fresh database copy — on it we check the integrity of relationships between products, orders, and customers.
- Catalog structure: categories, properties, product variants, price and discount rules.
- List of integrations with the warehouse, payment services, delivery services, mailing services, and accounting systems.
- List of non-standard scenarios: customer accounts, wholesale price lists, loyalty programs, delivery calculation.
- Configured addresses and redirect rules — so that search positions do not decline after the switch.
- Analytics data for several months: which sections and scenarios carry the main load.
In response, we send a migration work plan: stages, correspondence of entities between the old and new platform, what migrates automatically and what requires manual reconciliation.
We separately record risks, the rollback procedure to the previous version, and the site support option after migration — update regulations, availability monitoring, and handling of requests.
Describe the task and send the listed items — we will return with an estimate of migration timelines and a clear plan.