Magento 1 to Magento 2 Migration: Data, SEO and Cutover Plan

Magento 1 reached end of life in June 2020, and there are still stores running on it, often patched by hand and stuck on old PHP versions. Moving them to Magento 2.4.8 is less about the tool that copies the data and more about planning: what to move, how to keep search rankings, and how to switch over without losing orders.

This is the plan I follow for a Magento 1 to Magento 2 migration. It is split into four tracks that run in parallel: data, code and theme, SEO, and cutover.

What migrates and what does not

Adobe's Data Migration Tool moves database content. That covers:

• Products, categories, attributes and attribute sets
• Customers, addresses and customer groups
• Orders, invoices, shipments and credit memos
• CMS pages and blocks, URL rewrites, most store configuration
• Cart price rules, catalog price rules and tax settings

It does not move:

• Extension code, themes or templates. These are rebuilt for Magento 2.
• Media files. You copy media/ from Magento 1 into pub/media/ yourself.
• Data from third party extension tables, unless you write map files for them.

Before touching the tool, make an inventory of every Magento 1 extension, what it stores in the database and whether the business still needs it. Many stores carry extensions nobody uses anymore. Each one you drop is one less map file and one less Magento 2 module to buy or build.

Track 1: data migration

Set up the tool

Install a clean Magento 2.4.8 with no sample data, then add the Data Migration Tool with the same version as Magento:

composer require magento/data-migration-tool:2.4.8
bin/magento setup:upgrade

Configuration lives under vendor/magento/data-migration-tool/etc/, in a folder for your edition pair, such as opensource-to-opensource/, with one subfolder per supported Magento 1 version. Pick the one that matches your source store. Copy config.xml.dist to config.xml and fill in the source and destination database details and the crypt_key from Magento 1 app/etc/local.xml. The key is needed to keep encrypted values such as payment configuration readable.

Do not edit files inside vendor/ directly. Copy the configuration and the map files you change into your own module and point the tool to them, so a Composer update does not wipe your work.

Run the three steps

bin/magento migrate:settings --reset path/to/config.xml
bin/magento migrate:data --reset path/to/config.xml
bin/magento migrate:delta path/to/config.xml

• Settings moves websites, stores and configuration.
• Data moves the bulk of the content. It runs integrity checks first and stops on any source field or document that has no destination and no rule in the map files.
• Delta copies changes made in Magento 1 after the data step, such as new orders and customers. The tool tracks those changes with triggers it adds to the Magento 1 database.

The integrity check failures are the real work. Each one means a table or column from an extension or a customisation that the tool does not know. For each, decide to map it to a Magento 2 table, ignore it in map.xml (under the source document_rules or field_rules), or migrate it with your own script after the tool runs.

<ignore>
    <document>aw_blog_post</document>
</ignore>
<ignore>
    <field>sales_flat_order.legacy_erp_flag</field>
</ignore>

The --auto option resolves some integrity errors automatically. I avoid it except for quick tests, because it hides decisions you want to make on purpose.

Clean the source first

Migration is the best moment to drop data you do not need. Old quotes, logs, report tables and abandoned carts can be huge in Magento 1 and slow every rehearsal. Clean them in a copy of the source database before migrating, not in production Magento 1.

After the data step

rsync -a old-server:/var/www/m1/media/catalog/ pub/media/catalog/
bin/magento indexer:reindex
bin/magento catalog:images:resize
bin/magento cache:flush

Then check the data with people who know the business. Count products, customers and orders on both sides. Open some complex products, a configurable with many children, a bundle, a product with custom options, and compare them with Magento 1. Log in as a migrated customer. Magento 2 accepts the old password hashes and upgrades them on login.

Track 2: code and theme

This track runs in parallel and usually takes the longest. For each Magento 1 extension that stays, decide between the vendor's Magento 2 version, another Magento 2 extension that covers the need, native Magento 2 functionality or custom development.

The theme is a rebuild in any case. Magento 1 templates cannot be ported. This is the moment to choose between Luma based and Hyvä, which I compare in a separate article.

Keep a list of every custom behaviour in Magento 1: rewrites in config.xml, observers, cron jobs, custom checkout steps, ERP exports. Each line becomes a ticket in Magento 2 or an explicit decision to drop it.

Track 3: SEO

Rankings are lost in migrations because URLs change without redirects, content disappears or the new site goes live with technical errors. The plan has three parts.

Build the URL inventory

Before anything changes, collect every URL that matters:

• A full crawl of the Magento 1 site with a crawler such as Screaming Frog.
• URLs with impressions or clicks from Google Search Console for the last 16 months.
• Landing pages with traffic from analytics.
• URLs with external backlinks, from whatever backlink tool you use.

Merge them into one list. This list is the test set for redirects.

Keep URLs where you can

The tool migrates URL keys and URL rewrites, so most product and category URLs can stay identical. To keep them identical, match the Magento 1 settings in Magento 2:

• Product and category URL suffix, usually .html, under Catalog, Search Engine Optimization.
• Whether product URLs include the category path.
• Store codes in URLs, if Magento 1 used them.

Every URL that keeps working with no redirect is one less thing to go wrong.

Redirect what changes

For URLs that change, such as CMS pages restructured, removed categories, a blog moved, or old search and filter URLs, create 301 redirects to the closest relevant page. Not to the home page. For a few hundred rules, custom URL rewrites in Magento work. For thousands, a map in the web server is faster and easier to maintain:

map $request_uri $m1_redirect {
    default "";
    /old-category/old-product.html /new-category/new-product.html;
    /blog/2019/some-post /blog/some-post;
}

server {
    if ($m1_redirect) {
        return 301 $m1_redirect;
    }
}

Then test the whole URL inventory against staging: every URL should return 200 directly or a single 301 to a 200 page. No chains, no 404s, no redirect to the home page. A short script with curl does this in minutes and should run after every rehearsal.

Technical checks before launch

• Canonical tags on products and categories set the way you want.
• Robots meta and robots.txt correct for production, not copied from staging.
• XML sitemap generated and reachable, ready to submit in Search Console.
• Titles, meta descriptions and category descriptions migrated, not left empty.
• Structured data for products present and valid.

Track 4: rehearsals and cutover

Rehearse the full migration

Run the complete migration at least twice on a fresh copy of the production Magento 1 database, timing each step. The first rehearsal finds problems. The second confirms the fixes and gives you a realistic duration. If the data step takes too long for the downtime the business accepts, the delta mode is what makes it work: run settings and data days before launch, then only delta during the cutover window.

One rule matters here. Between the data step and the final delta, do not change migrated entities in the Magento 2 admin. Delta writes Magento 1 changes into Magento 2 and can overwrite or conflict with edits made there. Configure new things, but leave migrated products, customers and orders alone until launch.

Cutover checklist

1. A few days before: lower the DNS TTL so the switch propagates quickly.
2. Freeze content changes in Magento 1. Only orders and customer registrations continue.
3. At the start of the window: put Magento 1 in maintenance mode so no new orders arrive.
4. Run the final migrate:delta, copy new media, reindex and flush caches.
5. Smoke test on the real domain from an internal network or hosts file: browse, search, log in, place orders with each payment method, check the order reaches the ERP or fulfilment.
6. Switch DNS or the load balancer. Keep Magento 1 available in read only mode for reference.
7. Run the URL inventory test against production. Submit the sitemap.

The first weeks

Watch Search Console coverage and 404 reports daily for the first weeks and add redirects for anything missed. Watch server error logs, payment success rates and order flow to the back office. Some movement in rankings right after launch is normal. What matters is that 404s are fixed quickly and nothing important was left without a redirect.

FAQ

Does the Data Migration Tool move themes and extensions?

No. It moves database content such as products, customers, orders, CMS content, URL rewrites and configuration. Themes and extension code have to be rebuilt or replaced with Magento 2 versions, and media files are copied separately.

Can customers keep their passwords after migrating from Magento 1?

Yes. Customer password hashes are migrated, and Magento 2 accepts the old hashes and upgrades them to the current algorithm the next time the customer logs in.

How do I avoid losing SEO rankings in a Magento migration?

Build an inventory of every URL with traffic or backlinks, keep URL keys and suffixes identical where possible, add 301 redirects for everything that changes and test the full list against staging before launch.

What is delta mode in the Data Migration Tool?

After the main data step, migrate:delta copies only the changes made in Magento 1 since then, such as new orders and customers. It lets you migrate most data days in advance and keep the cutover window short.

I am available for freelance Magento and Adobe Commerce work, from module development and performance audits to migrations and Hyvä builds. If that sounds useful, get in touch.