How to Upgrade from Magento 1 to Magento 2 (Adobe Commerce)

Magento 1 reached end of life on June 30, 2020. Since then it has received no security patches, no PCI-compliance updates, and no official support from Adobe. If you are still running Magento 1 (or Magento Open Source 1.9), every day online is a growing liability: unpatched vulnerabilities, payment gateways that are dropping support, and extensions that no longer receive updates. Moving to Magento 2, now branded Adobe Commerce and Magento Open Source 2.4.x, is not a simple version bump—it is effectively a re-platform to a rebuilt codebase.

The good news is that Magento 2 is a genuinely better commerce engine: faster page loads with built-in full-page caching and Varnish support, a modern PHP 8 codebase, native support for Elasticsearch/OpenSearch, a streamlined checkout, and a far more maintainable module architecture. The challenge is that almost nothing carries over automatically—your database schema, themes, and extensions all have to be migrated or rebuilt.

This guide walks through exactly what changes, what breaks, and how to run the migration without losing your catalog, your customers, or your hard-won search rankings.

Why businesses upgrade from Magento 1 to Magento 2

The move is usually driven by risk and performance rather than a desire for new features. The most common reasons store owners finally pull the trigger:

• Security and PCI compliance: Magento 1 no longer receives patches, so processing card data on it can jeopardize PCI-DSS compliance and expose you to breaches like the widespread “Magecart” card-skimming attacks that targeted unpatched M1 stores.
• Payment and extension abandonment: Gateways such as PayPal and Authorize.Net, plus most serious extension vendors, have ended Magento 1 support. New functionality simply isn't being built for it anymore.
• Performance: Magento 2 handles roughly 2x the page views per hour of M1 under load, with built-in Varnish full-page cache and asynchronous, message-queue order processing.
• Admin and checkout UX: A modernized, mobile-friendly admin and a shorter, streamlined guest checkout improve both staff productivity and conversion.

What changes and what breaks in the move

Because Magento 2 is a rebuilt platform, treat this as a rebuild rather than an update. Here is what does not transfer cleanly:

• Themes and design: Magento 1 themes are 100% incompatible. Magento 2 uses a new theme structure (Luma/Blank base themes, LESS, Knockout.js, RequireJS, and UI components). Your storefront design must be rebuilt on a Magento 2 theme.
• Extensions and custom modules: M1 extensions will not install on M2. You must buy the Magento 2 version of each extension, or have custom modules rewritten against the new module API.
• Custom code: Any bespoke functionality—pricing rules, integrations, custom checkout steps—has to be re-developed for the M2 architecture.
• Data: Products, categories, customers, and orders can be migrated with Adobe's official Data Migration Tool, but store configuration, media, and ACL settings need manual attention.
• URLs and SEO: Default URL structures and category paths can differ, which is why a deliberate redirect strategy is essential (covered below).

The step-by-step migration process

A disciplined, staged process keeps a Magento 2 migration predictable. We recommend building the new store on a separate server or staging environment while Magento 1 stays live and selling.

• 1. Audit and inventory. Catalog every extension, custom module, theme customization, and integration on Magento 1. Note which extensions have M2 equivalents, which need replacing, and which you can drop. Record your current catalog, customer, and order counts to verify against later.
• 2. Provision the Magento 2 environment. Stand up Magento Open Source 2.4.x or Adobe Commerce on a server that meets requirements: PHP 8.1/8.2, MySQL 8.0 or MariaDB 10.4+, Elasticsearch or OpenSearch, Composer, and Redis for caching/sessions.
• 3. Migrate data with the Data Migration Tool. Install Adobe's data-migration-tool (matched to your exact M2 version) and run its three modes in order—settings (stores, config), then data (products, categories, customers, orders), then delta (incremental changes that accrued while M1 kept selling).
• 4. Migrate media and rebuild extensions. Copy the media directory manually—images are not moved by the tool. Install the M2 versions of your extensions and re-implement custom modules.
• 5. Rebuild the theme. Recreate your storefront design on a Magento 2 theme, including PWA/headless if you're going that route.
• 6. Map and implement 301 redirects. Build a full old-URL → new-URL map (detailed below).
• 7. Test thoroughly. Verify catalog data, pricing, tax, shipping, payment gateways, checkout, customer logins, and admin workflows on staging.
• 8. Final delta and go-live. Run a last delta migration to capture recent orders, reindex, warm the cache, then cut over DNS.

Because so much has to be rebuilt rather than copied, many teams treat this as a fresh web development project with data migration bolted on. If you'd rather hand it off end to end, our website migration services cover the full audit-to-launch process.

Preserving SEO and rankings with 301 redirects

The single biggest way stores lose traffic during a re-platform is broken URLs. Magento 2 may generate different category paths, product URL keys, or suffix behavior than your Magento 1 store used, and any mismatch produces 404s that bleed rankings and link equity.

• Crawl your live Magento 1 site (Screaming Frog or similar) and export every indexed URL—products, categories, CMS pages, and filtered/landing pages.
• Map each old URL to its new Magento 2 equivalent with a permanent 301 redirect. Magento 2's URL Rewrites grid handles this natively, and you can bulk-import a redirect map. Our 301 redirect map guide shows how to structure the spreadsheet.
• Preserve on-page SEO: migrate meta titles, meta descriptions, and URL keys, which the Data Migration Tool carries in the url_rewrite data—but always verify.
• Regenerate the XML sitemap in Magento 2 and resubmit it in Google Search Console the day you launch.
• Keep canonical tags consistent and confirm Magento 2's layered-navigation/canonical settings match your old configuration to avoid duplicate-content issues.

Work through a full website migration SEO checklist before and after launch so nothing gets missed. Monitor Search Console coverage and crawl-error reports closely for the first 30–60 days.

Testing, DNS and launch

Never cut over on a Friday. On a staging URL, place real test orders through each live payment method, confirm tax and shipping calculations, test customer account login and password migration, and reindex all indexers. Load-test if you expect meaningful traffic. When everything passes, run the final delta migration to sync last-minute Magento 1 orders, put M1 into maintenance mode to stop new orders, point DNS at the Magento 2 server, and immediately smoke-test the live site—checkout first. Keep the Magento 1 server available (read-only) for a few weeks so you can reconcile any straggling orders.

Realistic timeline and cost

A Magento 1 to Magento 2 migration is a project, not an afternoon. A modest catalog with a handful of extensions and a lightly customized theme typically takes 6–12 weeks. Large catalogs, heavy customization, B2B features, or a full design refresh push that to 3–6 months.

• Data migration: largely automated but needs cleanup and validation—days to a couple of weeks depending on data volume and quality.
• Theme rebuild: often the largest single line item, since it's effectively a new front end.
• Extensions: budget for new M2 license purchases and the labor to configure or rewrite custom modules.

At our $80/hr rate, a straightforward migration commonly lands in the low-to-mid four figures, while complex commerce builds with custom integrations run higher. If your store relies on bespoke workflows or ERP/CRM connections, factor in custom development and CRM integration as part of the estimate. The cost of migrating is almost always lower than the cost of a breach or a failed PCI audit on an unsupported platform—which is why doing it deliberately, once, is the right investment.