
Votre boutique WiziShop fonctionne déjà.
Des produits sont en ligne. Des clients ont créé leur compte. Des commandes ont été passées. Certaines pages apparaissent sur Google. Vos équipes ont pris leurs habitudes. Des transporteurs, des solutions de paiement, des outils marketing ou des applications gravitent peut-être autour du site.
Et maintenant, vous envisagez Shopify.
La première question n’est généralement pas :
« Comment créer une boutique Shopify ? »
Elle est beaucoup plus concrète :
« Qu’est-ce qu’on va perdre en changeant de plateforme ? »
C’est précisément ce qui différencie une migration d’une création de boutique neuve.
Lorsque vous partez de zéro, vous construisez.
Lorsque vous migrez, vous devez construire le nouveau sans détruire la valeur accumulée dans l’ancien.
Produits, variantes, clients, commandes, référencement, URLs, données marketing, stocks, avis, moyens de paiement, transporteurs, automatisations : une boutique e-commerce est progressivement devenue un écosystème.
Migrer de WiziShop vers Shopify ne consiste donc pas simplement à exporter un fichier CSV et à le réimporter ailleurs.
La vraie question est :
Que faut-il conserver, que faut-il transformer, que faut-il reconstruire et que peut-on profiter de la migration pour améliorer ?
C’est sur cette logique que nous abordons les migrations chez Refresh Services.

Vu de l’extérieur, une migration peut sembler assez simple.
On crée Shopify.
On récupère les produits.
On importe les clients.
On branche le domaine.
Et c’est terminé.
En pratique, une boutique en ligne repose sur plusieurs couches qui doivent continuer à fonctionner ensemble.
Shopify lui-même recommande, dans son processus général de migration, de traiter non seulement les contenus et les données, mais également la vérification du catalogue, les paiements, les commandes de test, le domaine et le référencement.
Le catalogue n’est donc qu’une partie du projet.
Prenons un exemple simple.
Vous pouvez avoir parfaitement importé vos 5 000 produits.
Mais si :
votre import de produits est techniquement réussi, mais votre migration ne l’est pas.
Une migration doit donc être pensée comme un projet de continuité d’activité, pas comme un transfert de fichiers.
Une erreur fréquente consiste à créer très vite la nouvelle boutique et à commencer les imports avant même d’avoir réalisé un inventaire complet.
Nous préférons faire l’inverse.
Avant de déplacer quoi que ce soit, il faut savoir précisément ce qui existe.
Auditer le catalogue
Combien avez-vous réellement de :
La quantité seule ne suffit pas.
Un catalogue de 1 000 produits simples peut être beaucoup plus facile à migrer qu’un catalogue de 300 produits comportant chacun de nombreuses variantes et des règles spécifiques.
Il faut donc regarder la structure de la donnée, pas uniquement son volume.
WiziShop permet actuellement d’exporter les fiches clients au format CSV avec différentes informations, notamment les coordonnées, adresses, dates d’inscription, nombre de commandes et certaines informations de fidélité. Les commandes peuvent également être exportées avec leur historique et leurs principales informations.
Mais exporter ne signifie pas que Shopify attend exactement les mêmes colonnes.
C’est là qu’apparaît la notion de mapping de données.
On doit déterminer :
champ WiziShop → champ Shopify
et décider quoi faire lorsqu’une information n’a pas d’équivalent direct.
Cette étape devient particulièrement importante avec :
Posez-vous une question extrêmement simple :
qu’est-ce que votre boutique fait aujourd’hui ?
Pas seulement ce qu’elle affiche.
Ce qu’elle fait.
Par exemple :
Une migration peut être réussie graphiquement tout en oubliant un outil critique utilisé tous les jours par l’entreprise.
💡 Conseil Refresh
Avant de migrer, ne créez pas seulement une liste des pages et des produits. Créez une cartographie de l’écosystème complet de la boutique : données, outils, automatisations, paiements, livraison, marketing et gestion interne.
Enfin, il faut regarder ce que Google connaît déjà.
Quelles catégories génèrent du trafic ?
Quels produits se positionnent ?
Quels articles attirent encore des visiteurs plusieurs mois après leur publication ?
Quelles URLs possèdent des backlinks ?
Quelles pages génèrent des ventes issues du référencement naturel ?
Changer de CMS sans regarder ces informations revient à déménager une boutique physique sans vérifier quels panneaux indiquent actuellement son adresse.
Beaucoup de choses peuvent être reprises.
Mais toutes ne se transfèrent pas avec la même méthode.
Les produits
WiziShop permet l’import et l’export de son catalogue produit au format CSV.
Le fichier contient différents champs permettant de récupérer et restructurer les informations produit.
Pour un catalogue relativement simple, le CSV peut donc constituer une bonne base de travail.
Mais dès que la structure devient complexe, il faut aller plus loin.
C’est un excellent exemple.
La documentation actuelle de WiziShop indique que les produits comportant des variations ne sont pas gérés par son outil classique d’import/export catalogue CSV de la même manière que les produits simples. Le recours à l’API peut alors être nécessaire pour travailler correctement sur ces données.
Une boutique qui vend un produit unique sans option n’a donc pas la même problématique qu’un site proposant :
À grande échelle, une mauvaise reprise des variantes peut produire :
⚠️ Erreur fréquente
Faire un test concluant sur dix produits simples puis considérer que tout le catalogue se migrera de la même manière.
Les cas complexes doivent être identifiés avant l’import massif.
Les profils clients WiziShop peuvent servir de base pour constituer le fichier d’import Shopify.
Shopify permet actuellement d’importer des profils clients via CSV, avec notamment les coordonnées, adresses, consentements marketing et certains champs personnalisés pris en charge.
Il faut cependant nettoyer le fichier avant import :
Une migration est également une excellente occasion de ne pas transférer aveuglément plusieurs années de données devenues inutiles.
Les commandes peuvent être exportées depuis WiziShop.
Côté Shopify, les commandes historiques ne s’importent pas simplement dans le CSV client.
Shopify indique que les commandes historiques peuvent notamment être migrées via des applications de migration ou les API prévues à cet effet. Shopify recommande également d’importer dans l’ordre :
produits → clients → commandes historiques
afin que les commandes puissent correctement retrouver les produits et clients auxquels elles correspondent.
Cet ordre peut sembler anecdotique.
Il ne l’est pas.
Une migration de données réussie ne consiste pas uniquement à retrouver les informations.
Il faut retrouver les relations entre elles.
Le CSV est extrêmement utile.
Mais il ne faut pas en faire une baguette magique.
Un fichier CSV représente des données sous forme de colonnes et de lignes.
Il ne reproduit pas automatiquement :
Pour certains projets, plusieurs méthodes peuvent donc être utilisées simultanément :
La bonne méthode dépend du volume et de la complexité.
✅ Bonne pratique
Ne choisissez pas la méthode de migration avant d’avoir compris la donnée à migrer.
Un petit catalogue simple et un catalogue de plusieurs dizaines de milliers de références ne justifient pas nécessairement la même approche.
Un autre piège consiste à considérer Shopify comme une boîte vide dans laquelle on doit reproduire exactement WiziShop.
Ce n’est pas forcément le bon objectif.
Une migration peut aussi servir à nettoyer plusieurs années d’accumulation.
Avant l’import, il peut être intéressant de revoir :
Shopify recommande lui-même de profiter d’une migration pour examiner l’existant et décider quelles données et quels contenus méritent réellement d’être conservés.
Autrement dit :
migrer ne signifie pas recopier aveuglément.
Si votre ancienne structure était devenue confuse, reproduire exactement cette confusion dans Shopify n’aurait aucun intérêt.
Avec quelques dizaines de produits, il est possible de vérifier manuellement chaque fiche après import.
Avec plusieurs dizaines de milliers, la logique change complètement.
Contrôler les références et SKU
Le SKU sert souvent de lien entre :
Une erreur de référence peut donc se propager bien au-delà de Shopify.
Sur un gros catalogue, on ne vérifie plus seulement :
« Le produit existe-t-il ? »
On vérifie :
« Toutes ses variantes existent-elles et sont-elles correctement associées ? »
Une image manquante sur 30 produits est visible.
Sur 30 000 références, elle peut facilement passer inaperçue.
Il faut prévoir des contrôles permettant d’identifier :
Les catégories WiziShop ne doivent pas nécessairement devenir une copie exacte des collections Shopify.
La migration est une opportunité pour vérifier :
Imaginez :
vous exportez votre catalogue lundi.
La nouvelle boutique est finalisée vendredi.
Pendant quatre jours, WiziShop continue à vendre.
Les stocks du fichier de lundi ne sont donc plus nécessairement les stocks réels du vendredi.
La bascule doit anticiper ces données qui continuent de bouger.
C’est souvent l’une des différences entre une migration théorique et une migration réellement opérationnelle.

C’est un point qui doit être anticipé dans la communication client.
Les profils peuvent être repris.
Les mots de passe, en revanche, constituent un cas différent.
Shopify précise actuellement que les mots de passe clients d’une autre boutique ne peuvent pas être migrés via CSV car ils sont chiffrés en dehors de Shopify. Les clients doivent donc être accompagnés dans le nouveau parcours de connexion ou de création de leurs accès selon le système de comptes utilisé.
Ce n’est pas un problème si c’est prévu.
Cela peut devenir un problème si vos clients le découvrent seuls le lendemain de la migration.
Le projet doit donc prévoir :
🧠 Le point de vue Refresh
🧠 Le point de vue Refresh
Une migration technique réussie mais incompréhensible pour les clients n’est pas une migration totalement réussie.
L’expérience utilisateur doit être pensée au même niveau que le transfert de données.
C’est probablement la partie où les erreurs sont les moins visibles le jour de la mise en ligne.
Et parfois les plus coûteuses plusieurs semaines plus tard.
Inventorier les anciennes URLs
Avant la bascule, il faut récupérer une cartographie aussi complète que possible des URLs actuelles :
Cette cartographie peut être croisée avec les données SEO pour identifier les URLs les plus importantes.
Shopify utilise sa propre structure d’URL.
La documentation Shopify prévient explicitement que les structures de liens peuvent différer de celles de l’ancienne plateforme.
Il faut donc créer un tableau :
| Ancienne URL | Nouvelle URL |
| ancienne page produit | nouvelle page produit |
| ancienne catégorie | nouvelle collection |
| ancien article | nouvel article |
Lorsqu’une ancienne URL change, elle doit idéalement rediriger vers la nouvelle page correspondante.
Pas systématiquement vers l’accueil.
Shopify permet actuellement de créer et d’importer des redirections d’URL, notamment via CSV.
Si Google connaît :
/ancienne-categorie/produit-a
et que le produit devient :
/products/produit-a
la redirection doit mener vers ce produit.
Pas vers /.
Sinon vous perdez une partie du sens de la redirection.
Un nouveau design donne parfois envie de tout simplifier.
Attention.
Une description de catégorie un peu longue ou un article publié trois ans auparavant peut sembler secondaire visuellement tout en générant encore :
Avant de supprimer un contenu, regardez sa valeur.
Après bascule, il faut surveiller :
📌 À retenir
Le SEO d’une migration ne se traite pas le soir de la mise en ligne.
Il doit être préparé avant la migration, exécuté pendant la bascule et surveillé après.

Changer de plateforme ne signifie pas devoir changer de domaine.
Shopify permet de connecter ou de transférer un domaine existant vers la nouvelle boutique.
Le point sensible est plutôt le moment de la bascule.
Le domaine ne doit être dirigé vers Shopify que lorsque la nouvelle boutique est suffisamment prête.
Avant de modifier le DNS, il faut avoir vérifié :
Le changement de DNS doit être l’aboutissement d’une préparation.
Pas son commencement.
C’est une distinction essentielle.
Paiements
Votre historique de commandes peut être repris.
Mais vos moyens de paiement doivent être configurés et testés dans le nouvel environnement.
Même chose pour :
Il faut repartir du fonctionnement attendu et reconstruire la configuration adaptée.
Une fonctionnalité utilisée dans WiziShop n’a pas nécessairement son clone exact sur Shopify.
La bonne question n’est donc pas :
« Quelle app ressemble à notre ancien outil ? »
Mais :
« Quel besoin cet outil résolvait-il ? »
Une migration est souvent le bon moment pour simplifier un empilement devenu trop complexe.
Il faut également vérifier :
Une boutique peut parfaitement encaisser les commandes tout en ayant perdu une partie de son tracking.
Cela ne se voit pas immédiatement côté client.
Mais cela peut fortement affecter le pilotage marketing.

Oui, et c’est généralement ce que l’on cherche à faire.
La boutique Shopify peut être préparée pendant que WiziShop continue à fonctionner.
On travaille alors sur :
La difficulté est que l’ancienne boutique reste vivante.
Entre le premier export et la bascule finale :
Il faut donc décider quelles données sont :
C’est ce que l’on appelle parfois une reprise différentielle ou une reprise finale.
Nous avons été confrontés à des projets où le catalogue dépassait les 30 000 références.
À cette échelle, le raisonnement change.
L’import n’est plus réellement la partie la plus impressionnante.
Importer des dizaines de milliers de lignes peut être automatisé.
Le véritable enjeu est de savoir si, après traitement :
Imaginez un taux d’erreur de seulement 0,5 %.
Sur 200 produits, cela représente un produit.
Sur 30 000 références, cela représente 150 références potentiellement concernées.
Le contrôle qualité doit donc évoluer avec le volume.
On ne peut plus se contenter d’ouvrir quelques fiches au hasard et de conclure :
« Ça a l’air bon. »
Il faut prévoir des contrôles systématiques, des rapprochements de volumes et des vérifications ciblées.
🧠 Le point de vue Refresh
Plus le catalogue est volumineux, moins la question est « Peut-on importer les données ? ».
La vraie question devient :
« Comment prouver que les données importées sont justes ? »
C’est une nuance essentielle.
Avant de changer le domaine, nous voulons au minimum pouvoir répondre positivement à ces questions :
Une checklist ne garantit pas à elle seule une bonne migration.
Mais elle réduit fortement le risque d’oublier un élément basique au milieu d’un projet complexe.
Le site est en ligne.
La première commande arrive.
Tout semble fonctionner.
La migration n’est pourtant pas terminée.
Les heures et jours suivants servent à surveiller :
Les vrais utilisateurs vont parfois reproduire des scénarios auxquels personne n’avait pensé pendant les tests.
Une période de surveillance après bascule est donc indispensable.
Non
Et dire le contraire serait peu crédible.
Une petite boutique WiziShop avec :
peut potentiellement réaliser une bonne partie de sa migration en interne.
Le besoin d’accompagnement augmente lorsque s’ajoutent :
La bonne question n’est donc pas :
« Une agence est-elle obligatoire ? »
Mais :
« Quel est le niveau de risque et de complexité de ma boutique actuelle ? »
Plus votre e-commerce est devenu essentiel à votre activité, plus la bascule mérite d’être préparée.
Passer de WiziShop à Shopify peut être une évolution pertinente.
Mais Shopify ne doit pas être choisi simplement parce qu’il est Shopify.
Une migration a du sens lorsqu’elle permet de répondre à de nouveaux besoins :
Et surtout, une migration ne doit pas chercher à reproduire aveuglément l’ancienne boutique dans un nouvel environnement.
Elle doit préserver ce qui possède de la valeur :
données, clients, SEO, contenus, historique et processus utiles.
Puis profiter du changement pour améliorer ce qui peut l’être.
Chez Refresh, nous considérons donc une migration comme une transformation complète de l’écosystème e-commerce.
Le transfert des produits est une étape.
La réussite du projet se mesure plutôt à une question beaucoup plus simple :
Le lendemain de la bascule, vos clients peuvent-ils continuer à trouver, comprendre, commander et recevoir vos produits pendant que votre équipe continue à travailler normalement ?
Si la réponse est oui, alors la migration commence réellement à être réussie.
Oui. Les produits, clients, contenus et une partie de l’historique peuvent être récupérés puis restructurés pour Shopify. La méthode dépend toutefois du volume de données, des variantes, de l’historique de commandes, des applications utilisées et des fonctionnalités spécifiques de la boutique.
Oui. WiziShop permet l’export de son catalogue produit. Il faut cependant contrôler la correspondance avec la structure Shopify, notamment pour les références, variantes, images, stocks et catégories. Les produits à variations demandent une attention particulière car l’outil CSV WiziShop ne les traite pas comme de simples produits.
Oui. Les fiches clients peuvent être exportées depuis WiziShop puis restructurées pour l’import Shopify. Il est conseillé de vérifier les doublons, les adresses, les emails et les consentements marketing avant import.
Pas via un import CSV classique. Shopify indique que les mots de passe provenant d’une autre boutique ne peuvent pas être migrés de cette façon car ils sont chiffrés. Le nouveau parcours de connexion doit donc être anticipé.
Oui, une migration n’entraîne pas automatiquement une perte de référencement. Le risque apparaît surtout si les anciennes URLs disparaissent sans redirection, si des contenus performants sont supprimés ou si la nouvelle architecture n’est pas correctement suivie. Il faut préparer un plan de redirections et contrôler l’indexation après la mise en ligne.
Oui. Un domaine existant peut être connecté ou transféré vers Shopify. Le changement de domaine technique doit simplement être préparé afin que la nouvelle boutique soit prête avant la bascule.
Oui. La boutique Shopify peut être construite pendant que WiziShop continue à prendre des commandes. Il faut cependant prévoir la reprise des données qui continuent d’évoluer entre le premier export et le moment de la bascule, notamment commandes, clients et stocks.
Non. Shopify peut être adapté à de nombreux projets e-commerce, mais le choix doit dépendre du besoin réel : volume, fonctionnalités, équipe, international, coûts, intégrations, autonomie et perspectives d’évolution. Une migration doit résoudre une problématique concrète, pas simplement remplacer une technologie par une autre.
Avant de commencer les imports, un audit de l’existant permet de cartographier le catalogue, les clients, les commandes, les URLs, les outils connectés et les fonctionnalités réellement indispensables.
L’objectif n’est pas simplement de « passer sur Shopify ».
Il est de construire une nouvelle boutique capable de reprendre ce qui fonctionne déjà, de corriger ce qui doit évoluer et de continuer à vendre pendant la transition.