The most common gap between what a Magento 1 merchant expects and what they get is the timeline and budget for the migration to Adobe Commerce. Sales pitches estimate four months. Internal IT estimates six months. The actual project runs nine to twelve months for a mid-market store. The gap is not because anyone is being dishonest; the gap is because the parts of the project that drive duration are different from the parts the early conversations focus on.
For Magento 1 merchants who are still on the legacy platform in 2026, the migration is not optional anymore. Adobe ended official support in June 2020, security patches stopped, and the PCI compliance situation for Magento 1 stores is increasingly untenable. The question is not whether to migrate but how to do it without a budget surprise or a timeline collapse.
Bemeir’s Magento team has shipped enough Magento 1 to Adobe Commerce migrations to have a realistic model for the timeline and the cost. Here is the honest framing.
The components of a Magento 1 to Adobe Commerce migration
A full migration is not one project; it is six concurrent workstreams that have to converge at launch. Understanding the workstreams separately makes the timeline and budget tractable.
Data migration. The catalog, customers, orders, configuration, and historical data moving from Magento 1 to Adobe Commerce. Typically 15-25% of the total project cost, 4-8 weeks of dedicated work.
Storefront rebuild. The new theme, page templates, and customer-facing experience on Adobe Commerce. This is usually the largest workstream by both cost and duration. Hyvä is now the standard recommendation here; the older choice of Luma is no longer worth scoping for new builds. Typically 35-45% of project cost, 12-20 weeks.
Extension migration. Every third-party extension on Magento 1 needs to be either replaced (with a Magento 2/Adobe Commerce equivalent), rebuilt natively, or scoped out of the new build. This is the most variable workstream because it depends entirely on how many extensions the source store has and how complex they are. Typically 15-25% of project cost, 6-12 weeks (often parallel with storefront).
Backend configuration. Setting up the new Adobe Commerce store with the merchant’s specific configuration: payment methods, shipping methods, tax rules, customer groups, product attributes, store views, and B2B configuration if applicable. Typically 5-10% of project cost, 3-6 weeks.
Integration rebuild. ERP, CRM, OMS, PIM, shipping, accounting, and any other integration the Magento 1 store has needs to be rebuilt for Adobe Commerce. This workstream is heavier than expected for B2B stores and lighter for B2C stores. Typically 10-15% of project cost, 6-10 weeks.
Testing, QA, and launch. End-to-end testing, performance tuning, soft launch on a traffic slice, and full cutover. Typically 5-10% of project cost, 3-5 weeks (most of which is parallel with the back half of build).
The workstreams overlap in execution but their durations are mostly additive when planned realistically.
What the realistic timeline actually looks like
A mid-market Magento 1 to Adobe Commerce migration (store revenue $10M-$40M, B2C or light B2B, moderate extension footprint) typically follows this timeline:
| Phase | Duration | Cumulative weeks |
|---|---|---|
| Discovery and architecture | 4-6 weeks | 4-6 |
| Design system and Hyvä theme base | 4-6 weeks | 8-12 |
| Backend configuration | 3-5 weeks (parallel with theme) | 8-12 |
| Page type migrations | 8-12 weeks | 16-24 |
| Extension migration | 6-10 weeks (parallel with pages) | 16-24 |
| Data migration | 4-8 weeks (parallel with build) | 16-24 |
| Integration rebuild | 6-10 weeks (parallel with build) | 16-24 |
| Hyvä Checkout configuration | 3-5 weeks (parallel) | 18-26 |
| QA and regression testing | 4-6 weeks | 22-32 |
| Performance tuning | 2-3 weeks | 24-35 |
| Soft launch and stabilization | 2-4 weeks | 26-39 |
A B2B migration with custom company accounts, ERP integration, and approval workflows typically adds 8-16 weeks to the total: 30-50 weeks end-to-end.
The variance is driven primarily by the extension count and complexity, the integration architecture complexity, and the discovery quality. Migrations with clean discoveries that catch the complexity up front stay closer to the lower bound; migrations with poor discoveries that surface complexity mid-build run to the upper bound or beyond.
What the realistic budget actually looks like
The budget ranges that match the timeline above:
| Store profile | Realistic budget range | What it covers |
|---|---|---|
| $5M-$15M B2C, simple extension stack | $180K-$320K | Full migration, Hyvä storefront, standard checkout, basic integrations |
| $15M-$40M B2C, moderate extensions | $320K-$580K | Full migration, Hyvä storefront, Hyvä checkout, multiple integrations, performance tuning |
| $15M-$40M B2B with ERP integration | $480K-$820K | Full migration with B2B company accounts, custom approval workflows, ERP integration, customer-specific pricing |
| $40M-$100M B2C/B2B with complex catalog | $700K-$1.4M | Full migration with multi-store views, complex catalog, multiple integrations, deeper customization |
| Above $100M, enterprise complexity | $1.2M-$3M+ | Multi-instance, headless components, deep integration, enterprise SLA |
These ranges assume mid-market agency pricing at $175-$250 per hour blended rate. They include implementation only, not platform licensing (Adobe Commerce license fees are separate and typically run $25K-$200K annually depending on GMV tier), hosting (typically $20K-$100K annually), or third-party software the new store depends on.
The most common budget surprise is not the implementation itself; it is the third-party software the new store needs that the old store didn’t (analytics upgrades, monitoring tools, security scanning, marketing automation enhancements). A 10-15% buffer for these is realistic.
The five things that move the budget most
Specific aspects of the migration meaningfully shift the cost up or down from the range above.
Extension count and quality. A store with 8 well-built extensions costs much less to migrate than a store with 25 mediocre extensions. Each extension that needs custom rebuild adds $15K-$60K to the budget. The compatibility audit done up front determines this honestly.
B2B complexity. Adobe Commerce B2B with company accounts, approval workflows, and customer-specific catalogs adds $80K-$250K to the project depending on configuration depth. If B2B is in scope, it usually deserves its own dedicated workstream.
Integration depth. ERP integration alone is typically $40K-$180K depending on the ERP system and the integration architecture. CRM, PIM, and OMS integrations each add similar amounts. Stores with one or two integrations are much cheaper than stores with five or six.
Data quality of the source store. Magento 1 stores with clean data migrate in a few weeks. Stores with years of accumulated data issues need data cleanup as part of the migration, which can add $30K-$120K and several weeks.
Custom feature requirements on the new store. If the merchant uses the migration as an opportunity to add features the Magento 1 store didn’t have, each feature adds to the budget. Common additions: native search upgrade, native marketing automation, advanced personalization, new checkout flows.
What you can do to compress the timeline
The timeline above is the standard. Compressing it meaningfully requires specific decisions:
Run discovery in parallel with vendor selection. Most merchants do discovery sequentially with each candidate agency, then pick one and start build. Discovery in parallel with selection (treating discovery as a paid engagement that both finalists run) compresses 4-6 weeks.
Limit scope to migration only. Resist the temptation to add new features as part of the migration. Get to feature parity on the new platform first, then add new features in post-launch sprints. This can save 6-12 weeks.
Choose Hyvä by default for the storefront. PWA Studio and full headless options add weeks to the timeline without delivering benefits most stores will use. Default to Hyvä unless there is a specific reason not to.
Defer non-critical extensions to post-launch. If an extension is nice-to-have but not critical, ship without it and add it in a post-launch sprint. This often removes 2-4 weeks from the critical path.
Run integration work in parallel with build. Integration teams can work on the integration architecture, ERP connector, and middleware while the build team works on the storefront. The two converge in QA. This is standard practice but is often missed when the same team is doing both.
A migration that takes the standard path and applies all of these compressions can typically ship in 22-30 weeks (B2C) or 28-40 weeks (B2B), versus the 26-39 weeks (B2C) or 30-50 weeks (B2B) baseline.
What you should not compress
Some shortcuts feel like compression and are actually risk concentration:
Skipping the compatibility audit. This is the most common shortcut that backfires. The audit is 1-2 weeks of work that prevents 4-8 weeks of mid-project rework. Always do it.
Compressing QA to 2 weeks. QA is where regressions get caught. A 2-week QA window finds the easy ones and leaves the hard ones for production. Real QA on a mid-market migration is 4-6 weeks.
Skipping performance tuning. A new Hyvä storefront ships with Lighthouse scores in the 80s without tuning, low 90s with light tuning, and high 90s with focused tuning. The difference between launch-day 85 and launch-day 95 is 1-2 weeks of work and meaningful conversion lift.
Skipping the soft launch. Going directly to full cutover instead of a phased rollout concentrates risk at the worst possible moment. Soft launch on 5-10% of traffic for a week catches issues before they affect the whole customer base.
The honest framing for a Magento 1 merchant
The Magento 1 to Adobe Commerce migration is not the project most merchants want to do. It does not add new revenue capabilities; it just gets the store onto a supported, secure, modern platform. The merchant who waits another quarter is taking on real security risk and accumulating technical debt. The merchant who migrates now is making a one-time investment that buys five-plus years of platform support.
The timeline and budget are real numbers, and the honest conversation is that they are higher than the merchant expects when starting the procurement process. The merchants who land their migrations cleanly are the ones who plan to the realistic numbers from the start, scope the discovery seriously, and resist the urge to compress the parts of the project that should not be compressed.
Bemeir’s Magento team has shipped Magento 1 to Adobe Commerce migrations across the store sizes and complexities described above. We are happy to walk through what the realistic timeline and budget look like for your specific situation, including what factors would push it higher or lower from the standard ranges. The conversation matters because the wrong assumptions at the start of the project become the wrong budget and the wrong timeline by month four. The right assumptions become a clean migration that ships when it was supposed to and costs what it was supposed to. The honest planning is the cheapest insurance in the project.
