The most common question asked at the start of a Magento 1 to Adobe Commerce migration conversation is “how long will this take.” The honest answer is that the timeline depends almost entirely on which complexity tier the retailer’s storefront falls into, and the variation across tiers is large. A small DTC retailer with a clean catalog and a handful of integrations is a four-to-six-month migration. A mid-market retailer with moderate B2B features and accumulated customization is six-to-nine months. An enterprise multi-store, multi-region retailer with complex ERP integration is twelve-to-eighteen months. Promising any of these in significantly less time is either a misunderstanding of the work or a pricing strategy that depends on someone else absorbing the overrun.
This article describes what each of those timelines actually contains, what work happens in each phase, and where the schedule slips most often. The framing here is based on the migration patterns Bemeir’s M1-to-M2 practice has executed across mid-market and enterprise retailers, and the cadence reflects realistic engineering throughput, not aspirational marketing numbers.
The three complexity tiers
Most Magento 1 sites fall cleanly into one of three tiers when measured against the migration variables that actually matter.
Tier 1, Small DTC retailer. Single store, single language, primarily consumer-facing, fewer than ten custom modules, standard integrations (Klaviyo, ShipStation, Avalara or no tax engine), under 5,000 SKUs, under 25,000 customer accounts. Typical annual revenue $1M-$8M. Migration timeline: 16-24 weeks.
Tier 2, Mid-market retailer. Single or small multi-store, one or two languages, mixed consumer and B2B features, 10-25 custom modules, integrations with ERP or WMS, 5,000-50,000 SKUs, 25,000-200,000 customer accounts. Typical annual revenue $5M-$50M. Migration timeline: 28-40 weeks.
Tier 3, Complex enterprise retailer. Multi-store, multi-language, multi-region, significant B2B portal, 25+ custom modules, complex ERP integration with SAP or Oracle, custom checkout flows, 50,000+ SKUs, 200,000+ customer accounts. Typical annual revenue $30M+. Migration timeline: 52-78 weeks.
The boundaries are not crisp. Some Tier 2 retailers have one or two Tier 3 complexity features (a complex ERP integration, a sophisticated B2B portal) that push them toward Tier 3 timeline. Some Tier 3 retailers are large in revenue but architecturally simple, which pulls their timeline back toward Tier 2. The audit phase, described below, is what produces a confident tier assignment.
| Tier | Annual revenue | Custom modules | Integrations | Timeline |
|---|---|---|---|---|
| 1, Small DTC | $1M-$8M | < 10 | Standard SaaS | 16-24 weeks |
| 2, Mid-market | $5M-$50M | 10-25 | ERP or WMS, B2B | 28-40 weeks |
| 3, Complex enterprise | $30M+ | 25+ | Complex multi-system | 52-78 weeks |
What each phase contains
Regardless of tier, the migration follows the same phase sequence: audit and discovery, design and architecture, core development, integration and data migration, QA and launch preparation, cutover and stabilization. The proportions shift across tiers but the sequence does not.
Phase 1: Audit and discovery (Tier 1: 2-3 weeks; Tier 2: 4-6 weeks; Tier 3: 8-12 weeks). The audit phase catalogs the existing M1 site comprehensively: every custom module with its purpose, every integration with its current state, every data structure, every operational dependency. The deliverable is a migration plan with phased scope, effort estimates, risk callouts, and a commitment to either Luma or Hyvä as the target frontend. Schedule slips in this phase usually come from incomplete access to the existing system, which is why securing access discipline is part of the migration intake checklist.
Phase 2: Design and architecture (Tier 1: 3-4 weeks; Tier 2: 6-8 weeks; Tier 3: 10-14 weeks). Design system adaptation for the target frontend, architecture decisions for custom module rebuilds, integration architecture, data migration plan. The deliverables are design assets, architecture decision records, and a fully-scoped development backlog. Schedule slips here usually come from indecisive stakeholders or from late-emerging requirements that should have been surfaced in audit.
Phase 3: Core development (Tier 1: 8-12 weeks; Tier 2: 14-20 weeks; Tier 3: 26-38 weeks). The largest single phase. Theme rebuilding, custom module redevelopment, frontend implementation, core checkout and cart flow work. This is also where engineering throughput is most predictable: experienced Adobe Commerce engineers ship at a known velocity, and the phase length is driven primarily by the size of the backlog from Phase 2. Schedule slips in this phase usually come from scope expansion that should have been managed in audit.
Phase 4: Integration and data migration (Tier 1: 3-4 weeks; Tier 2: 6-10 weeks; Tier 3: 12-18 weeks). Often executed in parallel with the back half of Phase 3. ERP, WMS, payment, tax, shipping, and any custom integrations are re-implemented and tested against representative data volumes. Data migration trial runs against an M1 snapshot are executed multiple times to surface issues before cutover. Schedule slips here usually come from undiscovered integration complexity or from delays in third-party vendor responsiveness.
Phase 5: QA and launch preparation (Tier 1: 2-3 weeks; Tier 2: 4-6 weeks; Tier 3: 6-10 weeks). Comprehensive UAT, performance testing, security review, accessibility audit, cutover rehearsal. The cutover rehearsal in particular is non-optional for any retailer above Tier 1, running through the cutover sequence end-to-end against a production-equivalent environment surfaces issues that no amount of unit testing reveals. Schedule slips in this phase are dangerous because they directly affect launch date and are visible to stakeholders.
Phase 6: Cutover and stabilization (Tier 1: 1-2 weeks; Tier 2: 2-4 weeks; Tier 3: 4-8 weeks). The actual launch, plus the immediate post-launch period where the team is on heightened operational footing. Most non-trivial migrations have a 48-72 hour intensive monitoring window followed by a 2-4 week stabilization period where the team is responsive to issues as they emerge.
Where timelines slip most often
Across the migrations Bemeir’s Adobe Commerce team has run, three categories account for the majority of schedule slips.
1. Inadequate audit phase. The audit phase is the highest-leverage time in the entire migration, and the most consistently underdone. Retailers eager to “start building” often push for a compressed audit, with the result that scope assumptions go unvalidated and emerge as problems three months into core development. The retailers who maintain timeline discipline are the ones who treat the audit as non-negotiable.
2. Stakeholder decision latency. Migrations require dozens of decisions across the retailer’s organization: design direction, feature scope cuts, integration vendor selections, data retention policies. Each decision that takes two weeks instead of two days is a small schedule slip; the cumulative effect is large. The retailers who maintain timeline discipline have a designated migration decision authority empowered to make calls without convening committees.
3. Late-discovered third-party constraints. A payment processor that has discontinued support for some legacy feature. A shipping carrier whose API has changed since the M1 integration was built. A vendor extension that has not been ported to Magento 2 and whose developer has gone out of business. These constraints are discoverable in audit if the audit looks for them; they cause schedule pain when they emerge during integration testing.
What “fast” actually means
Some retailers ask whether their migration can be accelerated below the typical tier timeline. The honest answer is that 10-20% acceleration is sometimes possible by adding senior engineering capacity, but 30%+ acceleration is almost never achievable without compromising scope or quality. The bottlenecks in Adobe Commerce migrations are not pure engineering hours; they are sequential dependencies (design before development, development before integration testing, integration testing before launch readiness), and parallelism has limits.
The exception is retailers who genuinely scope down, accept a smaller migration scope by retiring more functionality, deferring integrations, simplifying the launch product. These retailers can shorten the timeline meaningfully, often by 4-8 weeks on a Tier 2 migration. The trade-off is that the deferred work has to happen eventually, and the total cost of doing it later is typically higher than doing it in the initial migration. According to Forrester’s research on technology migration project economics, post-launch follow-on work typically costs 1.4-2.0x what equivalent work would have cost if included in the initial migration scope.
What “slow” actually costs
The other side of the timeline question is what each month of delayed launch actually costs. The cost has two components. The first is direct: every month on Magento 1 is a month with no security patches, no payment-processor improvements, no platform innovation. The second is opportunity cost: every month on Magento 1 is a month without the conversion improvements, search-engine ranking improvements, and operational efficiency improvements the Magento 2 / Adobe Commerce migration enables. According to Akamai’s eCommerce performance research and the Adobe Commerce platform documentation, mid-market retailers on modern Adobe Commerce platforms outperform M1 peer comparisons on conversion rate, mobile experience, and operational uptime.
The retailers who time the migration well are the ones who commit to the timeline that matches their actual complexity, resource the engagement appropriately, and treat the cutover as the start of a new operating capability rather than as the end of a project. That mindset is what produces migrations that ship on schedule and deliver the business value the migration was supposed to deliver in the first place.
