The Hyvä migration checklist: 47 items before you start

Hyvä migration projects that run long or over-budget almost always trace back to something missed at scoping. This checklist is the 47 items we run through with every merchant during pre-flight. Working through it once takes 2–3 hours and prevents 90% of mid-project blindsides.

Use it before signing a Hyvä migration scope. Take it to whichever agency you're considering and run through it together.

Section A: Magento environment (items 1–8)

1. Magento version confirmed (e.g. Magento Open Source 2.4.6, Adobe Commerce 2.4.7). Hyvä supports specific versions; if you're on an older version, plan a Magento upgrade first.

2. PHP version is Hyvä-supported. Hyvä typically supports PHP 8.1+ depending on Magento version. Confirm your hosting matches.

3. Hosting environment ready for staging. A separate staging environment (matching production config + recent data) is non-negotiable. Migration work happens here before cutover.

4. Production data refreshed to staging recently. Staging data older than 30 days will surface differences vs production at UAT. Refresh before kickoff.

5. Composer authentication working for Magento + private vendors. Confirm composer install runs clean on staging. Auth issues mid-project block deployment.

6. Sufficient disk + memory on staging for Hyvä install. Hyvä's compiled assets add to disk usage; verify staging can handle it.

7. Database backup procedure documented. Confirm you can roll back the database if anything goes catastrophically wrong during cutover.

8. Maintenance-mode workflow tested. Confirm enabling/disabling maintenance mode works as expected — this is the cutover-day mechanism.

Section B: Extension inventory (items 9–18)

9. Full extension list documented. Vendor + extension name + version + license status for every paid extension. Pull from composer.json + composer.lock.

10. ZIP-installed extensions identified separately. Anything in app/code/* not delivered via Composer. Often the trickiest to migrate.

11. Custom in-house extensions identified. Anything written by your previous dev team that touches the frontend.

12. Each extension checked against compat.hyva.io. Status noted: Compatible (vendor compat) / Workaround (community compat) / Not Compatible / Unknown.

13. Vendor compat module versions verified. A vendor that ships Hyvä compat for the current extension version may not for your older version. Verify per-extension.

14. Extensions identified as "skip rather than migrate". Abandoned extensions, redundant extensions, extensions slated for replacement — flagged so we don't pay for compat we won't use.

15. License validity confirmed for each paid extension. Composer install needs valid licenses; expired ones block deployment.

16. Extensions that hook into checkout flagged for extra QA. Payment, fraud, shipping, gift cards, store credit — these need full order-flow testing.

17. Custom theme modifications inventoried. Anything your previous dev team customised in the Luma theme that needs replicating under Hyvä.

18. Magic-string / event-dispatcher dependencies noted. Some extensions depend on specific event names or magic strings — these need to carry over in the Hyvä compat modules.

Section C: Content + URL structure (items 19–26)

19. URL structure documented. Every PDP, PLP, CMS page URL noted. URLs that won't change verified.

20. URLs that will change identified. Any that do change need 301 redirects in place at cutover.

21. URL rewrites table backed up. Magento's url_rewrite table is critical for SEO; back it up before cutover.

22. Structured data (Product, Offer, Breadcrumb, FAQPage) verified on existing site. Whatever's there now needs to carry over to Hyvä.

23. Schema.org markup currently present on PDP cataloged. Specifically: Product, Offer, AggregateRating, Review, FAQPage. Confirm all carry over.

24. CMS content inventoried. Static pages, CMS blocks, banners, dynamic content blocks — all need their Hyvä equivalents.

25. SEO meta data confirmed per page type. Title tags, meta descriptions, canonical tags, hreflang for multi-language.

26. Sitemap and robots.txt current state documented. Cutover doesn't change these but reviewing them is a good time.

Section D: Performance baseline (items 27–32)

27. Mobile Lighthouse Performance score recorded for PDP, PLP, search, cart, checkout. This is your before-baseline for measuring improvement.

28. Core Web Vitals status from Search Console recorded. Current Good/Needs Improvement/Poor status per URL group.

29. Current page weight measured. HTML, JS, CSS, image weight per key page type.

30. Third-party tag inventory. GTM tags, analytics scripts, chat widgets, marketing pixels — anything loaded from non-first-party domains.

31. Current mobile conversion rate captured. Specifically: mobile cart-add rate and mobile checkout-completion rate. The after-numbers are how you'll measure ROI.

32. Current desktop conversion rate captured. As a comparison; lift will be smaller on desktop than mobile.

Section E: Design + UX (items 33–38)

33. Design intent confirmed: faithful rebuild vs rebrand vs new direction. This is the single biggest scope-creep risk; lock it at scoping.

34. Brand tokens documented. Colours, typography, spacing, border radii. These feed into the Tailwind config.

35. Component-library expectations set. Button styles, form styles, card styles — do they exist? Need designing? Use Hyvä defaults?

36. PDP merchandising blocks inventoried. Related products, recently viewed, upsells, cross-sells, FAQ accordion, reviews — all carry over?

37. Customer-account section requirements confirmed. Stock Magento account or customised? Subscriptions, gift cards, returns?

38. Mobile-specific UX requirements noted. Sticky add-to-cart, mobile mini-cart, mobile filter behaviour.

Section F: B2B / Adobe Commerce features (items 39–43)

(Skip this section if Magento Open Source B2C.)

39. B2B features in use cataloged. Company accounts, shared catalogues, customer-specific pricing, quotes, requisition lists, approval workflows — all need re-templating.

40. Customer-segmented catalogue visibility confirmed. Which segments see which products / categories?

41. Customer-specific pricing logic documented. Pricing tiers, contract pricing, quantity breaks — all need to render correctly per logged-in customer.

42. Approval workflow thresholds documented. Which orders need approval, who approves, how notification works.

43. B2B-specific PDP attributes noted. Datasheets, certifications, lead times, bulk-pack pricing.

Section G: Stakeholder + project management (items 44–47)

44. Stakeholder review windows booked. UAT week needs your team's calendar. Book it before kickoff.

45. Cutover window confirmed. Off-peak weekend, no sale events, no marketing campaigns competing for traffic.

46. Post-launch monitoring resource confirmed. Someone on your side available for 72 hours post-cutover to catch issues.

47. Sign-off authority confirmed. Who has authority to sign off scope changes, UAT completion, cutover go/no-go? Single named person preferred.

What to do with this list

1. Run through it before requesting scoping quotes. The more items you can answer "yes / documented / confirmed" before talking to agencies, the faster + cheaper your scoping will be.

2. Take it to your shortlist of Hyvä agencies. Have them work through it with you. Agencies that engage thoroughly with the checklist are showing they understand migration; agencies that hand-wave through it are showing they don't.

3. Reference it at kickoff. Before any work starts, every checklist item should have a confirmed answer. Open items at kickoff become problems by week 4.

4. Use it for post-mortem. When something goes wrong, trace back to which checklist item failed. Updates the checklist for next time.

What this checklist doesn't cover

A few things the checklist deliberately doesn't include because they're too project-specific:

• Specific custom feature requirements (configurators, AR viewers, custom search) — these need their own scope docs
• Marketing campaign coordination — your marketing team owns this
• Communication plan with customers about the cutover — usually unnecessary if cutover is smooth
• Long-term Hyvä roadmap (when to add Checkout, when to add Admin) — talk about Phase 2 after Phase 1 ships

If your scope includes any of those, build separate detailed scope docs for them on top of this baseline checklist.

Why 47?

Not a magic number. The list grew over the years as we learned what items mid-project surprises traced back to. Currently sits at 47; will probably grow to 52 in the next two years as new edge cases emerge.

The point isn't the number; it's having a comprehensive list you run through once rather than discovering items in week 5 of build.

Next steps

• See the Hyvä Migration service page for the full process
• Read How to migrate Magento Luma to Hyvä in 8 weeks for week-by-week breakdown
• Read Hyvä migration cost in 2026 for cost framework
• Book a scoping call — we'll run through this checklist together