Adobe Commerce development
Storefront design
Performance & SEO
AI & agentic commerce
Release tracker
A Magento 1 to Magento 2 migration is really four projects: moving data with Adobe's Data Migration Tool, rebuilding the theme, replacing extensions and custom code, and protecting SEO with redirects. Only the first is automated. Data such as products, customers, orders and settings can move with the tool; themes and PHP code cannot and must be rebuilt for Magento 2.
Magento 1 reached end of life on June 30, 2020, so any store still on it has had years without official security patches. If you are reading this, the question is how, not whether.
Choose your target version first
Do not migrate to an old Magento 2 release. Adobe Commerce and Magento Open Source 2.4.9 became generally available on May 12, 2026 and has standard support until May 31, 2029. It requires PHP 8.5, MySQL 8.4 or MariaDB 12.3, OpenSearch 3 and Valkey 9 on-premises, so your hosting plan has to match.
One practical catch: the Data Migration Tool is released per Magento version, and its README says the tool and Magento 2 versions must be identical. At the time of writing (November 2026), the newest tag in Adobe's public data-migration-tool repository is 2.4.8.1. If no 2.4.9 release exists when you start, a common approach is to migrate data into a clean 2.4.8 instance and then upgrade to 2.4.9 as a separate, tested step. Check the repository before you plan.
How the Data Migration Tool works
The tool is a command-line module installed into Magento 2. It reads the Magento 1 database and writes to the Magento 2 database using map files that describe how tables and fields changed. It runs in three modes, in this order:
- Settings mode migrates system configuration and website settings.
- Data mode moves the bulk of database records.
- Delta mode moves changes made since the last run, such as new orders and customers, so you can keep Magento 1 trading until cutover.
# Placeholders: replace the edition folder and version with your own
bin/magento migrate:settings vendor/magento/data-migration-tool/etc/opensource-to-opensource/1.9.4.5/config.xml
bin/magento migrate:data vendor/magento/data-migration-tool/etc/opensource-to-opensource/1.9.4.5/config.xml
bin/magento migrate:delta vendor/magento/data-migration-tool/etc/opensource-to-opensource/1.9.4.5/config.xmlIf an extension added tables or columns that the map files do not declare, the tool stops with an error rather than guessing. That is helpful: every error is a decision about whether to map, ignore or rebuild that data.
Data-by-data migration map
This is the core of migration planning. For each type of data, decide which bucket it falls in before any code is written.
| Data or feature | How it moves | What to check or do |
|---|---|---|
| Store configuration, websites, store views | Tool (settings mode) | Review payment, shipping and tax settings by hand afterwards |
| Products, categories, attributes, attribute sets | Tool (data mode) | Reindex; check configurable and bundle products render correctly |
| Product images and media | Copy files manually | Copy media to pub/media (not the Magento 1 .htaccess files), then verify image paths on product pages |
| Customers and addresses | Tool | Test login with a migrated account; test new registration |
| Customer passwords | Tool (customer step maps the stored password hash) | Confirm migrated customers can log in on staging before launch |
| Orders, invoices, shipments, credit memos | Tool | Reconcile counts and totals by year |
| Cart price rules and catalog price rules | Tool | Re-test each active rule; conditions can behave differently |
| CMS pages and blocks | Tool moves content | Widgets and layout updates often need rework |
| URL rewrites | Tool (URL rewrite step) | Crawl old URLs and confirm they resolve or redirect |
| Reviews and ratings | Tool (ratings step and review tables) | Spot-check on product pages |
| Extension data in custom tables | Tool only if mapped; otherwise script | Decide per extension: map, export/import, or drop |
| Admin users, roles and API credentials | Re-create manually (not migrated) | Re-create admin accounts and roles against Magento 2 ACL resources and new web service credentials; enforce 2FA |
| Theme and templates | Rebuild | New Luma-based, Hyvä or Breeze theme |
| Extensions | Replace | Find Magento 2 versions or native features; Magento 1 modules do not run on Magento 2 |
| Custom modules | Rewrite | Port business logic to Magento 2 modules, plugins and observers |
| Integrations (ERP, PIM, feeds) | Rebuild | Use Magento 2 REST or GraphQL APIs and message queues |
Use the map as a checklist in your project tracker. Every row should end with an owner and a test.
A practical migration sequence
- Audit Magento 1. List every extension, custom module, integration, cron job and CMS widget. Remove what nobody uses. Fewer extensions means fewer map errors.
- Clean data. Delete test orders, spam customers, unused attributes and orphaned images. Back up first.
- Install Magento 2 on hosting that meets the target version's requirements, with no sample data.
- Install equivalent Magento 2 extensions before migrating data, so their tables exist.
- Run settings and data migration on a copy of the Magento 1 database. Fix map errors and repeat until clean.
- Build the theme and custom modules in parallel with data work.
- Rehearse. Run the full migration end to end at least twice, timing it and reconciling counts each time.
- Cut over. Freeze Magento 1 admin changes, run delta migration, switch DNS, enable redirects, reindex and flush caches.
- Monitor. Watch orders, errors and Search Console daily for the first weeks.
Choosing a frontend for Magento 2
Because the theme is rebuilt anyway, the migration is the cheapest moment to choose a modern frontend. The core Hyvä Theme became open source and free in November 2025, and Swissup's Breeze is a free alternative that stays closer to Luma. Our comparison of Hyvä, Breeze and Luma covers the trade-offs.
Protecting SEO through the migration
Magento 1 and Magento 2 can use the same URL keys, so many product and category URLs can stay identical if you keep URL suffixes and category paths consistent. Where URLs change, add permanent redirects, one old URL to its closest new equivalent. Then crawl the old site's URL list against staging. The full process is in our ecommerce SEO migration checklist, and the wider project steps are in our ecommerce replatforming guide.
What drives the effort
- Number of extensions and how many have Magento 2 equivalents.
- Amount of custom code and how tightly it is tied to Magento 1 internals.
- Integrations and whether they can move to Magento 2 APIs unchanged.
- Theme scope: rebuild the current design or redesign.
- Data volume and quality, which affects how long each rehearsal takes.
A reliable estimate needs the audit in step 1. Treat any fixed price offered before an audit with caution.
Frequently asked questions
Can I upgrade Magento 1 to Magento 2 in place?
No. Magento 2 is a different codebase with a different database structure. You install Magento 2 fresh and migrate data into it.
Will customers need to reset their passwords?
The tool's customer mapping carries over stored password hashes, so the aim is that customers log in as before. Test this with real migrated accounts on staging; if logins fail, plan a reset email before launch.
Should I move to another platform instead?
Possibly. Since you are rebuilding the theme and extensions anyway, compare options honestly. Our Magento vs Shopify comparison is a good starting point.
Next step
Mistri's Magento migration services start with the audit described above, then plan data, code and redirects together so cutover is a rehearsed routine rather than a leap.
Sources
How the Data Migration Tool works (Adobe Experience League); magento/data-migration-tool repository (GitHub); Adobe Commerce system requirements (Adobe Experience League); How to move a site with URL changes (Google Search Central); Migrate data manually: media, design, admin users and ACLs (Adobe Experience League).
