Official support for Magento 1 ended in June 2020, yet a surprising number of stores still depend on it. Usually this is not neglect. The site may contain a decade of bespoke code and connect to an ERP, PIM, couriers and payment providers, making every change feel risky. A well-planned Magento 1 to Magento 2 migration is not technology for technology’s sake. It should reduce operational risk, improve the buying experience and give the business a supportable route to growth.
Magento 2 is not an in-place upgrade. Themes, extensions and customisations do not transfer automatically. Adobe’s own migration guidance treats data, extensions, custom code, themes and customisations as separate workstreams. The project therefore calls for commercial as well as technical decisions: what to retain, what to rebuild and what can finally be retired.
Why a Magento 1 migration should not wait
An old store may still accept orders, but its real cost is often hidden in emergency fixes, obsolete dependencies, scarce expertise and slow releases. Adobe documentation confirms that support and security fixes for Magento 1 ended in 2020. Running an unsupported checkout also makes security assurance and conversations with payment providers harder, even if third-party patches are available.
Customers experience the result as slow pages, poor mobile behaviour, a confusing basket or checkout failures. Magento 2 provides a stronger current foundation, but changing platform alone does not guarantee improvement. It is entirely possible to carry the old tangle of extensions, unclear pricing rules and ownerless integrations into a newer codebase. That is why I start with an audit rather than a database copy.
Audit first, estimate second
Count products, customers and orders, but also map the processes that make the business distinctive: contract pricing, credit limits, multiple warehouses, repeat orders, product configuration, promotions, returns and data flows with the ERP. If the store serves trade customers, use the requirements for a Magento 2 B2B platform to test account structures, permissions and pricing rules. Review four areas overall: data, capabilities, integrations and commercial goals.
Question the assumption that everything must move. Recent account and order history may be valuable; obsolete attributes, expired promotions, duplicate customers and dormant accounts may not be. Personal data also makes migration a UK GDPR decision: retain what is necessary and documented, rather than copying records indefinitely simply because they exist.
What migrates and what is rebuilt?
Adobe’s Data Migration Tool transfers and validates Magento 1 settings and data in three modes: settings, bulk data and delta changes. It uses mapping files to reconcile schema differences and performs integrity and volume checks. That makes it useful, but it does not convert a Magento 1 theme or rewrite bespoke extensions.
Audit catalogue records, customers, addresses, orders, invoices, coupons and price rules before they enter the new system. Decide whether each Magento 1 extension is replaced by native capability, a maintained Magento 2 module, a service owned by the ERP/PIM, or a small bespoke component. Rebuilding a feature simply because it exists preserves cost without proving value.
The frontend is a new build. Magento 2 with Hyvä can deliver a leaner storefront, but every checkout, search, payment and third-party feature needs compatibility assessment. Hyvä’s documentation states that Luma-oriented extensions may require compatibility modules. Choose it for measurable benefits to users and maintainability, not simply because it is fashionable.
Integrations are usually the highest risk
Long-running Magento 1 integrations often lack current documentation; important exceptions live in people’s heads. Name an owner and system of record for every domain. What owns stock? Which price wins? What happens when a trade customer exceeds credit? Can an order message be replayed without creating a duplicate?
Design queues, monitoring, actionable logs and reconciliation from the beginning. Adobe Commerce supports REST APIs and message queues, but reliability comes from the surrounding contract: unique identifiers, retries, alerting, dead-letter handling and operational ownership.
A practical migration example
Suppose a parts distributor receives 300 orders during the final migration window. The bulk migration has already moved historic data. A delta run captures new Magento 1 customers and orders shortly before cutover, while a separate reconciliation compares order numbers, grand totals, tax and customer identifiers between both platforms. The team blocks checkout only for the short final window, validates the last order on Magento 1 and the first on Magento 2, then confirms both have reached the ERP. If the totals do not reconcile, the go-live decision pauses rather than leaving finance to untangle the difference later.
SEO and continuity need their own plan
Crawl the current site and inventory URLs that receive traffic, links or revenue. Create one-to-one 301 redirects where addresses change, retain valuable category and guide content, and verify canonical tags, robots directives, XML sitemaps and structured data. Never allow staging to replace production in the index.
After launch, monitor crawl errors, key landing pages, organic revenue, checkout errors and performance. A cleaner URL structure may be worthwhile, but it must be intentional and mapped rather than an accidental side effect of a new catalogue.
A safe Magento 2 launch
Build and test on a production-like environment. Ask the business to complete real scenarios: guest purchase, B2B sign-in, agreed pricing, ERP transfer, return, credit note and status update. Run repeated trial migrations until their duration and exceptions are understood.
The launch checklist should include UK VAT and GBP rounding, payment capture and refunds, delivery services, transactional email, cookie and analytics behaviour, data-protection notices, redirects, monitoring, backups and admin access. Consumer-facing stores should also confirm that total prices, delivery information and cancellation rights are clear; GOV.UK’s distance-selling guidance provides a practical baseline.
Plan the final import close to cutover and choose an approach for orders placed during the window. The team must know who makes the go/no-go decision, who validates payment and ERP posting, and who communicates with customers. The first few days after launch should be closely monitored; they are not the end of the project.
Budget follows complexity, not product count
A catalogue of 50,000 clean simple products may be easier than 5,000 products with several customer types, individual prices and a dozen integrations. Data quality, bespoke processes, frontend scope, B2B requirements, integration reliability and SEO preservation are the main cost drivers.
A fixed price can offer budget certainty only once the scope, assumptions and acceptance criteria are understood. Treat migration as an opportunity to simplify the sales platform rather than reproduce every technical decision made over the previous decade.
If Magento 1 still handles a meaningful share of revenue, the first step is not choosing a theme or extension. It is producing an honest map of processes, data, dependencies and risk. That map becomes the basis for a Magento 2 store the business can support and improve for years. Our Magento 1 to Magento 2 migration service explains how we approach that work.
