A Hyvä migration looks shorter on paper than it turns out to be. Vendor pitches and conference demos suggest twelve to sixteen weeks of work, with smooth handoffs and a clean cutover. In practice, mid-market Adobe Commerce stores with realistic complexity, third-party modules, custom theme work, integration touchpoints, usually run twenty to twenty-eight weeks once discovery, scope changes, and the final stabilization sprint are accounted for. The gap between marketing timeline and reality is not because Hyvä is hard. It is because most migration plans underestimate the discovery work and skip the parts that determine whether the launch holds up under traffic.
This piece is a sprint-by-sprint breakdown of what a Hyvä migration actually looks like for a mid-market store running Magento 2.4.6 or later. The pattern below comes from Bemeir’s Hyvä migration practice across dozens of mid-market and enterprise engagements, and it is what we use to set realistic timeline expectations with clients before a contract is signed.
What Counts as Mid-Market for This Discussion
For the purposes of timeline planning, “mid-market” means: between twenty and one hundred million in online revenue, between five thousand and one hundred thousand active SKUs, between one and five storefronts in a single Adobe Commerce installation, and an existing technology stack that includes ten to thirty installed Magento extensions plus a few custom modules. Stores smaller than this can sometimes complete a Hyvä migration in twelve weeks. Stores larger than this, true enterprise, multi-store international, should plan for thirty to forty weeks.
Discovery: Weeks One Through Three
Discovery is the work most teams compress. It should not be. The discovery phase produces the artifacts that everything downstream depends on: the module compatibility matrix, the theme rebuild scope, the integration touchpoint map, and the regression test plan. Discovery work that gets squeezed shows up later as scope changes, rework, and missed deadlines.
The deliverables for a thorough three-week discovery include:
- A complete inventory of installed Magento extensions, scored for Hyvä compatibility
- An audit of the existing Luma theme, broken down by custom component
- A list of every third-party JavaScript that runs on the storefront, with vendor responses on Hyvä compatibility
- A measured Core Web Vitals baseline on production, segmented by page type
- A user flow inventory documenting every customer interaction the storefront supports
- A QA scope estimate broken out by automation feasibility
Bemeir’s Hyvä discovery practice publishes the compatibility audit framework that this work uses, and the framework is built around the same dimensions that the Hyvä Themes team publishes in their official compatibility documentation.
Foundation: Weeks Four Through Six
The foundation phase is when the engineering team stands up the Hyvä environment and starts moving the core. The Hyvä base theme is installed, the development environment is configured, the deployment pipeline is updated, and the team starts implementing the homepage and the first product detail page template.
This phase typically takes three weeks because the work has dependencies on Adobe Commerce’s deployment model. Each environment (local, dev, staging) has to be configured. Cache strategies have to be revisited. The CI/CD pipeline has to be updated to handle the new theme structure. And the team’s working agreement on Hyvä conventions, naming, file structure, component patterns, has to be established before serious work begins.
The output of the foundation phase is a working Hyvä storefront that renders the homepage and the PDP, with no full-catalog testing yet. It is incomplete by design. The point of this phase is to validate the architecture, not to ship features.
Module Rebuild: Weeks Seven Through Twelve
This is the longest phase and the source of most timeline surprises. Every installed Magento extension that touches the frontend has to be evaluated, and most have to be rebuilt or replaced. The decisions break down into categories:
- Compatible out of the box: the vendor has shipped a Hyvä-compatible build. Use it.
- Compatible with the Hyvä Compatibility Module: a Hyvä community module exists. Install and test.
- Vendor commitment: the vendor has committed to ship Hyvä compatibility on a roadmap. Negotiate timing.
- Rebuild required: the functionality is needed, no Hyvä support exists, the team rebuilds it natively.
- Replace: the functionality is needed but the current vendor has no path forward; a different vendor is sourced.
- Remove: the functionality is not actually needed; the migration is the opportunity to retire it.
The rebuild work is what blows up timelines. Each rebuild module is a discrete project: scope, design, build, test, deploy. The discovery phase should have identified roughly how many rebuilds are coming, but the actual effort per rebuild varies widely. A search refinement bar might take a week. A product configurator might take six weeks.
| Migration phase | Duration (mid-market) | Key risks |
|---|---|---|
| Discovery | 3 weeks | Skipped or compressed work returns as scope changes |
| Foundation | 3 weeks | Underestimated CI/CD and environment work |
| Module rebuild | 5-8 weeks | Unscoped vendor dependencies, third-party gaps |
| Theme & UX completion | 4-6 weeks | Pixel-perfect parity expectations vs Hyvä conventions |
| Integration testing | 2-3 weeks | Surprise data discrepancies across payment/shipping |
| Performance tuning | 2 weeks | INP/LCP issues that need design changes, not just code |
| Pre-launch hardening | 2 weeks | Last-minute regressions from extension updates |
| Launch & stabilization | 2-4 weeks | Real-world edge cases not surfaced in QA |
Theme and UX Completion: Weeks Thirteen Through Eighteen
With modules in place, the team completes the theme work, every page template, every component, every responsive breakpoint, every accessibility check. This is where pixel-perfect parity expectations meet Hyvä conventions, and the conversation with the design team has to happen explicitly. Hyvä’s Tailwind-first architecture works against certain Luma-era design choices, and the cheapest path is usually to adjust the design rather than to fight the framework.
Accessibility deserves particular attention during this phase. The Web Content Accessibility Guidelines (WCAG) at level AA are now table stakes for most jurisdictions, and the migration is the natural moment to close any gaps in the existing storefront. Bemeir’s Hyvä builds include accessibility validation in this phase rather than treating it as a post-launch concern.
Integration Testing: Weeks Nineteen Through Twenty-One
Once the storefront is functionally complete, the team runs full integration testing against the entire third-party stack: payment providers (Stripe, Braintree, Adyen, PayPal), shipping carriers, tax engines, ERP, PIM, marketing automation, customer data platforms. Each integration is tested end-to-end with realistic data, and the team validates that no behavior has regressed against the Luma baseline.
Surprises here are common. A payment provider’s redirect flow that worked on Luma may need adjustment for Hyvä’s cart structure. A shipping rate calculator that returned results in 200ms on Luma may now run twice because of how Hyvä re-renders the cart. The integration testing phase is where these surprises surface, and the schedule must include time to fix them.
Performance Tuning: Weeks Twenty-Two and Twenty-Three
With everything functionally working, the team measures Core Web Vitals and tunes against the baseline established in discovery. Hyvä’s defaults are fast, but tuning is still required. LCP needs image strategy work. INP needs hydration and event handler work. CLS needs layout reservation. The patterns are documented across Bemeir’s Hyvä performance practice, and a focused two-week sprint is typically enough to land in the green for all three metrics.
Pre-Launch Hardening: Weeks Twenty-Four and Twenty-Five
The last two weeks before cutover are hardening. The team freezes new feature work, runs the full QA regression, validates monitoring and alerting, exercises the rollback plan, and runs a final security review. Anything not shipped by the start of this phase ships after launch, not before.
This is also when the team coordinates with adjacent stakeholders, marketing, customer service, paid acquisition, on the cutover plan. Marketing pauses email sends during the cutover window. Customer service prepares scripts for handling expected post-launch incidents. Paid acquisition pauses bidding briefly to allow CrUX data to stabilize.
Launch and Stabilization: Weeks Twenty-Six Through Twenty-Eight
Cutover happens, and the team stays on alert for two to four weeks. Real-world edge cases surface that QA did not catch. Conversion rates take a few days to stabilize. The team’s working agreement with the business sponsors should treat this period as expected, not as crisis. The pattern of post-launch issues is well-understood, and the playbook for handling them is straightforward if the team has prepared.
For broader context on Adobe Commerce platform engineering, the Adobe Commerce DevDocs and the Hyvä Themes documentation are the primary references, and Adobe’s Experience League covers operational concerns.
What Throws Off the Timeline
The most common timeline disruptions in Hyvä migrations are: discovery compressed below three weeks, scope creep on theme parity that the design team did not commit to up front, vendor dependencies that arrive late or never, and a QA scope that did not include automation early enough. Plans that account for these risks land on time. Plans that assume best-case-everywhere slip.
For mid-market stores comparing platform investments more broadly, Bemeir’s practice across Adobe Commerce, Shopify Plus, and Shopware gives the same discovery-first treatment to platform transitions as to theme migrations. The pattern that holds across all of them is that the work compressed at the start surfaces as overrun at the end. Build the time in early.
