How to migrate from Magento: a practical, step-by-step guide

The CIQRA team30 September 2026 8 min read

To migrate from Magento, export your catalog and customers with Magento's built-in Data Transfer tool, pull orders and content through its REST and GraphQL APIs, map every old URL (including Magento's URL rewrites) to its new address with a single 301 redirect, and rehearse the whole move on a password-protected copy before you switch your domain. The steps below apply to both Magento Open Source and Adobe Commerce, and each export method links to Adobe's own documentation.

This guide is about the data and the mechanics. For the search side of the move in full detail, pair it with our e-commerce replatforming SEO checklist.

Why stores re-platform off Magento

For most merchants the trigger is the upgrade calendar, not a single feature. According to Adobe's Adobe Commerce lifecycle policy (last updated September 18, 2026), each version gets a three-year standard support window from its general availability (GA) date, and Adobe offers one extra year of extended support at no additional cost for versions 2.4.6 and 2.4.7. The published dates are:

ReleaseGeneral availabilityEnd of standard supportEnd of extended support
2.4.5August 9, 2022August 12, 2025August 11, 2026
2.4.6March 14, 2023August 11, 2026August 31, 2027
2.4.7April 9, 2024May 31, 2027May 31, 2028
2.4.8April 8, 2025May 31, 2028To be announced
2.4.9May 12, 2026May 31, 2029To be announced

The same page notes that Adobe does not provide fixes for third-party dependencies such as PHP, MariaDB or OpenSearch, and that PHP 8.2 reaches end of life on December 31, 2026, which Adobe flags as a PCI compliance risk for 2.4.6 stores running on it. The policy is written for Adobe Commerce; if you run Magento Open Source, check the release notes for your version.

So every Magento store faces a recurring choice: upgrade in place to a supported release, or move to another platform. Both are legitimate. If you are weighing the second option, our guides to choosing an e-commerce platform and on-premise versus SaaS cover the decision itself. The rest of this post assumes you have decided to move.

Step 1: Inventory before you export

Write down what exists before you touch an export button:

  • Websites, stores and store views, and which languages each one serves.
  • Attribute sets and the attributes each product type uses, especially the ones that drive configurable options (size, color and so on).
  • Extensions that add their own data, such as reviews, loyalty points or custom fields. These are usually not in the standard exports.
  • How much order history you actually need on the new platform, and for how long.

Step 2: Export products and attributes

In the Admin, go to System > Data Transfer > Export. Adobe's export documentation lists these entity types: Advanced Pricing, Products, Customer Finances, Customers Main File, Customer Addresses and Stock Sources. The default format is CSV, and the export runs in the background.

The product file has one row per SKU. Adobe's product data attributes reference describes the columns you will map most often:

  • sku: required, up to 64 characters; longer values make an import fail.
  • store_view_code: the store view a row applies to; blank means the default store view. Store-view rows are where translated values live.
  • attribute_set_code and product_type (simple, grouped, configurable and others).
  • url_key, meta_title and the other SEO fields.
  • additional_attributes: your custom attributes, packed into one cell as comma-separated code=value pairs. Split this column into separate fields before importing elsewhere.

Configurable products

Configurable products need the most care. As Adobe's configurable product guide explains, each simple variation is exported as its own row, and the parent row carries a configurable_variations column that links them: each variation is written as sku=…,color=…,size=…, variations are separated by a pipe (|), and values use attribute codes rather than labels. A second column, configurable_variation_labels, holds the option labels.

On most other platforms the parent becomes one product and the children become its variants. Create the option attributes on the target first, then check that every child SKU in the pipe-separated list exists in your file, and that no child is also left behind as a stand-alone product unless you want it sold separately.

Step 3: Export customers, and decide about passwords

Export Customers Main File and Customer Addresses separately. Adobe's customer data attributes reference lists what the main file contains, including email, website, created_at, group_id and password_hash.

That last column is the key point: you get a hash, not a password. Adobe's encryption key documentation states that SHA-256 is used to hash all data that does not require decryption, so no one can recover the original passwords from the export. You have two options:

  1. Carry the hashes over, if the new platform can verify Magento's hash format at a customer's first login and then re-hash it in its own format.
  2. Ask customers to set a new password after launch, with a clear message that explains why. Send it from the live store only, never from a test environment.

Step 4: Export orders through the REST API

Orders are not among the Admin export entity types, so use the API. Adobe's REST search documentation shows the endpoint GET /rest/<store_code>/V1/orders with an administrator token and searchCriteria filters. Always set searchCriteria[pageSize] and step through searchCriteria[currentPage]: the same page notes that if pageSize is not specified, the system returns all matches, which is heavy on a large store.

Decide early whether old orders must live in the new admin (for returns and customer order history) or whether an exported archive is enough for accounting and support.

Step 5: Export CMS pages and URL rewrites

For content pages, the GraphQL cmsPage query returns a page by its identifier, with fields such as url_key, title, content, meta_title and meta_description. Check the content for Magento widgets and variables, which another platform will not render.

URL rewrites deserve their own export. They are listed in the Admin under Marketing > SEO & Search > URL Rewrites, where Adobe's URL rewrite documentation shows each request path, target path and redirect type: Temporary (302) or Permanent (301). Two details catch migrations out:

  • A product can answer at several addresses. In the example in Adobe's route query documentation, one product is reachable at new-joust-duffle-bag.html, gear/new-joust-duffle-bag.html and gear/bags/new-joust-duffle-bag.html.
  • Old redirects already exist. When a url_key changes and save_rewrites_history is set to 1, Magento creates a 301 from the old URL to the new one, so your store may already hold chains of past addresses.

Step 6: Build the redirect map

Google's site-move guidance (last updated August 2026) asks you to map old URLs to new ones, redirect server-side with 301s, and avoid chained redirects. Every old address, including category-path variants and old rewrite targets, should go straight to its final new URL in one hop:

Old Magento URLNew URL
/gear/bags/joust-duffle-bag.html/products/joust-duffle-bag
/gear/joust-duffle-bag.html/products/joust-duffle-bag
/old-duffle-name.html (existing 301)/products/joust-duffle-bag
/about-us/pages/about-us

Google recommends keeping redirects for as long as possible, generally at least one year.

Step 7: Test on a staging copy

  • Counts match: products, variants, customers, addresses, orders and pages.
  • Spot-check prices, options, stock, images and translated store-view values on a sample of SKUs.
  • Request every old URL in your map and confirm one 301 hop to a page that returns 200.
  • Place test orders end to end: tax, shipping, payment in test mode, confirmation emails.
  • Log in with a migrated customer account, or run the password-reset flow.
  • Confirm the staging copy cannot email real customers.

Step 8: Cut over

  1. Freeze catalog edits on Magento.
  2. Run a final delta export of orders and customers created since your main export; Adobe's REST search examples filter on created_at with conditions such as gt (greater than).
  3. Switch the domain, enable the redirect map and submit the new XML sitemap.
  4. Watch 404s and Search Console daily for the first weeks and add missing redirects as they appear.
  5. Keep the old Magento database available read-only until your order history and accounting are confirmed.

Moving to CIQRA

If you move to CIQRA, the migration follows the same shape: products, categories, content and media move over in every language. Your new store is built behind a password while the current one keeps selling until launch, and the preview environment never sends notifications to real inboxes. Product and category URLs are kept or 301-redirected, and titles and descriptions carry over unchanged; the redirect manager lets you bulk-import old URLs and catch broken links from the 404 log. Once you give the go-ahead, we point your domain to the new platform.

FAQ

Can I keep my customers' Magento passwords?

Only as hashes. The export contains password_hash, not readable passwords, so either the new platform verifies those hashes at first login or customers set a new password.

Can I export orders from the Magento Admin?

Not through System > Data Transfer > Export, which covers products, pricing, customers, addresses and stock sources. Use the REST orders endpoint with paged search criteria.

How long should I keep the redirects?

Google's guidance is as long as possible, generally at least one year.

Should I upgrade Magento instead?

If your team is comfortable with the upgrade cycle and your extensions support the target release, upgrading is a valid choice. Check your version's end-of-support date in Adobe's lifecycle policy either way.

Sources

Share LinkedIn X Facebook Email

Written by
The CIQRA team

Related articles