Combien de temps prend réellement une migration Hyvä ?

Une migration typique de Luma → Hyvä prend 6 à 10 semaines, du lancement à la mise en service. Hyvä Commerce (Thème + Paiement) se situe entre 10 et 14 semaines. Hyvä Enterprise sur Adobe Commerce avec toutes les fonctionnalités B2B atteint 14 à 16 semaines.

Ce sont des chiffres réalistes issus de nos 50+ dernières constructions Hyvä, et non des aspirations marketing. Voici ce qui les influence, d'où vient la variance et les dépassements honnêtes des pires cas.

Les délais principaux

Type de projet	Délai typique	Plage
Hyvä Thème uniquement (petite boutique, 5 à 10 extensions)	6 semaines	5 à 8 semaines
Hyvä Thème (moyenne boutique, 15 à 25 extensions)	8 semaines	7 à 10 semaines
Hyvä Thème (grande boutique, 25+ extensions)	10 semaines	9 à 12 semaines
Hyvä Commerce (Thème + Paiement)	12 semaines	10 à 14 semaines
Hyvä Enterprise (Adobe Commerce B2B)	14 semaines	12 à 16 semaines
Hyvä Paiement autonome sur un Thème Hyvä existant	3 semaines	2 à 4 semaines
Hyvä Paiement autonome sur Luma	4 semaines	3 à 5 semaines
Module de compatibilité Hyvä personnalisé par extension	2 semaines	1 à 3 semaines

Ce qui influence le calendrier

Dans un ordre approximatif d'impact :

1. Nombre d'extensions payantes

C'est la variable la plus importante. Chaque extension payante sur la boutique nécessite un module de compatibilité Hyvä avant que son interface ne s'affiche correctement. De nombreux fournisseurs livrent le leur ; les autres nécessitent une compatibilité personnalisée.

Impact sur le calendrier : chaque extension de compatibilité personnalisée ajoute 3 à 10 jours. Une boutique propre avec 5 extensions compatibles de fournisseurs fonctionne rapidement ; une boutique avec 25 extensions mixtes ajoute 4 à 6 semaines.

2. Hyvä Commerce vs Hyvä Thème

Le Hyvä Thème seul couvre la vitrine. Ajouter Hyvä Paiement (avec intégration des modules de paiement + expédition + fraude) ajoute 2 à 4 semaines. Ajouter Hyvä Admin + Insights ajoute 1 à 2 semaines.

3. Portée des fonctionnalités B2B (Adobe Commerce)

Chaque fonctionnalité B2B d'Adobe Commerce (comptes d'entreprise, catalogues partagés, tarification client, devis, approbations) est une surface de modèle Hyvä distincte. Une portée B2B complète ajoute 4 à 6 semaines.

4. Fidélité au design vs rebranding

Une reconstruction fidèle de Luma → Hyvä correspond au design existant sous la nouvelle couche de rendu. Un rafraîchissement de marque ajouté ajoute 2 à 3 semaines d'itération de design + développement. Engagez-vous soit pour le rebranding lors de la définition du projet, soit conservez-le pour l'année prochaine.

5. Magento multi-boutiques / multi-sites

Deux boutiques ne prennent pas 2 fois le temps d'une seule si le design + la fonctionnalité sont identiques. Cinq boutiques avec des variations spécifiques à chaque pays prennent facilement 3 fois le temps.

6. Complexité de la section des comptes clients

Le compte client standard de Magento est simple. Si vous avez ajouté des abonnements, des cartes-cadeaux, un crédit de boutique, un portail de retours, une expédition multi-adresses, chacun ajoute 2 à 5 jours.

7. Complexité du flux de paiement personnalisé

Méthodes d'expédition personnalisées, routage d'approbation B2B, personnalisations de paiement en plusieurs étapes, champs conditionnels par pays d'expédition, chacun ajoute du temps. Une forte personnalisation peut faire passer le Hyvä Paiement autonome de 3 semaines à 6.

La répartition standard de 8 semaines (migration uniquement Thème)

Pour une migration typique de Hyvä Thème pour une moyenne boutique :

• Semaine 1 : Fondation, installation du Thème Hyvä, configuration de la marque Tailwind, bibliothèque de composants du système de design, en-tête / pied de page / navigation
• Semaine 2-3 : Modèles de page, PDP, PLP, recherche, panier, compte client, blocs CMS
• Semaine 4-5 : Compatibilité des extensions, modules de compatibilité de fournisseurs + personnalisés
• Semaine 6 : Optimisation des performances, Lighthouse mobile 90+ comme critère de sortie
• Semaine 7 : UAT sur staging, commandes réelles de bout en bout, tests multi-navigateurs, accessibilité, chasse aux bugs
• Semaine 8 : Mise en service + surveillance post-lancement de 72 heures + sprint de correction de bugs

Chaque semaine a des jalons explicites que nous vérifions. Si nous manquons un jalon, la date de mise en service est repoussée, nous ne compressons pas les semaines suivantes pour récupérer.

La liste des "éléments qui perturbent un calendrier de 8 semaines"

Dans un ordre approximatif de fréquence, selon nos dossiers de projet :

1. La liste des extensions s'allonge en cours de projet (le plus courant)

Nouvelle extension payante découverte à la semaine 4 = 1 à 3 semaines ajoutées. Presque toujours évitable en effectuant un inventaire complet avant le lancement.

Atténuation : traiter l'inventaire des extensions comme une condition préalable avant que la portée ne soit finalisée. Ne commencez pas le travail de construction sans qu'il soit verrouillé.

2. Élargissement de la portée du design

"Tant que nous y sommes, pouvons-nous redessiner le PDP ?" = 2+ semaines ajoutées. Modèle courant : un acteur voit la nouvelle vitrine Hyvä sur staging et décide que les couleurs / typographie ne sont pas tout à fait correctes, ce qui entraîne un rebranding en cours de projet qui n'était pas prévu.

Atténuation : verrouiller les références de design lors de la définition de la portée. Engagez-vous soit pour "reconstruction fidèle de Luma", soit pour "inclure un rebranding dans la portée dès le premier jour." Ne laissez pas de place à l'ambiguïté.

3. Mise à niveau de la version de Magento combinée

Mettre à niveau Magento 2.4.4 → 2.4.7 + migrer vers Hyvä dans la même fenêtre = +3 à 4 semaines de complexité intégrée.

Atténuation : séquencez-les. Mettez d'abord à niveau Magento, faites-le fonctionner en production pendant 4 à 6 semaines pour faire remonter les régressions, puis migrez vers Hyvä. Les mises à niveau combinées coûtent presque toujours plus cher que la version séquencée.

4. Environnement de staging non prêt au lancement

Si nous ne pouvons pas déployer sur staging le jour 1 de la semaine 1, chaque jour de retard repousse la mise en service 1 pour 1.

Atténuation : mettez en place le staging pendant la pré-vol, avant la date de lancement.

5. Revue des parties prenantes lente pendant l'UAT

La semaine UAT suppose que votre équipe peut consacrer du temps aux tests. Si les retours prennent 5 jours ouvrables, cela repousse la mise en service de 5 jours.

Atténuation : réservez des créneaux de calendrier UAT pour les parties prenantes avant le lancement. Ne laissez pas la revue de la semaine 7 être programmée de manière ad hoc.

6. Exigence B2B surprise

Découvrir à la semaine 5 que le commerçant a besoin d'un service autonome pour les comptes d'entreprise ou d'un flux de devis transforme une migration B2C en un projet B2B.

Atténuation : question explicite sur la portée B2B lors de la définition de la portée. "Avez-vous l'une de ces fonctionnalités ?" + liste de contrôle des fonctionnalités B2B d'Adobe Commerce.

7. La date de mise en service entre en conflit avec des événements de vente

Essayer de mettre en service la semaine du Black Friday ou lors d'un lancement de produit. Ne le faites pas.

Atténuation : choisissez une fenêtre calme de 4 semaines pour la mise en service + le post-lancement. Attendez la bonne fenêtre si nécessaire ; nous avons retardé des migrations de 8 semaines pour cela.

Quand 8 semaines ne sont pas réalistes

Soyez honnête si l'un de ces points s'applique, vous avez besoin de 10 à 14 semaines, pas 8 :

• 25+ extensions payantes
• Fonctionnalités B2B Commerce dans la portée
• Flux de paiement fortement personnalisé
• Portée Hyvä Commerce (pas seulement Hyvä Thème)
• Rebranding de marque ajouté à la migration
• Configuration Magento multi-boutiques / multi-sites avec >2 vitrines
• Adobe Commerce sur Cloud (le pipeline CI ajoute des frictions par rapport à l'auto-hébergement)

Pour ceux-ci, nous citons 10 à 14 semaines dès le départ. 8 semaines vous donne un site à moitié terminé en ligne ; personne ne gagne.

Dépassements de pires cas que nous avons vus

Pires cas réalistes issus de nos dossiers de projet :

Projet de 12 semaines qui a duré 18 semaines. B2B Adobe Commerce. En cours de projet, le commerçant a ajouté une exigence d'intégration avec un ERP personnalisé qui n'était pas sur la liste originale. L'intégration ERP seule a ajouté 4 semaines. Résultat final : expédié avec succès mais 6 semaines de retard.

Projet de 8 semaines qui a duré 11 semaines. Magento Open Source standard. En cours de projet, une mise à niveau de Magento 2.4.6 → 2.4.7 était nécessaire pour prendre en charge un correctif de sécurité. Nous avons séquencé : mise à niveau, puis reprise de la migration. Ajouté 3 semaines.

Projet de 10 semaines qui a duré 14 semaines. Rafraîchissement de marque ajouté à une migration en cours de projet. L'équipe de design a produit de nouvelles maquettes à la semaine 5 ; l'équipe de développement a dû jeter 2 semaines de travail et reconstruire à partir des nouvelles maquettes. Leçon : concevez avant de construire.

Dans les trois cas, le dépassement a été causé par des changements de portée en cours de projet, et non par des problèmes techniques avec Hyvä. Le travail technique est bien rodé ; la gestion de projet est là où les choses tournent mal.

Comment nous structurons les engagements de calendrier

Lorsque nous faisons une offre, le calendrier est fixé par rapport à la portée convenue. Plus précisément :

• Chaque semaine a des livrables explicites par écrit
• Chaque semaine, nous publions les progrès par rapport au plan
• Les ajouts hors de portée déclenchent une nouvelle offre (prix + calendrier) avant que nous les touchions
• Si nous manquons un jalon, vous en entendez parler la semaine où il est manqué, pas à la fin
• La date de mise en service se déplace avec le glissement des jalons ; nous ne compressons pas les semaines suivantes pour récupérer

C'est la signification pratique de "prix fixe, calendrier fixe". Le compromis : nous n'accepterons pas de changements de portée en cours de projet sans une nouvelle offre.

La question "pouvons-nous expédier plus rapidement ?"

Demande courante. Parfois oui, parfois non.

Plus rapide est réaliste lorsque :

• Vous pouvez prioriser la réactivité des parties prenantes (UAT en 1 jour au lieu de 5)
• Vous êtes prêt à abandonner des éléments souhaitables de la portée
• Vous pouvez consacrer du temps de développeur interne pour aider avec QA + UAT
• Vous n'êtes pas dans une fenêtre d'événement de vente ou en concurrence pour notre calendrier

Plus rapide n'est pas réaliste lorsque :

• Votre liste d'extensions a des surprises
• Votre fidélité au design n'est pas verrouillée
• Votre équipe est déjà surchargée (l'UAT sera en retard)
• Vous insistez pour que les fonctionnalités de la phase 2 soient livrées dans la phase 1

Nous sommes honnêtes sur votre situation lors de la définition de la portée. Parfois, la réponse est "oui, nous pouvons expédier en 6 semaines au lieu de 8" ; parfois c'est "non, et se précipiter nuira à la qualité." Nous le disons.

Prochaines étapes

• Consultez la page de service de migration Hyvä pour ce qui est inclus
• Lisez Comment migrer de Magento Luma à Hyvä en 8 semaines pour la répartition semaine par semaine
• Lisez Coût de la migration Hyvä en 2026 pour le budget détaillé
• Réservez un appel de définition de 30 minutes pour un devis à prix fixe et à calendrier fixe