La liste de contrôle de migration Hyvä : 47 éléments avant de commencer

Les projets de migration Hyvä qui prennent du temps ou dépassent le budget sont presque toujours dus à quelque chose qui a été négligé lors de la définition du périmètre. Cette liste de contrôle contient les 47 éléments que nous passons en revue avec chaque commerçant avant le décollage. La parcourir une fois prend 2 à 3 heures et permet d'éviter 90 % des imprévus en cours de projet.

Utilisez-la avant de signer un périmètre de migration Hyvä. Apportez-la à l'agence que vous envisagez et passez-la en revue ensemble.

Section A : Environnement Magento (éléments 1 à 8)

1. Version de Magento confirmée (par exemple, Magento Open Source 2.4.6, Adobe Commerce 2.4.7). Hyvä prend en charge des versions spécifiques ; si vous utilisez une version plus ancienne, prévoyez d'abord une mise à niveau de Magento.

2. Version PHP prise en charge par Hyvä. Hyvä prend généralement en charge PHP 8.1+ selon la version de Magento. Confirmez que votre hébergement correspond.

3. Environnement d'hébergement prêt pour la mise en scène. Un environnement de mise en scène séparé (correspondant à la configuration de production + données récentes) est non négociable. Le travail de migration se fait ici avant le basculement.

4. Données de production récemment actualisées pour la mise en scène. Les données de mise en scène de plus de 30 jours feront apparaître des différences par rapport à la production lors de l'UAT. Actualisez avant le lancement.

5. Authentification Composer fonctionnelle pour Magento + fournisseurs privés. Confirmez que composer install s'exécute sans erreur sur la mise en scène. Les problèmes d'authentification en cours de projet bloquent le déploiement.

6. Espace disque + mémoire suffisants sur la mise en scène pour l'installation de Hyvä. Les actifs compilés de Hyvä augmentent l'utilisation du disque ; vérifiez que la mise en scène peut le gérer.

7. Procédure de sauvegarde de la base de données documentée. Confirmez que vous pouvez revenir en arrière sur la base de données si quelque chose tourne catastrophiquement mal lors du basculement.

8. Flux de travail en mode maintenance testé. Confirmez que l'activation/désactivation du mode maintenance fonctionne comme prévu, c'est le mécanisme du jour du basculement.

Section B : Inventaire des extensions (éléments 9 à 18)

9. Liste complète des extensions documentée. Nom du fournisseur + nom de l'extension + version + statut de la licence pour chaque extension payante. Récupérez à partir de composer.json + composer.lock.

10. Extensions installées par ZIP identifiées séparément. Tout ce qui se trouve dans app/code/* et qui n'a pas été livré via Composer. Souvent les plus difficiles à migrer.

11. Extensions personnalisées en interne identifiées. Tout ce qui a été écrit par votre ancienne équipe de développement et qui touche l'interface utilisateur.

12. Chaque extension vérifiée sur compat.hyva.io. Statut noté : Compatible (compatibilité fournisseur) / Solution de contournement (compatibilité communautaire) / Non compatible / Inconnu.

13. Versions des modules de compatibilité fournisseur vérifiées. Un fournisseur qui expédie la compatibilité Hyvä pour la version actuelle de l'extension peut ne pas le faire pour votre version plus ancienne. Vérifiez par extension.

14. Extensions identifiées comme "à ignorer plutôt qu'à migrer". Extensions abandonnées, extensions redondantes, extensions prévues pour remplacement, signalées afin que nous ne payions pas pour une compatibilité que nous n'utiliserons pas.

15. Validité de la licence confirmée pour chaque extension payante. L'installation de Composer nécessite des licences valides ; celles qui ont expiré bloquent le déploiement.

16. Extensions qui s'intègrent au processus de paiement signalées pour un contrôle qualité supplémentaire. Paiement, fraude, expédition, cartes-cadeaux, crédit magasin, celles-ci nécessitent des tests complets du flux de commande.

17. Modifications de thème personnalisées inventoriées. Tout ce que votre ancienne équipe de développement a personnalisé dans le thème Luma qui doit être reproduit sous Hyvä.

18. Dépendances de chaînes magiques / de gestionnaires d'événements notées. Certaines extensions dépendent de noms d'événements spécifiques ou de chaînes magiques, celles-ci doivent être transférées dans les modules de compatibilité Hyvä.

Section C : Contenu + structure d'URL (éléments 19 à 26)

19. Structure d'URL documentée. Chaque URL de PDP, PLP, page CMS notée. Les URL qui ne changeront pas vérifiées.

20. URLs qui vont changer identifiées. Celles qui changent doivent avoir des redirections 301 en place lors du basculement.

21. Table des réécritures d'URL sauvegardée. La table url_rewrite de Magento est critique pour le SEO ; sauvegardez-la avant le basculement.

22. Données structurées (Produit, Offre, Fil d'Ariane, FAQPage) vérifiées sur le site existant. Tout ce qui est présent maintenant doit être transféré vers Hyvä.

23. Marquage Schema.org actuellement présent sur PDP catalogué. Spécifiquement : Produit, Offre, Évaluation agrégée, Avis, FAQPage. Confirmez que tout est transféré.

24. Contenu CMS inventorié. Pages statiques, blocs CMS, bannières, blocs de contenu dynamique, tous ont besoin de leurs équivalents Hyvä.

25. Métadonnées SEO confirmées par type de page. Balises de titre, méta descriptions, balises canoniques, hreflang pour le multilingue.

26. État actuel du sitemap et robots.txt documenté. Le basculement ne change pas ces éléments, mais les examiner est une bonne idée.

Section D : Base de référence de performance (éléments 27 à 32)

27. Score de performance Mobile Lighthouse enregistré pour PDP, PLP, recherche, panier, paiement. C'est votre base de référence avant de mesurer l'amélioration.

28. Statut des Core Web Vitals enregistré depuis Search Console. Statut actuel Bon / À améliorer / Mauvais par groupe d'URL.

29. Poids de page actuel mesuré. Poids HTML, JS, CSS, image par type de page clé.

30. Inventaire des balises tierces. Balises GTM, scripts d'analyse, widgets de chat, pixels marketing, tout ce qui est chargé depuis des domaines non propriétaires.

31. Taux de conversion mobile actuel capturé. Spécifiquement : taux d'ajout au panier mobile et taux de finalisation de paiement mobile. Les chiffres après sont comment vous mesurerez le ROI.

32. Taux de conversion desktop actuel capturé. En comparaison ; l'augmentation sera plus faible sur desktop que sur mobile.

Section E : Design + UX (éléments 33 à 38)

33. Intention de design confirmée : reconstruction fidèle vs rebranding vs nouvelle direction. C'est le plus grand risque de dérive de périmètre ; verrouillez-le lors de la définition du périmètre.

34. Tokens de marque documentés. Couleurs, typographie, espacement, rayons de bordure. Ceux-ci alimentent la configuration de Tailwind.

35. Attentes de la bibliothèque de composants définies. Styles de boutons, styles de formulaires, styles de cartes, existent-ils ? Ont-ils besoin d'être conçus ? Utiliser les valeurs par défaut de Hyvä ?

36. Blocs de merchandising PDP inventoriés. Produits connexes, récemment vus, ventes incitatives, ventes croisées, accordéon FAQ, avis, tout cela est transféré ?

37. Exigences de la section compte client confirmées. Compte Magento standard ou personnalisé ? Abonnements, cartes-cadeaux, retours ?

38. Exigences UX spécifiques aux mobiles notées. Ajout au panier collant, mini-panier mobile, comportement de filtre mobile.

Section F : Fonctionnalités B2B / Adobe Commerce (éléments 39 à 43)

(Sauter cette section si Magento Open Source B2C.)

39. Fonctionnalités B2B en cours cataloguées. Comptes d'entreprise, catalogues partagés, tarification spécifique aux clients, devis, listes de réquisition, flux de travail d'approbation, tous nécessitent un nouveau modèle.

40. Visibilité du catalogue segmenté par client confirmée. Quels segments voient quels produits / catégories ?

41. Logique de tarification spécifique au client documentée. Niveaux de prix, tarification contractuelle, remises sur quantité, tous doivent s'afficher correctement par client connecté.

42. Seuils de flux de travail d'approbation documentés. Quelles commandes nécessitent une approbation, qui approuve, comment fonctionne la notification.

43. Attributs PDP spécifiques au B2B notés. Fiches techniques, certifications, délais de livraison, tarification en gros.

Section G : Parties prenantes + gestion de projet (éléments 44 à 47)

44. Fenêtres de révision des parties prenantes réservées. La semaine UAT nécessite le calendrier de votre équipe. Réservez-le avant le lancement.

45. Fenêtre de basculement confirmée. Week-end hors pointe, pas d'événements de vente, pas de campagnes marketing en concurrence pour le trafic.

46. Ressource de suivi post-lancement confirmée. Quelqu'un de votre côté disponible pendant 72 heures après le basculement pour détecter les problèmes.

47. Autorité de validation confirmée. Qui a l'autorité pour approuver les changements de périmètre, l'achèvement de l'UAT, le go/no-go du basculement ? Une personne nommée est préférable.

Que faire avec cette liste

1. Passez en revue avant de demander des devis de périmètre. Plus d'éléments vous pouvez répondre "oui / documenté / confirmé" avant de parler aux agences, plus vite et moins cher sera votre périmètre.

2. Apportez-la à votre liste restreinte d'agences Hyvä. Faites-les travailler avec vous. Les agences qui s'engagent à fond avec la liste de contrôle montrent qu'elles comprennent la migration ; les agences qui la survolent montrent qu'elles ne le font pas.

3. Référez-vous à elle lors du lancement. Avant que tout travail commence, chaque élément de la liste de contrôle doit avoir une réponse confirmée. Les éléments ouverts au lancement deviennent des problèmes d'ici la semaine 4.

4. Utilisez-la pour le post-mortem. Lorsque quelque chose tourne mal, retracez quel élément de la liste de contrôle a échoué. Mettez à jour la liste de contrôle pour la prochaine fois.

Ce que cette liste de contrôle ne couvre pas

Quelques éléments que la liste de contrôle n'inclut délibérément pas car ils sont trop spécifiques au projet :

• Exigences spécifiques de fonctionnalités personnalisées (configurateurs, visionneuses AR, recherche personnalisée), celles-ci nécessitent leurs propres documents de périmètre
• Coordination de campagne marketing, votre équipe marketing en est responsable
• Plan de communication avec les clients concernant le basculement, généralement inutile si le basculement se déroule sans accroc
• Feuille de route Hyvä à long terme (quand ajouter le paiement, quand ajouter l'administration), parlez de la phase 2 après la phase 1

Si votre périmètre inclut l'un de ces éléments, construisez des documents de périmètre détaillés séparés pour eux en plus de cette liste de contrôle de base.

Pourquoi 47 ?

Ce n'est pas un nombre magique. La liste a grandi au fil des ans à mesure que nous avons appris quels éléments les surprises en cours de projet étaient liées. Elle compte actuellement 47 éléments ; elle devrait probablement passer à 52 dans les deux prochaines années à mesure que de nouveaux cas particuliers émergent.

Le point n'est pas le nombre ; c'est d'avoir une liste complète que vous parcourez une fois plutôt que de découvrir des éléments à la semaine 5 de la construction.

Prochaines étapes

• Consultez la page de service de migration Hyvä pour le processus complet
• Lisez Comment migrer Magento Luma vers Hyvä en 8 semaines pour une répartition semaine par semaine
• Lisez Coût de migration Hyvä en 2026 pour le cadre de coût
• Réservez un appel de définition de périmètre, nous passerons en revue cette liste de contrôle ensemble