Magento migration: moving off (or onto) Adobe Commerce

"Magento migration" is used for two different projects. A version upgrade (Magento 1 to Magento 2, or an older Magento 2 release to a current one) keeps you on Magento; Adobe provides a Data Migration Tool for the Magento 1 to 2 path, and themes, extensions and custom code have to be redone for Magento 2. Replatforming moves the store to a different platform altogether. This page covers replatforming. If a version upgrade is what you need, a Magento development partner is the right choice; if you are weighing an upgrade against a move, the assessment can help you compare.

Stores leave Magento for predictable reasons: Magento 1 reached end of life in June 2020 and still runs in places; Magento 2 needs hosting, patching and specialized developers; Adobe Commerce licence and Cloud costs; and extension conflicts that make every upgrade a project. Stores move onto Adobe Commerce less often, typically for complex B2B requirements, many store views, or deep custom integrations a hosted platform will not support.

Magento is self-hosted (or runs on Adobe Commerce Cloud), so the data is accessible through the REST API, the admin export, or directly from a database copy. For established stores we work from the database, because that is where the full picture is: EAV attribute tables, attribute sets, configurable, bundle and grouped product relations, store-view-specific values, customer groups, tier prices, and the URL rewrites table.

The EAV model means a single product's data is spread across many tables by attribute type and scope. Values can differ per website and store view, so the export must decide which scope wins for the target. Extensions add their own tables for things like layered navigation, product labels, reviews, rewards, B2B quotes or blog content, and custom modules may hold business logic in PHP rather than data. Magento 1 and Magento 2 have different schemas, so the extraction differs by version, and we confirm the exact version and edition first.

When Adobe Commerce or Magento Open Source is the target, the structure has to be designed before import: attribute sets, attributes with their scope (global, website or store view), configurable products and their super attributes, the category tree, websites and store views, and customer groups. Data then goes in through the native import, the REST API, or scripted imports for large volumes and order history.

Moving onto Magento from a hosted platform, customers arrive without passwords and need a reset step, and apps from the old platform are replaced by extensions or custom modules. Hosting, caching, search configuration and a patching plan are part of the project scope, because Magento does not provide them the way a SaaS platform does.

Moving off Magento, the catalog is the main work. Configurable products become variant products on the target, which on Shopify means at most three option dimensions per product. Bundle and grouped products need an equivalent on the target (native bundles, an app, or separate products), and custom options that change the price become modifiers, line-item properties or an app. Hundreds of EAV attributes across attribute sets are reviewed: filterable ones become filterable attributes or metafields, the rest become custom fields or are dropped deliberately.

Store views and websites are mapped to the target's model: one store with markets and translations, several stores, or a mix. Customer groups and tier prices become price lists, customer tags or B2B features where the target supports them. CMS blocks and widgets, often with Magento directives in the content, are rebuilt as sections on the target.

A Magento store's behaviour is spread across marketplace extensions and custom modules: payment and shipping methods, ERP and warehouse connectors, B2B pricing, product configurators, search, feeds and checkout changes. We list each one and what it does for customers or staff, then choose a native feature, an app or extension, custom development, or a deliberate decision to drop it. Logic that lives in custom PHP code has to be understood before it can be replaced, so a code review is part of the audit for customized stores.

Magento themes (layout XML, templates, Luma- or Hyvä-based frontends) do not transfer, so the storefront is rebuilt on the target. Integrations are reconnected and tested with real orders on staging before launch.

Magento stores URLs in a URL rewrites table: product and category URL keys, optional .html suffixes, category paths in product URLs, store codes in URLs, and custom rewrites added over the years. Several URLs can point to the same product, and each store view can have its own. We export the rewrites, crawl the live site to see which URLs are actually indexed and linked, and build the redirect map from that evidence rather than from Magento defaults.

Every important URL gets a 301 destination on the target, including category paths, store-view variants, CMS pages and blog posts from extensions. Layered-navigation filter URLs are reviewed separately, because many should not be carried over at all. Titles, meta descriptions and canonical settings move with the content. After launch we crawl again and monitor Search Console. We check redirects and coverage; we do not promise rankings.

Customer passwords depend on the target. Hosted platforms cannot import Magento password hashes, so customers reset their passwords; self-hosted targets are assessed case by case. Stored cards and payment tokens depend on the gateway and never move silently. Adobe Commerce B2B features (company accounts, shared catalogs, quotes, requisition lists) have no direct equivalent on many platforms and need a scoped replacement.

Magento 1 stores often run on old PHP versions and servers, so getting a clean database copy can itself be a task. Multi-website setups with different catalogs, prices and languages may need several target stores, and orders spanning many store views need consistent mapping.

A named lead owns the project. We confirm the Magento version and edition, audit the database, attribute sets, store views, extensions, custom modules, integrations and indexed URLs, and write a mapping you approve. The trial migration runs into the target's staging store, and you check it record by record. After sign-off we plan launch: content freeze, final migration, a delta migration of new orders and customers, redirects, DNS and payment tests.

Scripts and automated comparisons check counts, prices, stock and URLs, and a person approves every production decision. After launch we review orders, emails, feeds and redirects, and fix what the first days of traffic uncover.