The data migration is the most underestimated part of any Magento 1 to Magento 2 project. Storefront rebuild, frontend theming, and extension porting all get the budget attention; the data migration gets treated as “we’ll just run the tool.” Then the project hits week 12, the tool fails on a customer table corruption from 2017, half the order history doesn’t carry over, and the launch slips by six weeks.
The decision between Adobe’s official Data Migration Tool and a custom ETL pipeline is the single largest variable in how predictable the data migration phase will be. Both options work for the right store; both options fail expensively for the wrong store. Bemeir’s Magento team has shipped data migrations using both approaches across stores ranging from $3M to $80M in annual GMV. Here is what determines which one is right.
What the Data Migration Tool actually does
Adobe’s Data Migration Tool is the official utility for migrating data from Magento 1 to Magento 2. It runs in three modes: settings (system configuration), data (catalog, customers, orders), and delta (changes since the initial migration, used during the cutover phase).
The tool is open source, well-documented in the Adobe Commerce migration documentation, and handles the standard schema differences between Magento 1 and Magento 2 out of the box. For a vanilla Magento 1 store with limited customization, it can migrate the entire database in hours and produce a working Magento 2 instance with all data intact.
The tool’s capabilities cover: system configuration (stores, store views, currencies, payment methods, shipping methods), catalog (products, categories, attributes, attribute sets, prices), customers (customer accounts, addresses, customer groups), orders (sales orders, invoices, credit memos, shipments), URL rewrites, EAV configuration, CMS pages and blocks, and most stock and inventory data.
What the tool does not handle: data from third-party extensions, customizations to standard Magento tables, custom EAV attributes added after database setup, customer log tables that don’t map cleanly between versions, and any business data stored outside the standard Magento schema.
For roughly 30-40% of Magento 1 stores we evaluate, the tool is sufficient. For the rest, the tool gets you 70-90% of the way and a custom ETL pipeline fills the gap.
What a custom ETL pipeline looks like
A custom ETL (Extract, Transform, Load) pipeline for Magento 1 to Magento 2 migration is a purpose-built data migration solution that handles the specific data shapes of the source store. Architecturally, it typically has three layers:
Extract. Reads data from the Magento 1 database, file system, or APIs. For most stores, this is direct database access through a read replica or a copy of the production database.
Transform. Applies the schema mappings between Magento 1 and Magento 2, handles data cleanup, resolves inconsistencies, and computes derived values. This is where the custom logic for the specific store’s data shape lives.
Load. Writes the transformed data into the Magento 2 database, either through direct database writes (faster, more risky) or through the Magento 2 API (slower, safer).
The pipeline is typically built in PHP, Node.js, or Python, depending on the team’s stack preference. It runs in batches to manage memory and database load, with logging and error handling at each stage. The total development time for a custom ETL pipeline on a complex store is typically 4-8 weeks, compared to 1-2 weeks of configuration for the Data Migration Tool.
When each approach is the right choice
The decision factors are mostly about the source data, not about the target Magento 2 store.
Data Migration Tool is the right choice when: the Magento 1 store has limited third-party extensions (under 15), the customizations to standard tables are minimal, the order history is under 100,000 orders, the customer base is under 250,000 customers, and the catalog is under 50,000 SKUs with standard attribute sets.
Custom ETL is the right choice when: the Magento 1 store has substantial third-party extensions (15+) that hold meaningful business data, the database has accumulated data quality issues over multiple years, the order history is over 250,000 orders (where the tool’s performance becomes problematic), the customer base is over 500,000 customers, or the catalog has heavy custom EAV usage that the tool does not map cleanly.
Hybrid approach (tool + custom supplements) is the right choice when: the standard data (catalog, customers, orders, configuration) can be handled by the tool, but specific third-party extension data needs custom migration scripts.
The hybrid approach is what we end up recommending most often for mid-market migrations. The tool handles the bulk of the work; custom scripts handle the specific data shapes the tool cannot.
Comparison: actual outcomes by approach
The pattern across the migrations our team has shipped:
| Outcome metric | Data Migration Tool | Hybrid (Tool + Custom) | Full Custom ETL |
|---|---|---|---|
| Development time | 1-2 weeks | 4-8 weeks | 8-16 weeks |
| Data quality at migration | Good for standard tables | High across the board | Very high |
| Third-party extension data | Not handled | Handled selectively | Handled completely |
| Delta migration support | Native | Hybrid (tool for standard) | Custom (must be built) |
| Total project cost (data migration portion) | $25K-$60K | $60K-$160K | $120K-$280K |
| Risk of post-launch data issues | Moderate to high (depending on source) | Low | Very low |
| Time to first usable Magento 2 instance | Days | Weeks | Weeks to months |
The cost difference is meaningful and worth being honest about. The cheapest path is not always the right path; a $25K data migration that leaves the new store with significant data quality issues is more expensive than an $80K migration that ships clean data.
The data quality reality
The most overlooked aspect of Magento 1 to Magento 2 migration is that Magento 1 stores have accumulated data quality issues that have been hidden by the source application. Common issues:
Orphaned product records. Products in catalog tables but not in catalog_product_entity, or vice versa. The source application handles these gracefully; the migration tool may not.
Inconsistent attribute data. Custom attributes that were added, used, deprecated, and re-added with different attribute IDs over time. The migration needs to resolve which version of the attribute is canonical.
Customer duplicates. The same customer registered multiple times with slightly different email addresses or capitalizations. The migration is the opportunity to resolve these, but only if it is designed to do so.
Order data inconsistencies. Orders with payment method or shipping method that no longer exists in configuration. The migration tool typically chokes on these; custom ETL can resolve them with explicit business logic.
URL rewrite explosion. Magento 1 stores routinely have URL rewrites tables with hundreds of thousands of rows from years of catalog changes. Migrating all of them is unnecessary and slow; selective migration based on currently-active URLs is much better.
A pre-migration data quality audit is the highest-leverage activity in the planning phase. The audit catalogs the specific data issues and feeds the decision about whether the tool, custom ETL, or hybrid approach is appropriate.
The delta migration challenge
Magento 1 to Magento 2 migrations almost always require a delta phase: between the initial data migration and the launch cutover, the Magento 1 store continues to take orders, accept customer registrations, and process inventory changes. These changes need to be migrated to the Magento 2 store before the cutover.
The Data Migration Tool supports delta migration natively for standard tables. It uses Magento 1 database triggers to track changes and the migration tool replays them into Magento 2. This works well for stores using the tool exclusively.
For custom ETL pipelines, delta support has to be built. The typical pattern: trigger-based change tracking on the Magento 1 side, with the custom ETL pipeline reading the change log and applying the changes to Magento 2. The complexity is in handling edge cases: customers who register on M1 after migration, orders that span the cutover, inventory that changes during the cutover window.
The cutover window length is determined by how reliable the delta migration is. Stores using the tool with simple delta requirements can cut over in a few hours. Stores using custom ETL with complex delta requirements may need a 24-48 hour cutover window. For high-volume stores, this is a meaningful business consideration.
What the cutover actually looks like
The cutover is the moment the Magento 1 store stops taking orders and the Magento 2 store starts taking them. The sequence:
First, the Magento 1 store is set to maintenance mode (no new orders, customer service continues). The exact start time is usually scheduled for a low-traffic period: typically late evening or early morning depending on the store’s customer geography.
Second, the final delta migration runs. All changes since the most recent delta sync are migrated to Magento 2. For stores using the tool, this is typically 30-60 minutes for moderate stores. For custom ETL stores, it varies based on the delta volume.
Third, the new Magento 2 store is sanity-tested. Test orders, customer logins, search functionality, payment flow, and integration with ERP/CRM systems. This typically takes 1-2 hours.
Fourth, DNS is switched to point to the new Magento 2 store. The DNS propagation takes 5-60 minutes depending on TTL settings.
Fifth, the Magento 2 store is monitored intensively for the first 24 hours. The on-call team is fully staffed. Customer service is briefed on the migration and prepared for any data-related questions from customers.
The cutover window from “store goes into maintenance” to “store is fully on Magento 2” is typically 4-8 hours for well-prepared migrations. Longer cutovers usually indicate insufficient delta migration testing.
What happens after launch
The first 30 days after launch are when data migration issues surface. The patterns:
Week 1: Customer service tickets about missing order history, addresses not transferring, or saved payment methods that disappeared. Most are real data migration issues that need targeted fixes.
Week 2-3: Reporting discrepancies between the old and new stores. The finance team is reconciling numbers and finds gaps. Most of these are explainable (different reporting periods, different inclusion of test orders) but each needs investigation.
Week 4: The first invoice and shipment cycle on the new platform completes. Any issues with ERP or shipping integration that didn’t surface in testing show up here.
A useful pattern: budget for a dedicated post-launch stabilization sprint in the first 30 days. Not for new features, but specifically for resolving the data and integration issues that surface only in production use. Migrations that skip this phase tend to accumulate technical debt that affects the next 6-12 months.
The honest budget framing
For a $20M Magento 1 store migrating to Magento 2 (Adobe Commerce), a realistic budget for the data migration component alone is:
| Approach | Realistic budget range | Best fit profile |
|---|---|---|
| Tool only | $25K-$60K | Clean source data, limited extensions |
| Tool + custom supplements | $60K-$160K | Mixed source data, several key extensions |
| Full custom ETL | $120K-$280K | Complex source data, heavy extension dependency |
These ranges assume professional services pricing at typical mid-market agency rates. They do not include the cost of source-side preparation (data cleanup, extension audit), which can add 20-40% to the total.
The total Magento 1 to Magento 2 project cost (data migration plus storefront rebuild, theme migration, extension porting, testing, and launch) for a mid-market store typically runs $200K-$600K. The data migration is 15-25% of that total. Treating it as a minor component is the most common way to blow the total budget.
Bemeir’s Magento team scopes the data migration as a deliberate engagement at the start of any Magento 1 to Magento 2 project, with a pre-migration audit, a tool-vs-custom decision based on the source data, and a budget that reflects the real complexity. The clients who treat this seriously have predictable migrations. The clients who don’t usually end up calling for help in week 14 of a project that should have shipped in week 12. The data work is the work that makes or breaks the migration timeline.
