Migrating from Magento 1 to Magento 2: Data Migration and Pitfalls

1. Why migration is still a real project in 2026

Magento 1 reached official end of life in June 2020; since then there have been no more security patches from the vendor. Yet in 2026 shops still run on this platform, usually because a Magento 1 to Magento 2 migration was judged too expensive or too risky for day-to-day business. The risk today, however, is significantly greater than it was a few years ago: known, publicly documented security vulnerabilities will never be closed, PCI DSS compliance for payment processing is barely demonstrable on an unsupported platform, and the number of available developers with current Magento 1 knowledge keeps shrinking.

This article covers a practical Magento migration from an existing Magento 1 shop to Magento 2.4.8, focused on the technical pitfalls that repeatedly cause delays in migration projects: the Data Migration Tool and its limits, EAV mapping problems with custom product attributes, the mandatory theme rebuild instead of a 1:1 transfer, URL structure and SEO redirects, and the technically non-trivial conversion of existing customer accounts' password hashes.

Important up front: a Magento 1 to Magento 2 migration is not a pure database-copy project, but in large parts a rebuild. Anyone who plans for that from the start, instead of expecting a quick, superficial transfer, avoids the biggest disappointments over the course of the project.

2. Choosing a migration strategy: big bang vs. incremental

A big bang cutover migrates the entire shop on a fixed date: data gets synchronized one final time, the old shop is switched off, the new one goes live. This approach suits smaller to mid-sized shops with manageable order volume, where a maintenance window of a few hours is acceptable. The advantage lies in simplicity: there's no parallel operation, no synchronization logic between two systems, and the project has a clear conclusion.

For shops with high daily order volume or multiple connected third-party systems such as ERP or PIM, an incremental migration with temporary parallel operation is often the more realistic choice. Here both systems run side by side for a limited period, while individual functional areas, for instance first just the product catalog, then later checkout and customer accounts, get switched to Magento 2 one after another. This strategy significantly increases project complexity but reduces the risk of a complete shop outage during the critical transition phase. The decision between the two approaches should be made early in the project, since it influences the entire technical preparation of the Magento migration.

3. Data Migration Tool: fundamentals and mapping.xml

Adobe provides an official Data Migration Tool for the Magento 1 migration, which runs as a separate Composer package alongside the Magento 2 installation and works in several phases: first the settings migration (configuration values), then the data migration (master data such as products, categories, customers), and finally the delta migration, which continuously pulls new changes from Magento 1 during ongoing parallel operation, up to the final cutover.

Central to the tool's correct operation are the mapping.xml files shipped for each Magento edition and version, which define which Magento 1 tables and columns map to which Magento 2 entities. For custom modifications in the original Magento 1 shop, for example additional columns in core tables or renamed attributes, the shipped mapping.xml isn't sufficient and has to be extended with custom mapping rules before the data migration phase starts.

# Install the Data Migration Tool matching your Magento 2 edition and version
bin/composer require magento/data-migration-tool:2.4.8

# Phase 1: migrate configuration settings first
bin/magento migrate:settings --reset vendor/magento/data-migration-tool/etc/opensource-to-opensource/2.4.8/config.xml

# Phase 2: migrate master data (products, categories, customers, orders)
bin/magento migrate:data --reset vendor/magento/data-migration-tool/etc/opensource-to-opensource/2.4.8/config.xml

# Phase 3: run repeatedly during parallel operation to pull incremental changes
bin/magento migrate:delta vendor/magento/data-migration-tool/etc/opensource-to-opensource/2.4.8/config.xml

4. Custom attributes and EAV mapping pitfalls

Custom product attributes are the area where a Magento 1 to Magento 2 migration most often stalls. Magento 1 and Magento 2 both use an EAV model (Entity-Attribute-Value), but the internal structure of attribute sets, attribute groups, and attribute types differs in details that aren't always correctly resolved by an automated migration. A common problem: an attribute created as a text field in Magento 1 that should really be a dropdown gets carried over 1:1, instead of being cleanly remodeled in Magento 2 as a select attribute with defined options.

A second, subtler problem is duplicate attribute_code collisions: Magento 2 reserves certain attribute codes for internal purposes that may have been used for custom, project-specific attributes in Magento 1. In such cases the migration tool either aborts with an error or silently overwrites the wrong values if the mapping wasn't explicitly cleaned up beforehand. The recommended path is a complete attribute inventory of the Magento 1 shop before migration begins, with a deliberate decision per attribute: carry it over 1:1, rename it, or recreate it as an entirely new Magento 2 attribute with a clean attribute set.

<!-- Custom mapping.xml override for an attribute renamed to avoid a Magento 2 core collision -->
<?xml version="1.0" encoding="UTF-8"?>
<config>
    <step title="Custom Attribute Mapping">
        <map>
            <field_rules>
                <ignore>
                    <!-- Attribute code collided with a Magento 2 reserved name -->
                    <field name="status"/>
                </ignore>
                <rename>
                    <!-- Renamed to avoid the collision, remapped explicitly here -->
                    <field name="status" to="legacy_order_status"/>
                </rename>
            </field_rules>
        </map>
    </step>
</config>

5. Theme and extensions: why a rebuild is necessary

Magento 1 templates are built on phtml files with direct Zend_Db access, blocks following the old EAV model pattern, and a completely different layout XML dialect. This structure is technically incompatible with the Magento 2 module system, service contracts, and the Hyvä theme approach with Tailwind CSS and Alpine.js; an automated conversion of Magento 1 templates to Magento 2 doesn't exist, and even if it did would produce fragile, barely maintainable code. The only sensible path is a deliberate theme rebuild that uses the old shop's design as a visual reference but is built technically from scratch on the Magento 2 block structure and, if desired, Hyvä.

The same principle applies to extensions: a Magento 1 extension, for instance a custom shipping module or a payment integration, can't simply be copied, because module registration, dependency injection, and service contract patterns have fundamentally changed. For every Magento 1 extension it must be checked whether an official Magento 2 version already exists from the vendor, whether a functionally comparable Magento 2 alternative exists on the market, or whether the logic has to be rebuilt as an entirely new Magento 2 module with modern PHP 8.4 and service contracts.

6. URL structure and SEO redirects

Magento 1 and Magento 2 differ in their URL key conventions, often just through different default suffixes and category path structures alone. Without careful planning, the migrated shop loses a significant portion of its organically built search engine rankings, because search engines suddenly find the old, indexed URLs returning 404. The central building block for avoiding this risk is a complete 301 redirect table that explicitly maps every old Magento 1 URL to the new Magento 2 route, not just a blanket redirect to the homepage.

In addition to plain URL forwarding, canonical tags have to be set anew and the XML sitemap has to be completely rebuilt, since the old sitemap structure was based on Magento 1 URLs that no longer exist. An often underestimated effort is building the redirect mapping table itself: for a catalog with several thousand products and categories, manual maintenance isn't sufficient; an automated script that programmatically compares the old and new URL structure and generates the redirect rules before they land in Magento 2's final url_rewrite table is recommended.

7. Customer data and password hashes

Magento 1 stores customer passwords with an MD5-based hashing scheme, while Magento 2 relies on bcrypt-based hashing via \Magento\Framework\Encryption\Encryptor, a fundamental and, from a security perspective, very welcome difference. The Data Migration Tool initially carries over the old MD5 hashes unchanged into the new database, but internally flags them as a legacy format. On a migrated customer's first successful login, Magento 2 automatically recognizes the old hash format, validates the entered password once more against the MD5 hash, and on success transparently stores a new bcrypt hash, without the customer noticing anything or having to re-enter their password.

Important for project planning: customers who never log in again after the migration permanently retain an MD5 hash, which represents a residual risk from today's security standpoint. For particularly security-critical projects, a one-time, communicated password reset campaign is additionally recommended for all migrated accounts that haven't logged in within a certain period, for example six months after the cutover, to systematically eliminate remaining MD5 hashes.

declare(strict_types=1);

namespace Vendor\MigrationTools\Model;

use Magento\Customer\Api\Data\CustomerInterface;
use Psr\Log\LoggerInterface;

/**
 * Reports customers whose password hash is still in the legacy MD5-based
 * format after a Magento 1 to Magento 2 migration, so they can be targeted
 * for a proactive password reset campaign.
 */
final class LegacyHashReporter
{
    private const string LEGACY_HASH_PREFIX_LENGTH = 32; // MD5 hex digest length

    /**
     * @param LoggerInterface $logger Logs identified legacy accounts for the reset campaign
     */
    public function __construct(
        private readonly LoggerInterface $logger,
    ) {
    }

    /**
     * Flags whether a stored password hash still looks like a legacy MD5-based hash.
     *
     * @param string $passwordHash Raw password_hash value from customer_entity
     * @return bool True if the hash format still matches the legacy Magento 1 pattern
     */
    public function isLegacyHash(string $passwordHash): bool
    {
        // Magento 2 bcrypt hashes contain a version prefix and a salt separated by ':'.
        // A legacy migrated hash typically has no such separator structure.
        return !str_contains($passwordHash, ':') && strlen($passwordHash) === self::LEGACY_HASH_PREFIX_LENGTH;
    }
}

8. Testing and the go-live cutover plan

Before any final cutover, at least two to three complete dry-run migrations should be performed against a copy of the production database, to realistically assess runtime, error rate, and data consistency. After every dry run, a data reconciliation checklist belongs to the fixed process: does the number of migrated orders exactly match the source database, does the customer count match, does the product count match including all variants for configurable products, and were all attribute values correctly carried over.

#!/usr/bin/env bash
# Quick row-count reconciliation after a Data Migration Tool dry run.
# Run against both the Magento 1 source and the fresh Magento 2 target
# database to catch obvious data loss before scheduling the final cutover.
set -euo pipefail

SOURCE_DB="magento1_prod_copy"
TARGET_DB="magento2_migration"

echo "Orders:"
bin/mysql -e "SELECT COUNT(*) FROM ${SOURCE_DB}.sales_flat_order" -N
bin/mysql -e "SELECT COUNT(*) FROM ${TARGET_DB}.sales_order" -N

echo "Customers:"
bin/mysql -e "SELECT COUNT(*) FROM ${SOURCE_DB}.customer_entity" -N
bin/mysql -e "SELECT COUNT(*) FROM ${TARGET_DB}.customer_entity" -N

echo "Products (including all configurable variants):"
bin/mysql -e "SELECT COUNT(*) FROM ${SOURCE_DB}.catalog_product_entity" -N
bin/mysql -e "SELECT COUNT(*) FROM ${TARGET_DB}.catalog_product_entity" -N

The actual cutover day should have a fixed, communicated maintenance window with a realistic time buffer, usually outside of core business hours. A documented rollback plan for the case that the final delta migration produces unexpected errors is mandatory preparation: if in doubt, the old Magento 1 shop must be quickly reactivatable until the problem is fixed and a new cutover date is scheduled. A cutover without a tested rollback plan is one of the biggest avoidable risks of a Magento migration.

9. Comparison: typical mistakes vs. correct approach

The overview below summarizes the most common mistakes in a Magento 1 to Magento 2 migration and contrasts them with the established, correct approach.

The common denominator of all avoidable mistakes: a Magento 1 to Magento 2 migration rarely fails because of the Data Migration Tool itself, but because of insufficient preparation and missing tests in the areas the tool doesn't automatically cover.

The project also isn't finished the moment cutover succeeds. During the first two to four weeks after go-live, close monitoring should watch for abandoned checkouts, unusual 404 rates from search engine crawlers, and support requests about missing customer accounts. This phase reliably surfaces exactly the bugs that stay hidden in dry runs against synthetic test data, such as rare combinations of legacy discount codes with new tax rules, or isolated products carrying inconsistent EAV values left over from years of organically grown legacy data. A dedicated window for this post-launch observation period, including a reachable development team, belongs in the migration plan just as much as the cutover date itself.

10. Summary

A successful Magento 1 to Magento 2 migration to Magento 2.4.8 requires far more than installing and running the official Data Migration Tool. The choice between big bang and incremental migration determines the entire project structure. Custom attributes require a complete inventory before the data migration phase to avoid EAV mapping collisions. Theme and extensions have to be deliberately rebuilt; an automated 1:1 conversion doesn't exist and wouldn't be desirable anyway.

URL redirects and a newly built sitemap concept protect existing SEO rankings, while the transparent password hash conversion from MD5 to bcrypt kicks in automatically on first login, but should be proactively tracked for inactive accounts. Multiple tested dry-run migrations with a complete data reconciliation and a documented rollback plan reduce the risk of the final cutover to a calculable level, instead of treating a Magento migration as a one-time, irreversible leap into the unknown.

11. FAQ: Migrating from Magento 1 to Magento 2