How to migrate Magento Luma to Hyvä in 8 weeks
An 8-week Hyvä migration is the realistic baseline for a clean Magento Luma store — 8 to 15 paid extensions, no major B2B features, faithful design rebuild rather than a rebrand. Stores outside that profile take longer.
This post is the week-by-week plan we use, the milestones that decide whether you land on time, and the things that derail an 8-week timeline into a 14-week one.
Pre-flight: before week 1
Two things have to be true before week 1 starts:
Extension inventory complete. Every paid module on the store, with vendor + version + license status. We use this list to decide which extensions have vendor-supplied Hyvä compat (free) vs need a custom compatibility module (paid). Without it, scoping is guessing.
Magento on a Hyvä-supported version. If you're on Magento Open Source 2.4.4 or earlier, the upgrade comes first. Don't combine Magento major-version upgrades with Hyvä migration — that's two risky changes in one window.
Pre-flight is usually a 1-week window before the engagement officially starts. We do it during the scoping period so kickoff isn't loaded with admin.
Week 1 — foundation
Goal: Hyvä Theme installed, brand-system Tailwind config done, design-system component library exists.
What ships:
- Hyvä Theme package installed in your dev environment
- Tailwind config matching your brand: colour tokens, typography scale, spacing, radii
- Base component library (button, card, badge, form input, modal) styled to your brand
- Header, footer, navigation, breadcrumb templates
- A staging URL where you can see the bones of the new site
Milestone: End of week 1, the homepage renders under Hyvä with your brand. No products yet, no checkout, but the visual identity is in place.
Weeks 2–3 — page templates
Goal: Every storefront page template re-platformed onto Hyvä.
What ships:
- Product Detail Page (PDP) — image gallery, variant selector, price block, add-to-cart, related products, reviews, FAQ
- Product Listing Page (PLP) — filters, sorting, pagination, infinite scroll if applicable
- Search results
- Cart page
- Customer account section (dashboard, orders, addresses, wishlists, returns)
- CMS blocks and content pages
Milestone: End of week 3, you can browse the staging site as a customer would. Every page renders. Add to cart works. Login works. Account dashboard works.
The PDP usually takes the longest because of variants, image galleries, and the long tail of merchandising blocks (related products, recently viewed, FAQs, reviews). Budget 3–5 days on PDP alone.
Weeks 4–5 — extension compatibility
Goal: Every paid extension on the store renders correctly under Hyvä.
What ships:
- Vendor-supplied Hyvä compat modules installed for extensions that ship them
- Custom Hyvä compatibility modules written for extensions without vendor compat
- Each extension tested in context — banners showing, badges rendering, product feeds firing
Extensions split into three groups:
- Vendor compat available — composer require + config flip. 30 minutes per extension.
- Custom compat needed (display-only) — banners, badges, content blocks. 1–3 days each.
- Custom compat needed (checkout/cart-touching) — payment, fraud, shipping. 3–7 days each, plus order-flow testing.
The variance here is enormous. A clean store with all-vendor-compat extensions can finish this phase in 3 days. A store with 15 extensions needing custom compat is the full 2 weeks.
Milestone: End of week 5, every extension on the live site has a working equivalent on staging. You should be able to do an end-to-end purchase including any third-party payment, shipping, or fraud module.
Week 6 — performance tuning
Goal: Mobile Lighthouse Performance at 90+, with no regressions on accessibility or best practices.
What changes:
- LCP optimisation: critical CSS inlining, font preload, hero image priority
- JS budget: tree-shaking, lazy-loading anything below the fold
- Third-party script audit: GA, Meta pixel, chat widgets — these are the biggest LCP killers
- Image optimisation: WebP/AVIF, responsive
srcset, lazy-load images below fold - Server response time (TTFB): Magento config tuning if needed
Milestone: End of week 6, mobile Lighthouse on PDP and PLP both score 90+. If they don't, the cutover date is at risk.
Week 7 — UAT on staging
Goal: Real orders end-to-end, with your team and (optionally) selected real customers.
What happens:
- Your team runs through every key flow: browse, search, PDP, add to cart, checkout (real card), customer login, account dashboard, contact us
- We run cross-browser QA on iOS Safari, Android Chrome, desktop Chrome, Firefox, Edge
- Accessibility pass: keyboard navigation, screen reader, contrast
- Schema.org structured data validated via Rich Results Test (Product, Offer, Breadcrumb, FAQPage)
- 301 redirect plan finalised for any URL that's changed
- Bug-bash session: 1-hour everyone-on-Zoom session where 5+ people try to break the staging site
Milestone: End of week 7, the bug list is closed and you sign off on cutover.
Week 8 — cutover + post-launch
Goal: Hyvä live in production with zero downtime, monitored for 72 hours.
What happens:
- Cutover window: Sunday 02:00 UK time by default. 30–60 minutes of maintenance. DNS flip, cache flush, final order sync.
- Post-launch monitoring: Sentry dashboard open for 72 hours. Order completion rate watched against baseline. Search Console monitored for crawl errors.
- Bug-fix sprint: 5-day reactive window for anything that surfaces in the first week of real traffic. Usually 2–5 small issues; never a fundamental rebuild.
- Handover doc: Theme config, custom modules, deploy runbook, and a "what changed" reference for your in-house team.
Milestone: End of week 8, you have a live Hyvä site, a clean Sentry dashboard, and conversion rate at or above the Luma baseline.
What derails an 8-week timeline
In rough order of frequency:
Extension list grows mid-project. New paid module discovered in week 4 = 1–3 weeks added. Avoid by doing the inventory thoroughly before kickoff.
Design scope creep. "While we're at it, can we redesign the PDP?" = 2 weeks added. Either commit to the rebrand at scoping or save it for next year.
Magento version upgrade combined. Upgrading Magento 2.4.4 → 2.4.7 + migrating to Hyvä in the same window doubles risk and adds 3–4 weeks. Don't.
Staging environment not ready at kickoff. If we can't deploy on day 1 of week 1, every day of delay slips the cutover date 1-for-1. Stand up staging during pre-flight.
Stakeholder review slow. 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.
When 8 weeks isn't realistic
Be honest with yourself if any of these apply — you need 10–14 weeks, not 8:
- 25+ paid extensions
- B2B Commerce features (company accounts, shared catalogues, custom pricing, quotes)
- Heavily customised checkout flow (split checkout, B2B approvals, complex shipping rate calc)
- Hyvä Commerce scope (not just Hyvä Theme) — Hyvä Checkout adds 2–3 weeks
- Brand rebrand bolted onto the migration
- Multi-store / multi-website Magento setup with >2 storefronts
For these, we quote 10–14 weeks upfront. 8 weeks gets you a half-finished site live; nobody wins.
Next steps
- See the Hyvä migration service page for what's included
- Read the migration cost breakdown for line-item pricing
- Check the Hyvä migration checklist — 47 items to confirm before kickoff
- Book a 30-minute scoping call to get a fixed-price, fixed-timeline quote