A meaningful number of mid-market retailers are still running Magento 1 in 2026, six years after the platform reached official end of life. The reasons are usually pragmatic: the platform is stable, the business has bigger fires to fight, and the migration cost feels prohibitive. The pragmatic reasoning is reasonable, but it usually overestimates the migration cost while underestimating the running cost of staying on M1. This article unpacks what actually drives Magento 1 to Magento 2 migration cost on mid-market retailers, and the specific line items where teams consistently overpay.
The framing here reflects how Bemeir’s M1-to-M2 migration practice actually scopes these engagements. The costs vary widely across retailers, but the variation is explainable, and the drivers are understandable in advance.
The headline range
A mid-market Magento 1 to Magento 2 (or Adobe Commerce) migration typically falls in the $120,000 to $400,000 range, all-in. The midpoint for a non-trivial retailer with moderate customization, a typical B2C product catalog, and standard integrations sits around $200,000 to $260,000. The variation reflects the scope of customization carrying forward, the complexity of integrations, the data volume, the number of stores and languages, and the design choices made during the migration.
The cost is bounded. It is not “as much as it takes.” A serious migration partner can scope the work to a defined budget by making explicit choices about what carries forward, what gets rebuilt, and what gets retired. The retailers who overspend almost always overspend in one of five specific categories.
Cost driver 1: Custom module re-platforming
The largest single cost driver in most M1-to-M2 migrations is custom modules. Magento 1’s module architecture is fundamentally different from Magento 2’s, which means custom modules cannot be migrated; they have to be rebuilt. The cost of rebuilding depends on how many custom modules the M1 site has and how much business logic they contain.
A typical mid-market M1 site has 8-25 custom modules. Of these, the audit usually finds that roughly 30-50% are no longer needed, either because their functionality is now in Magento 2 core, because the business no longer needs the feature, or because a modern third-party module solves the problem better. Retiring these modules is one of the highest-leverage cost reductions available in the migration scope.
The remaining custom modules — the ones that genuinely contain business logic the retailer needs — have to be rewritten. The cost depends on their complexity: simple ones (small admin interfaces, lightweight integrations) typically run $8,000-$20,000 to rebuild; complex ones (pricing engines, custom checkout flows, ERP integrations) can run $30,000-$80,000.
| Custom module category | Typical count on mid-market M1 | Migration cost per module |
|---|---|---|
| Simple admin extensions | 3-8 | $5K-$12K |
| Frontend display modifications | 2-6 | $8K-$18K |
| Lightweight third-party integrations | 2-5 | $10K-$25K |
| Custom pricing or promotion logic | 1-3 | $20K-$50K |
| Custom checkout or cart flow modifications | 1-2 | $25K-$70K |
| Complex integrations (ERP, WMS, CRM) | 1-3 | $30K-$80K |
| Custom B2B workflow modules | 0-2 | $40K-$100K |
The single most common overspending pattern is rebuilding modules that should have been retired. The audit step that catalogs which modules are actually being used, by which business processes, with what frequency, is one of the highest-ROI hours in the entire migration scope.
Cost driver 2: Theme rebuilding
Magento 1 themes cannot be migrated to Magento 2. The theme architecture is fundamentally different, and the rebuild is necessary regardless of whether the retailer wants to keep the existing design or refresh it.
Two paths exist. The first is to rebuild the existing M1 theme on Magento 2’s Luma framework, preserving the visual design as closely as possible. The cost typically runs $40,000-$80,000 for a mid-market storefront with standard customization. The result is functional but inherits all the performance constraints of Luma.
The second path is to migrate directly to Hyvä, the modern Tailwind-based theme framework that has become the default trajectory for serious Adobe Commerce retailers. The cost is similar — $50,000-$100,000 — but the result is a dramatically faster storefront with substantially better Core Web Vitals out of the box. Bemeir’s Hyvä practice sees the majority of M1-to-M2 migrations now landing on Hyvä rather than Luma, because the incremental cost is small and the operational benefit is large.
The cost the retailer should compare against is not “Luma vs Hyvä migration cost.” It is “Luma migration cost plus Hyvä migration cost two years later.” Doing both is materially more expensive than doing Hyvä directly. The retailers who overspend in this category are typically the ones who treated the M1-to-M2 migration as a pure replatforming exercise and went through Luma first.
Cost driver 3: Data migration
Data migration is unglamorous and consistently underestimated. The categories that have to migrate cleanly:
- Product catalog. SKUs, attributes, attribute sets, category trees, product images, inventory, pricing tiers, custom options. Typical effort: $8K-$20K.
- Customer data. Customer accounts, addresses, customer groups, custom attributes, password hashes (the salt format differs between M1 and M2 and requires special handling). Typical effort: $10K-$25K.
- Order history. Past orders, invoices, shipments, credit memos. Depending on volume and depth, $15K-$40K.
- CMS content. Pages, blocks, widgets. Typical effort: $5K-$15K.
- Configuration data. Tax rules, shipping methods, payment configurations, promotions. Typical effort: $5K-$15K.
The Magento Data Migration Tool, an officially supported Adobe Commerce tool documented in detail in the Adobe Commerce DevDocs, handles a significant portion of the standard data migration. The cost line items above assume the tool is used as a foundation, with custom mapping and adapter work layered on top for non-standard data.
The overspending pattern in this category is treating data migration as a separate stream from custom module migration. The two are tightly coupled: a custom module that uses non-standard data structures requires migration work specific to those structures, and the migration scoping should treat them as a unit.
Cost driver 4: Integration redevelopment
Magento 1 sites typically have integrations with several third-party systems: ERP, WMS, CRM, payment processors, search providers, shipping carriers, tax engines, email service providers, marketing automation. Each integration has to be re-implemented on Magento 2’s service contract and API architecture.
For most mid-market retailers, the major integrations to migrate are:
- ERP integration (NetSuite, SAP, Microsoft Dynamics, Acumatica): $25K-$80K
- Payment processor (typically already supports M2 natively): $5K-$15K
- Search provider (Algolia, Klevu, Searchspring): $10K-$25K
- Tax engine (Avalara, TaxJar): $8K-$15K
- Shipping integration: $5K-$15K
- Marketing automation (Klaviyo, Bronto, Mailchimp): $8K-$20K
- Custom B2B portal or punchout: $30K-$80K
The overspending pattern is rebuilding integrations to behave identically to their M1 versions, including the workarounds that accumulated over years on M1. The right approach is to use the migration as a forcing function to clean up integration patterns: retire integrations that are no longer needed, simplify ones that have accumulated unnecessary complexity, and adopt vendor-supported M2 connectors where they exist.
Cost driver 5: Project management and QA
The project management and QA share of the budget is often underestimated by retailers but is consistently large in practice — typically 15-25% of the total migration cost. The work includes sprint planning, stakeholder communication, requirements documentation, test plan development, manual QA execution, automated test development, UAT coordination, and launch readiness.
The overspending pattern in this category is shadow project management on the retailer’s side: the internal team taking on coordination work that should have been bundled into the agency scope, and then doing it less efficiently than the agency would have. The right model is to scope the agency engagement to include real project management capacity, and to use the internal team for stakeholder decisions and acceptance rather than for day-to-day coordination.
Where teams consistently overpay
Beyond the line items above, three meta-patterns explain most overspending across M1-to-M2 migrations:
1. Rebuilding everything rather than retiring strategically. The single biggest cost reduction available in a migration scope is deciding what not to migrate. Most M1 sites have accumulated functionality that the business no longer needs.
2. Choosing fixed-bid pricing for genuinely variable scope. M1-to-M2 migrations have intrinsic scope uncertainty. Fixed-bid pricing for the full scope forces the partner to price in risk, which means the retailer pays a risk premium. T&M or hybrid pricing for discovery, with fixed-bid for clearly-defined workstreams, produces better economic outcomes. According to Forrester’s research on technology migration project structures, hybrid pricing models outperform pure fixed-bid for migrations of this complexity by 15-25% in total cost.
3. Skipping the migration audit. A two-to-four-week paid migration audit, scoped at $15,000-$30,000, consistently saves 5-15% of the total migration budget by identifying retire-able modules, unnecessary data migrations, and integration simplifications. The audit is not optional for retailers serious about controlling cost. Bemeir’s Adobe Commerce migration practice treats the audit as the standard opening engagement for any serious M1-to-M2 conversation.
The right way to scope
The migration scope that produces the best economic outcomes is structured in three phases: audit and discovery (4-6 weeks, $25K-$50K), core migration build (16-24 weeks, $150K-$280K), and stabilization and post-launch (4-8 weeks, $25K-$50K). The total comes in at $200K-$380K for a mid-market retailer with typical complexity, and the variability within that range is driven by the variables identified above rather than by surprise scope expansion.
That predictability is what makes M1-to-M2 migrations a tractable budget decision rather than a fearful one. The retailers who delay the migration year after year are usually delaying because they have not done the scoping work to know what it actually costs. Doing the scoping is the first step toward making the decision a real one.
