How long does Hyvä migration take? Short answer

Hyvä migration is a frontend-replacement project that swaps Magento 2's Luma theme for Hyvä (Tailwind + Alpine.js). The honest calendar-time range is 2 weeks to 6 months, with most independent Magento Open Source stores landing between 4 and 10 weeks from kickoff to production launch. The timeline is driven primarily by extension count, custom code volume, and how many stakeholders need to sign off on QA. A small Luma store with under 20 extensions and minimal customisation can ship in 14 calendar days using my fixed-fee sprint.

Dev hours and calendar time are different things. A 320-hour project can ship in 4 weeks with two developers in parallel, or 10 weeks with one developer working solo on a part-time client schedule. The numbers below assume a single senior Hyvä developer (me, in most cases) working with focused client availability.

Hyvä migration timeline by store size

Calendar weeks for the four stores I've shipped or quoted in the last 18 months, plus the typical industry baseline for enterprise projects on Adobe Commerce 2.4.4 — 2.4.9.

Store profile	Calendar time	Dev hours	What ships
Starter sprint (fixed fee, $2,499)	2 weeks	~100h	Hyvä baseline + 10 most-used pages + checkout. Tiny stores only.
Small (1 storefront, <20 ext)	2–4 weeks	120 – 320h	Full Hyvä theme port, all pages, 1 QA round, launch.
Mid-market (multi-store, 30–60 ext)	6–10 weeks	320 – 1,000h	Multi-store config, B2B-lite, custom Hyvä modules, 2 QA rounds, staged launch.
Enterprise (Adobe Commerce, B2B, integrations)	3–6 months	1,000 – 3,200h+	Full B2B port, page builder migration, ERP/PIM/CRM integration ports, blue-green deploy.

If you're shopping multiple developers and one of them quotes 2 weeks for a 60-extension mid-market store, walk away. That's a number designed to win the bid, not to ship a working store.

Phase 1: discovery and compatibility audit (1–2 weeks)

Before any Hyvä code is written, I run a discovery sprint that produces a written audit. The deliverable is a per-extension compatibility matrix and a custom-code inventory. Calendar time is 1–2 weeks depending on extension count and how organised the existing codebase is.

What happens in this phase:

• Day 1–2: read-only access to admin + git repo. Snapshot of composer.json, installed extensions list, custom theme inventory.
• Day 3–5: per-extension Hyvä compatibility check. The Hyvä compatibility checker handles the easy 60%; the rest needs manual vendor research.
• Day 6–8: custom code inventory — theme overrides, custom modules, third-party integrations, custom checkout logic.
• Day 9–10: written audit document. Per-extension status, port-vs-replace decisions, hour estimates, risk register.

For mid-market and enterprise projects, this phase is the single most important. Skipping it adds 2–4 weeks of rework later because of late-discovered compatibility gaps.

Phase 2: theme rebuild and component port (2–6 weeks)

This is the longest phase. The Luma theme is replaced with a Hyvä theme using Tailwind CSS utility classes and Alpine.js for interactivity. Every page template, layout XML, and design token gets re-implemented.

Roughly how the hours break down on a mid-market store:

If your existing Luma theme has 5,000+ lines of bespoke LESS and 20+ KnockoutJS components, this phase doubles in duration. Knowing this up front is what the audit is for.

Phase 3: extension compatibility sweep (1–3 weeks)

Every third-party extension your store uses needs one of three treatments:

1. Native Hyvä support — the vendor ships a Hyvä-compatible version. Install, configure, smoke test. ~1–2h per extension.
2. Community compat module — someone wrote a Hyvä wrapper for the extension. Test thoroughly; quality varies. ~2–6h per extension.
3. Custom port — no vendor support, no community module. Write a Hyvä module yourself or replace with an alternative. ~8–40h per extension.

Average mid-market store has 8–12 extensions in bucket 3. That's where the 1–3 week range comes from. Stores that aggressively use one-of-a-kind admin extensions can spend an extra full week here.

Phase 4: QA, performance, and deploy (1–2 weeks)

The final phase. QA, performance benchmarking, staging signoff, DNS cutover, and post-launch monitoring.

• QA matrix: Chrome / Safari / Firefox, desktop + tablet + mobile, logged-in + guest, every payment method, every shipping method. Usually 2–3 days for a small store, 5–7 for mid-market.
• Performance benchmark: baseline Core Web Vitals on staging, target LCP < 2.5s mobile, INP < 200ms, CLS < 0.1. See the LCP / INP / CLS recipe for the specific Magento knobs.
• SEO migration QA: every URL still works, redirects in place, structured data preserved, hreflang correct, XML sitemap regenerated.
• Launch window: usually a weekend evening. DNS cutover, smoke tests, monitor for 4–6 hours.
• Post-launch: 14 days of daily monitoring for ranking dips, conversion changes, and bug reports. Included in every Hyvä theme development service engagement.

What makes a migration slow down

Five things explain why a 6-week project becomes a 12-week project:

1. Extension vendor delays. You request Hyvä support from a vendor; they say "next month"; the month becomes two. Mitigation: ask the audit phase to flag every vendor with no Hyvä roadmap.
2. Undocumented custom code. A previous developer wrote 800 lines of magic in a theme override file with no comments. Reverse-engineering it adds 20–60 hours.
3. Scope creep during the rebuild. Stakeholders see Hyvä and want a redesign at the same time. Combining the two doubles the timeline. Hard rule: redesign in a separate sprint after the Hyvä baseline ships.
4. QA bottleneck. Client team isn't available to sign off on staging for a week at a time. The fix is a defined sign-off SLA in the contract (48 hours per QA round).
5. Hosting/server problems discovered late. Old Magento server is undersized for the new asset pipeline. Mitigate by including a server-health check in the audit.

How to keep your timeline tight

Five tactics that reliably compress calendar time without compressing quality:

• Run the audit first, separately. A 2-week audit produces a defensible plan that prevents 6 weeks of mid-project re-scoping.
• Don't redesign during migration. Port the existing design pixel-close, then redesign in a separate sprint.
• Single point-of-contact on the client side. Multiple stakeholders means slow sign-off. One decision-maker compresses QA loops dramatically.
• Use Hyvä Checkout unless you have data showing your custom checkout drives conversion lift worth porting.
• Freeze new feature requests during the migration window. Anything new goes into the backlog for after launch.

If you want, I can run a free 20-minute scoping call and give you a realistic timeline for your specific store before you commit. Book it from the hire me page.

Frequently asked questions

What is the absolute minimum time for a Hyvä migration?

14 calendar days for the fixed-fee $2,499 sprint on a small store with under 20 extensions and minimal customisation. Below that, you're either using a default Hyvä theme as-is (no porting) or rushing QA. Honest floor is 2 weeks for any real migration.

Can Hyvä migration be done in parallel with other work?

Yes — most of my projects run alongside the client's normal development. The Luma site keeps running until the staging-to-production cutover. New features can be added to the Luma codebase during migration, but they need to be ported to Hyvä before launch. Easier to freeze features during migration if possible.

How long does the discovery audit take?

1–2 weeks for the standalone $499 audit. Output is a written report: per-extension compatibility matrix, custom-code inventory, line-itemised hour estimates, and a risk register. Audit cost rolls into the migration if you proceed within 30 days.

How long is the launch downtime?

Zero to 5 minutes on Magento Open Source with proper DNS pre-warming. On Adobe Commerce with blue-green deploy, zero downtime is standard. The 4–6 hour launch window is mostly monitoring, not downtime.

Do you migrate during business hours or off-hours?

Development happens during my working hours (India Standard Time, with global-client overlap). Production launch is scheduled at the client's lowest-traffic window — usually a weekend evening in the client's timezone.

What's the bottleneck — code or QA?

For small stores, code. For mid-market and enterprise, QA. Every additional stakeholder who needs to sign off adds 1–3 days to each QA round. Two QA rounds × 4 stakeholders × 3 days = 24 calendar days just for sign-offs. This is why a single decision-maker matters.

Can I see progress weekly?

Yes. Every project gets a staging URL from day 3, and I push updates daily. Weekly 30-minute sync call to review progress, demo new pages, and adjust scope. Slack/email access throughout for ad-hoc questions.

What happens if the timeline slips?

If a delay is on my side, my hours are capped at the original quote — you don't pay for my over-runs. If a delay is on the client side (slow sign-off, scope creep, late content), additional hours are billed at $25/hr with prior approval. This is in every contract.

Do you offer expedited timelines for extra cost?

Yes, for mid-market and enterprise. Bringing in a second senior Hyvä developer can compress a 10-week timeline to 6 weeks. Cost premium is roughly 15–25% because of coordination overhead, not 2× because two devs don't ship 2× faster.

How long until I see Core Web Vitals improvements?

Immediately at launch. Hyvä's frontend is fundamentally smaller and faster than Luma's — LCP typically drops 30–60% on mobile from day one. Field data in Search Console takes 28 days to catch up because of the rolling CrUX window.