Migrating Magento 1 to 2: what breaks without a transfer plan
A store on an outdated version of Magento holds out until the first conflict: extensions for the old branch stop receiving updates, and some are already incompatible with the new architecture.
Connecting a new payment or delivery module becomes a workaround task, and no security fixes are released for the core — vulnerabilities are closed with patches in third-party code.
Support for the old version rests on people and the absence of a staging environment.
Engineers who remember how it works are increasingly scarce, documentation for customizations is often incomplete, and any modification happens without a test environment that replicates the production catalog and settings.
The second point of failure is data. Manual export of the catalog and orders causes desynchronization: some products transfer without attributes, some lose links to categories, and order history is transferred incompletely. The customer sees an empty product page or an order without status — and goes to a competitor.
The third is addresses. If an e-commerce store transfer proceeds without a redirect map, the old product and section URLs return 404, and accumulated links and search positions are wiped out within weeks. Restoring them later costs more than building the URL scheme in advance.
The transfer plan ties these parts into a single sequence of work: inventory of extensions, data transfer with convergence checks, a URL map, and a test environment on a catalog copy. Let's break down how this is covered step by step.
What a transfer to a supported platform delivers: the effect in numbers
Transferring from Magento 1 to a current branch changes not the appearance but the system's behavior under load.
On the old scheme, the catalog is assembled from several cache layers, and any attribute edit triggers a full reindex: a category page with filters responds more slowly as the number of products and attribute values grows.
After the transfer, a prepared layer serves the selection, indexes are rebuilt in parts, and the catalog response on listings and filters is reduced several times over — while it does not degrade as the assortment grows. Heavy filter combinations stop being a bottleneck.
Resilience to spikes also changes separately: a peak from a newsletter or sale used to knock out some pages and the cart, because reads and writes competed for the same resources.
Now reads are moved to separate nodes, writes go through queues, and the spike is spread over time instead of turning into an outage.
The time to ship changes also shrinks: editing a template, setting, or promo block, instead of manual deployment to the server, goes to production in one pass, and rolling back to the previous build restores a working state without manually sorting through files.
Indexing, cache warm-up, and static build run on a schedule, so the share of manual operations falls — along with the class of failures when updating a third-party module overwrote the theme or broke checkout.
Options for migrating Magento 1 to 2: comparing approaches
The choice of transfer option is determined not by catalog size but by the acceptable downtime window for the storefront and the volume of custom logic.
Magento 1 and Magento 2 have different cores, database structures, and template layers, so modules and themes are not transferred by copying but rewritten for the new architecture. Hence three working scenarios with different transition costs.
| Option | When it fits | Downtime window | Limitations of the approach |
|---|---|---|---|
| One-time transfer | Compact catalog, minimal customizations, several hours of downtime acceptable | Full, up to a day | Everything is transferred in a single run; errors in attributes, links, and pricing rules surface on the live storefront, and rollback affects the entire data set |
| Phased migration with a parallel storefront | Large catalog, orders and traffic run continuously | Almost zero, downtime only at the final switchover | Requires constant synchronization of orders, customers, and stock between systems; twice as many checks and more complex SEO URL reconciliation |
| Storefront-only transfer while keeping the server side | Logic and integrations are tied to the old core, which cannot be stopped | Minimal, for frontend switchover | Two systems live for a long time: part of the data comes from the new layer, part from the old core, and any change affects both sides |
The price for speed always shifts elsewhere. With a parallel storefront, it is the cost of synchronization and double testing; with a one-time transfer, it is the risk of a long recovery after a failure.
We lock in the approach after inventorying modules and measuring the load on the current system; otherwise the choice remains theoretical.
Transfer stages: audit, data schema, configuration, verification
The move from Magento 1 to 2 is not a reinstall but a transfer of data on which the store's operation depends: a catalog with price history, orders over several years, customers with addresses and discounts.
There is no way to restore them after loss, so the work proceeds in steps, and each next one begins after acceptance of the previous one.
- Store data audit. We inventory the catalog, attribute sets and values, categories, customers, address books, orders, pricing rules, and static pages: we count volumes, find duplicates, broken image links, and data that does not need to be transferred.
- Entity mapping schema. We compile a table of "source attribute → target attribute" with value type, requiredness, and attribute set. We separately describe order statuses, customer groups, and address types — discrepancies here cause losses during transfer.
- Environment configuration. We deploy the target platform on the current branch: language, DBMS, search service, cache, and message queues; configure indexing and separate environments for development and transfer rehearsal.
- Trial run on a copy. We transfer data to a full copy of the database and media files, measure time and resources, and catch type and encoding errors. There are usually two runs: after the first, the mapping schema is refined.
- Data reconciliation after transfer. We compare record counts for each entity, and selectively compare prices, stock, order history, address and image associations, and check redirects for old links.
- Switchover and support. We catch up on data growth, change routing, enable monitoring, and watch indexing and cart operation; for a while we keep the previous version available for rollback.
Handover artifacts: configurations, data schemas, policies
Handover of a Magento 1 to 2 migration is not only a working site but also a set of artifacts by which your team will continue the project without us.
We hand everything over to a repository next to the code: files are versioned, changes go through review, and do not live in chats and individual people's memories.
We agree on the list before work starts, so acceptance follows a checklist rather than feelings. Below is the minimum that remains with the customer after the old site is decommissioned.
- Environment configurations — test and production environment parameters, variables, build order: a local copy of the project comes up by instruction in a single run.
- Data transfer map — "source → destination" mapping for products, categories, orders, customers, and reviews, transformation rules, and behavior on repeated runs.
- Access and role separation policies — permission matrix in the admin panel, who can change the catalog and export data, and the procedure for granting and revoking access.
- URL handling rules — permanent redirect map from old links, priorities for conflicts, and a log of broken URLs after switchover.
- Update policy — branches, release windows, procedure for applying platform and extension updates, and rollback points to the previous working state.
- Team instructions — deployment, where to view logs, how to perform a rollback, what to do in an incident, plus an acceptance checklist for key scenarios.
Transfer case study: catalog and orders moved without losing positions
A store with a catalog of about 12 thousand SKUs and several years of order history was running on Magento 1 — it needed to sell without interruption, so the transfer of the catalog, customers, and orders was prepared in advance, and the storefront switchover was done in a short low-traffic window.
What was changed
The catalog was transferred through an attribute mapping schema: old sets were mapped to new ones, and product relations were reassembled by external identifiers rather than names — otherwise bundles and related items fell apart.
Order history was transferred while preserving the "customer — order — items" link; statuses and manager comments remained readable in the customer account instead of turning into an archive dump.
Special attention was paid to preserving page URLs: 96% of product pages and categories kept their previous form, and the rest were covered by permanent redirects according to the mapping table — search engine crawling did not hit dead ends, and accumulated external links continued to lead to the same products.
Metrics before and after
Catalog response under peak load dropped from seconds to fractions of a second: filtered results stopped "hanging" when paginating.
Updating the assortment from a supplier price list used to take hours of manual edits per batch — now it is a single import operation with discrepancy checking.
In the first day after switchover, the storefront handled peak traffic without cart or checkout failures, and no discrepancies between stock and accepted orders were recorded.
What to do if part of the data has already been transferred manually?
Starting the migration over when half the catalog has already been transferred in-house is more expensive than reconciling two databases.
First we establish the source of truth for each entity type: the catalog and content are maintained in the new system, while orders and customer history remain in the old one until switchover.
We search for duplicates not by internal identifiers — in Magento 1 and Magento 2 they are not linked to each other — but by natural keys: SKU, URL key, supplier association.
From them, a mapping of "old identifier — new identifier" is built, and it becomes the working map for all subsequent data loading.
The situation is more difficult with product and category relations.
During manual transfer, an item gets into the catalog but loses its association with attribute sets, reference values, and images: the product exists in the database, but it is absent in filters and on the storefront. We restore these relations using the mapping table, not by refilling them manually again.
Orders from the transition period are a separate risk. They cannot be appended as a list: continuous numbering, status history, and the link to customer accounts would break.
Therefore a snapshot is taken at the moment of switchover and transferred incrementally, with deduplication by order number and creation date.
Data loading is made idempotent: a repeated run does not create copies or double stock. We verify the result by reconciliation — the number of items, the share of products without a category, and orders left without a customer association. Discrepancies in a partial transfer are visible before launch, not after.
Compatibility of extensions, integrations, and page URLs
Before starting, the customer usually fears not for the data but for three things: extensions that do not work on the new platform branch, integrations with the warehouse and payments, and page URLs accumulated from search traffic.
The order of work here is the reverse of the usual one: first module inventory and a URL map, then content transfer — otherwise the catalog and sections will have to be redone twice.
We carry out the transfer from Magento 1 to the current branch of version 2 by functionality, not by module names: for each extension, we record what task it covers, what share of scenarios is actually used, and whether there is a ready replacement.
The rest is covered by custom development through the standard extension mechanism or a separate module, so that platform updates do not break the logic.
An extension has no equivalent for the new branch — what then?
We look at what part of the functionality is needed in practice: often only one or two scenarios out of ten are used from a module, and they are covered by custom development through the standard interception mechanism without modifying the core.
If the logic is deeper, we write our own module with test coverage — it moves along with the platform and does not block updates.
How do integrations with the warehouse and payments survive the transfer?
We move the exchange into a separate layer: the platform accesses it through standard interfaces, and external systems through the exchange API.
We synchronize orders and stock with protection against reprocessing, a log, and retries, so that a failure on one side does not cause double charges. Before traffic switchover, we run both sides in a test environment on a data copy.
Will page URLs and section structure be preserved?
We take a URL map of the old site, match it one-to-one with the new structure, and serve it via permanent redirects — without chains of multiple hops. Categories, filters, pagination, and the sitemap get separate rules.
After switchover, we check the export from the webmaster panel: the search engine should see the new URLs, not errors.
Let's discuss the task: where a store transfer begins
Discussion of the task begins not with an estimate but with an inventory: how many products, attributes, and variants the store has, which extensions and core modifications support the sales logic, and how integrations are structured.
Without these inputs, estimating the scope of work turns into guesswork, and the transfer plan breaks on the first non-standard module — so we discuss transferring from Magento 1 to the current branch in terms of facts.
What to prepare for the discussion:
- a catalog export: the number of products, categories, attributes, and variants;
- a list of extensions, themes, and core modifications — with a note on what is critical for sales;
- integrations: warehouse, accounting system, delivery services, payment gateways, newsletters;
- the URL structure and rules for forming URLs — the basis for the redirect map;
- a report on traffic and search entry points for the last year;
- access to servers, repositories, and panels, and constraints on the transfer window;
- processes that cannot be stopped: orders, price list exports, stock.
At the end of the first stage, you receive a transfer plan broken down by work, a data and URL map, a list of risks, and the verification order.
If some data is unavailable, indicate this at the start — we will clarify the set of inputs and come back with an estimate of the scope of work. Then we will agree on timelines and team composition and begin with a trial transfer to the test environment.
