Comment migrer Magento Luma vers Hyvä en 8 semaines
Une migration Hyvä de 8 semaines est la base réaliste pour un magasin Magento Luma propre, avec 8 à 15 extensions payantes, sans fonctionnalités B2B majeures, reconstruction fidèle du design plutôt qu'un rebranding. Les magasins en dehors de ce profil prennent plus de temps.
Cet article présente le plan semaine par semaine que nous utilisons, les étapes qui décident si vous respectez les délais, et les éléments qui peuvent faire passer un calendrier de 8 semaines à 14 semaines.
Pré-vol : avant la semaine 1
Deux choses doivent être vraies avant le début de la semaine 1 :
Inventaire des extensions complet. Chaque module payant sur le magasin, avec fournisseur + version + statut de licence. Nous utilisons cette liste pour décider quelles extensions ont une compatibilité Hyvä fournie par le fournisseur (gratuite) ou nécessitent un module de compatibilité personnalisé (payant). Sans cela, le périmètre est une devinette.
Magento sur une version supportée par Hyvä. Si vous êtes sur Magento Open Source 2.4.4 ou antérieur, la mise à niveau vient en premier. Ne combinez pas les mises à niveau de version majeure de Magento avec la migration vers Hyvä, cela représente deux changements risqués en une seule fenêtre.
Le pré-vol est généralement une fenêtre de 1 semaine avant le début officiel de l'engagement. Nous le faisons pendant la période de définition du périmètre afin que le lancement ne soit pas chargé d'administration.
Semaine 1, fondation
Objectif : Thème Hyvä installé, configuration du système de marque Tailwind terminée, bibliothèque de composants du système de design existante.
Ce qui est livré :
- Paquet de thème Hyvä installé dans votre environnement de développement
- Configuration Tailwind correspondant à votre marque : tokens de couleur, échelle typographique, espacement, rayons
- Bibliothèque de composants de base (bouton, carte, badge, champ de formulaire, modal) stylisée selon votre marque
- Modèles d'en-tête, de pied de page, de navigation, de fil d'Ariane
- Une URL de staging où vous pouvez voir les bases du nouveau site
Étape : À la fin de la semaine 1, la page d'accueil s'affiche sous Hyvä avec votre marque. Pas encore de produits, pas de paiement, mais l'identité visuelle est en place.
Semaines 2–3, modèles de page
Objectif : Chaque modèle de page de la vitrine migré vers Hyvä.
Ce qui est livré :
- Page de Détails du Produit (PDP), galerie d'images, sélecteur de variantes, bloc de prix, ajouter au panier, produits associés, avis, FAQ
- Page de Liste des Produits (PLP), filtres, tri, pagination, défilement infini si applicable
- Résultats de recherche
- Page du panier
- Section compte client (tableau de bord, commandes, adresses, listes de souhaits, retours)
- Blocs CMS et pages de contenu
Étape : À la fin de la semaine 3, vous pouvez naviguer sur le site de staging comme un client le ferait. Chaque page s'affiche. Ajouter au panier fonctionne. La connexion fonctionne. Le tableau de bord du compte fonctionne.
La PDP prend généralement le plus de temps en raison des variantes, des galeries d'images et de la longue traîne des blocs de merchandising (produits associés, récemment vus, FAQ, avis). Prévoyez 3 à 5 jours uniquement pour la PDP.
Semaines 4–5, compatibilité des extensions
Objectif : Chaque extension payante sur le magasin s'affiche correctement sous Hyvä.
Ce qui est livré :
- Modules de compatibilité Hyvä fournis par le fournisseur installés pour les extensions qui les livrent
- Modules de compatibilité Hyvä personnalisés écrits pour les extensions sans compatibilité fournisseur
- Chaque extension testée dans le contexte, bannières affichées, badges rendus, flux de produits actifs
Les extensions sont réparties en trois groupes :
- Compatibilité fournisseur disponible, composer require + config flip. 30 minutes par extension.
- Compatibilité personnalisée nécessaire (affichage uniquement), bannières, badges, blocs de contenu. 1 à 3 jours chacun.
- Compatibilité personnalisée nécessaire (touchant au paiement/au panier), paiement, fraude, expédition. 3 à 7 jours chacun, plus tests de flux de commande.
La variance ici est énorme. Un magasin propre avec toutes les extensions compatibles fournisseur peut terminer cette phase en 3 jours. Un magasin avec 15 extensions nécessitant une compatibilité personnalisée prend les 2 semaines complètes.
Étape : À la fin de la semaine 5, chaque extension sur le site en direct a un équivalent fonctionnel sur le staging. Vous devriez être en mesure de réaliser un achat de bout en bout, y compris tout module de paiement, d'expédition ou de fraude tiers.
Semaine 6, optimisation des performances
Objectif : Performance Mobile Lighthouse à 90+, sans régressions sur l'accessibilité ou les meilleures pratiques.
Ce qui change :
- Optimisation LCP : inlining CSS critique, préchargement de police, priorité de l'image héro
- Budget JS : tree-shaking, chargement paresseux de tout ce qui est en dessous de la ligne de flottaison
- Audit des scripts tiers : GA, pixel Meta, widgets de chat, ce sont les plus grands tueurs de LCP
- Optimisation des images : WebP/AVIF,
srcsetréactif, chargement paresseux des images en dessous de la ligne de flottaison - Temps de réponse du serveur (TTFB) : réglage de la configuration Magento si nécessaire
Étape : À la fin de la semaine 6, Mobile Lighthouse sur PDP et PLP obtient tous les deux un score de 90+. S'ils ne le font pas, la date de basculement est en danger.
Semaine 7, UAT sur staging
Objectif : Réelles commandes de bout en bout, avec votre équipe et (optionnellement) des clients réels sélectionnés.
Ce qui se passe :
- Votre équipe passe en revue chaque flux clé : navigation, recherche, PDP, ajout au panier, paiement (carte réelle), connexion client, tableau de bord du compte, contactez-nous
- Nous effectuons un QA multi-navigateur sur iOS Safari, Android Chrome, desktop Chrome, Firefox, Edge
- Passation d'accessibilité : navigation au clavier, lecteur d'écran, contraste
- Données structurées Schema.org validées via le Test des Résultats Riches (Produit, Offre, Fil d'Ariane, FAQPage)
- Plan de redirection 301 finalisé pour toute URL qui a changé
- Session de correction de bogues : session de 1 heure sur Zoom où 5+ personnes essaient de casser le site de staging
Étape : À la fin de la semaine 7, la liste des bogues est close et vous validez le basculement.
Semaine 8, basculement + post-lancement
Objectif : Hyvä en production avec zéro temps d'arrêt, surveillé pendant 72 heures.
Ce qui se passe :
- Fenêtre de basculement : Dimanche 02:00 heure du Royaume-Uni par défaut. 30 à 60 minutes de maintenance. Basculement DNS, vidage du cache, synchronisation finale des commandes.
- Surveillance post-lancement : Tableau de bord Sentry ouvert pendant 72 heures. Taux de complétion des commandes surveillé par rapport à la base de référence. Search Console surveillé pour les erreurs de crawl.
- Sprint de correction de bogues : Fenêtre réactive de 5 jours pour tout ce qui apparaît dans la première semaine de trafic réel. En général, 2 à 5 petits problèmes ; jamais une reconstruction fondamentale.
- Document de passation : Configuration du thème, modules personnalisés, manuel de déploiement, et une référence "qu'est-ce qui a changé" pour votre équipe interne.
Étape : À la fin de la semaine 8, vous avez un site Hyvä en direct, un tableau de bord Sentry propre, et un taux de conversion égal ou supérieur à la base de référence de Luma.
Ce qui fait dérailler un calendrier de 8 semaines
Dans un ordre approximatif de fréquence :
La liste des extensions s'allonge en cours de projet. Nouveau module payant découvert en semaine 4 = 1 à 3 semaines ajoutées. Évitez cela en faisant l'inventaire de manière approfondie avant le lancement.
Dérive du périmètre de design. "Tant qu'on y est, peut-on redesign la PDP ?" = 2 semaines ajoutées. Engagez-vous soit à la refonte lors de la définition du périmètre, soit réservez cela pour l'année prochaine.
Mise à niveau de version Magento combinée. Mise à niveau de Magento 2.4.4 → 2.4.7 + migration vers Hyvä dans la même fenêtre double le risque et ajoute 3 à 4 semaines. Ne le faites pas.
Environnement de staging pas prêt au lancement. Si nous ne pouvons pas déployer le jour 1 de la semaine 1, chaque jour de retard repousse la date de basculement 1 pour 1. Mettez en place le staging pendant le pré-vol.
Examen des parties prenantes lent. La semaine UAT suppose que votre équipe peut consacrer du temps à tester. Si le retour prend 5 jours ouvrables, cela repousse le basculement de 5 jours.
Quand 8 semaines n'est pas réaliste
Soyez honnête avec vous-même si l'un de ces points s'applique, vous avez besoin de 10 à 14 semaines, pas 8 :
- 25+ extensions payantes
- Fonctionnalités B2B Commerce (comptes d'entreprise, catalogues partagés, tarification personnalisée, devis)
- Flux de paiement lourdement personnalisés (paiement fractionné, approbations B2B, calcul complexe des frais d'expédition)
- Périmètre Hyvä Commerce (pas seulement Hyvä Theme), Hyvä Checkout ajoute 2 à 3 semaines
- Rebranding de marque ajouté à la migration
- Configuration Magento multi-boutique / multi-site avec >2 vitrines
Pour ces cas, nous proposons 10 à 14 semaines dès le départ. 8 semaines vous donnent un site à moitié terminé en ligne ; personne ne gagne.
Prochaines étapes
- Consultez la page de service de migration Hyvä pour ce qui est inclus
- Lisez le détail des coûts de migration pour le prix par ligne
- Vérifiez la liste de contrôle de migration Hyvä, 47 éléments à confirmer avant le lancement
- Réservez un appel de définition de périmètre de 30 minutes pour obtenir un devis à prix fixe et à délai fixe