How long does a Hyvä migration actually take?
A typical Luma → Hyvä migration takes 6–10 weeks from kickoff to live cutover. Hyvä Commerce (Theme + Checkout) sits at 10–14 weeks. Hyvä Enterprise on Adobe Commerce with full B2B features hits 14–16 weeks.
These are realistic numbers from our last 50+ Hyvä builds, not marketing aspirations. Here's what drives them, where the variance comes from, and the honest worst-case overruns.
The headline timelines
| Project type | Typical timeline | Range |
|---|---|---|
| Hyvä Theme only (small store, 5–10 extensions) | 6 weeks | 5–8 weeks |
| Hyvä Theme (medium store, 15–25 extensions) | 8 weeks | 7–10 weeks |
| Hyvä Theme (large store, 25+ extensions) | 10 weeks | 9–12 weeks |
| Hyvä Commerce (Theme + Checkout) | 12 weeks | 10–14 weeks |
| Hyvä Enterprise (Adobe Commerce B2B) | 14 weeks | 12–16 weeks |
| Standalone Hyvä Checkout on existing Hyvä Theme | 3 weeks | 2–4 weeks |
| Standalone Hyvä Checkout on Luma | 4 weeks | 3–5 weeks |
| Per-extension custom Hyvä compat module | 2 weeks | 1–3 weeks |
What drives the timeline
In rough order of impact:
1. Paid extension count
This is the single biggest variable. Each paid extension on the store needs a Hyvä compatibility module before its frontend renders correctly. Many vendors ship their own; the rest need custom compat.
Timeline impact: each custom-compat extension adds 3–10 days. A clean store with 5 vendor-compat extensions runs fast; a store with 25 mixed extensions adds 4–6 weeks.
2. Hyvä Commerce vs Hyvä Theme
Hyvä Theme alone covers the storefront. Adding Hyvä Checkout (with payment + shipping + fraud module integration) adds 2–4 weeks. Adding Hyvä Admin + Insights adds 1–2 weeks.
3. B2B feature scope (Adobe Commerce)
Each Adobe Commerce B2B feature (company accounts, shared catalogues, customer pricing, quotes, approvals) is a separate Hyvä template surface. Full B2B scope adds 4–6 weeks.
4. Design fidelity vs rebrand
A faithful Luma → Hyvä rebuild matches the existing design under the new render layer. A brand refresh bolted on adds 2–3 weeks of design + dev iteration. Either commit to the rebrand at scoping or save it for next year.
5. Multi-store / multi-website Magento
Two stores aren't 2x the time of one if design + functionality are identical. Five stores with country-specific variations are easily 3x the time.
6. Customer-account section complexity
Stock Magento customer account is straightforward. If you've added subscriptions, gift cards, store credit, returns portal, multi-address shipping, each adds 2–5 days.
7. Custom checkout flow complexity
Custom shipping methods, B2B approval routing, multi-step checkout customisations, conditional fields per shipping country — each adds time. Heavy customisation can push standalone Hyvä Checkout from 3 weeks to 6.
The standard 8-week breakdown (Theme-only migration)
For a typical medium-store Hyvä Theme migration:
- Week 1: Foundation — Hyvä Theme install, Tailwind brand config, design system component library, header / footer / nav
- Week 2–3: Page templates — PDP, PLP, search, cart, customer account, CMS blocks
- Week 4–5: Extension compatibility — vendor + custom compat modules
- Week 6: Performance tuning — Lighthouse mobile 90+ as exit criteria
- Week 7: UAT on staging — real orders end-to-end, cross-browser, accessibility, bug bash
- Week 8: Cutover + 72-hour post-launch monitoring + bug-fix sprint
Each week has explicit milestones we check against. If we slip a milestone, the cutover date moves — we don't compress later weeks to recover.
The "what derails an 8-week timeline" list
In rough frequency order, from our project records:
1. Extension list grows mid-project (most common)
New paid extension discovered in week 4 = 1–3 weeks added. Almost always avoidable by doing the inventory thoroughly before kickoff.
Mitigation: treat the extension inventory as a hard gate before scoping is finalised. Don't start build work without it locked.
2. Design scope creep
"While we're at it, can we redesign the PDP?" = 2+ weeks added. Common pattern: stakeholder sees the new Hyvä storefront on staging and decides the colours / typography aren't quite right — leading to a rebrand mid-project that wasn't scoped.
Mitigation: lock design references at scoping. Commit to either "faithful Luma rebuild" or "include a rebrand in scope from day 1." Don't allow ambiguity.
3. Magento version upgrade combined
Upgrading Magento 2.4.4 → 2.4.7 + migrating to Hyvä in the same window = +3–4 weeks of integrated complexity.
Mitigation: sequence them. Upgrade Magento first, run it in production for 4–6 weeks to surface regressions, then migrate to Hyvä. Combined upgrades almost always cost more than the sequenced version.
4. Staging environment not ready at kickoff
If we can't deploy to staging on day 1 of week 1, every day of delay slips cutover 1-for-1.
Mitigation: stand up staging during pre-flight, before the kickoff date.
5. Stakeholder review slow during UAT
UAT week assumes your team can dedicate time to test. If feedback takes 5 working days to come back, that's 5 days the cutover gets pushed.
Mitigation: book stakeholder UAT calendar slots before kickoff. Don't leave week 7 review to be scheduled ad-hoc.
6. Surprise B2B requirement surfaces
Discovering in week 5 that the merchant needs company-account self-service or a quote flow turns a B2C migration into a B2B project.
Mitigation: explicit B2B-scope question at scoping. "Do you have any of these features?" + checklist of B2B Adobe Commerce features.
7. Cutover date conflicts with sale events
Trying to cut over the week of Black Friday or during a product launch. Don't.
Mitigation: pick a 4-week quiet window for cutover + post-launch. Wait for the right window if necessary; we've delayed migrations 8 weeks for this.
When 8 weeks isn't realistic
Be honest if any of these apply — you need 10–14 weeks, not 8:
- 25+ paid extensions
- B2B Commerce features in scope
- Heavily customised checkout flow
- Hyvä Commerce scope (not just Hyvä Theme)
- Brand rebrand bolted onto the migration
- Multi-store / multi-website Magento setup with >2 storefronts
- Adobe Commerce on Cloud (CI pipeline adds friction vs self-hosted)
For these, we quote 10–14 weeks upfront. 8 weeks gets you a half-finished site live; nobody wins.
Worst-case overruns we've seen
Realistic worst cases from our project records:
12-week project that ran 18 weeks. B2B Adobe Commerce. Mid-project the merchant added a requirement to integrate with a custom ERP that wasn't on the original list. The ERP integration alone added 4 weeks. Final outcome: shipped successfully but 6 weeks late.
8-week project that ran 11 weeks. Standard Magento Open Source. Mid-project a Magento 2.4.6 → 2.4.7 upgrade was needed to support a security patch. We sequenced: upgrade, then resume migration. Added 3 weeks.
10-week project that ran 14 weeks. Brand refresh bolted onto a migration mid-project. The design team produced new mocks in week 5; the dev team had to throw away 2 weeks of work and rebuild from the new mocks. Lesson: design before build.
In all three cases, the overrun was driven by mid-project scope changes — not technical problems with Hyvä. The technical work is well-trodden; the project management is where things go wrong.
How we structure timeline commitments
When we quote, the timeline is fixed against the agreed scope. Specifically:
- Each week has explicit deliverables in writing
- Each week we publish progress vs the plan
- Out-of-scope additions trigger a re-quote (price + timeline) before we touch them
- If we slip a milestone, you hear about it the week it slips, not at the end
- The cutover date moves with milestone slippage; we don't compress later weeks to recover
This is the practical meaning of "fixed-price, fixed-timeline." The trade-off: we won't accept mid-project scope changes without a re-quote.
The "can we ship faster?" question
Common ask. Sometimes yes, sometimes no.
Faster is realistic when:
- You can prioritise stakeholder responsiveness (UAT in 1 day not 5)
- You're willing to drop nice-to-haves from scope
- You can dedicate in-house developer time to help with QA + UAT
- You're not in a sale-event window or competing for our calendar
Faster isn't realistic when:
- Your extension list has surprises
- Your design fidelity isn't locked
- Your team is already overcommitted (UAT will lag)
- You're insisting on Phase 2 features being delivered in Phase 1
We're honest about which case you're in during scoping. Sometimes the answer is "yes we can ship in 6 weeks instead of 8"; sometimes it's "no, and rushing will hurt quality." We say which.
Next steps
- See the Hyvä Migration service page for what's included
- Read How to migrate Magento Luma to Hyvä in 8 weeks for the week-by-week breakdown
- Read Hyvä migration cost in 2026 for the line-item budget
- Book a 30-minute scoping call for a fixed-price, fixed-timeline quote