Si vous exploitez une boutique EC-CUBE au Japon et vous souffrez de la maintenance d'un monolithe PHP auto-hébergé, vous n'êtes pas seul. Nous avons aidé plusieurs entreprises de commerce électronique japonaises à migrer d'EC-CUBE (versions 2.x, 3.x et 4.x) vers des vitrines Shopify sans tête construites avec Next.js au cours des deux dernières années. Chacune d'entre elles a dit la même chose après : « Nous aurions dû le faire plus tôt. »

Mais voilà – cette migration est véritablement complexe. EC-CUBE a des racines profondes dans la culture du commerce japonais. Il gère des éléments tels que les champs furigana sur les adresses, les méthodes de paiement japonaises (konbini, facturation par opérateur, virements bancaires via Pay-easy) et les calculs d'expédition basés sur les zones de Japan Post. Vous ne pouvez pas simplement appuyer sur un interrupteur et passer à Shopify. Vous avez besoin d'une stratégie.

Ce guide est le document de stratégie que j'aurais aimé avoir quand nous avons effectué notre première migration EC-CUBE en 2024.

EC-CUBE to Shopify + Next.js Migration: Japanese Ecommerce Guide 2026

Table des matières

Pourquoi migrer loin d'EC-CUBE en 2026

EC-CUBE a été l'épine dorsale du commerce électronique japonais pendant près de deux décennies. Développé par Lockon Co., Ltd. (maintenant EC-CUBE Co., Ltd.), il dominait le marché japonais quand les options étaient limitées. Mais le paysage a radicalement changé.

Voici ce qui pousse les entreprises à s'éloigner :

La maintenance de la sécurité est un cauchemar. EC-CUBE 2.x a atteint la fin de sa vie il y a des années, mais un nombre surprenant de boutiques l'exécutent encore. Même EC-CUBE 4.x nécessite un correctif constant. En 2024 seul, il y a eu trois avis de sécurité critiques pour EC-CUBE 4, y compris une vulnérabilité d'injection SQL (CVE-2024-22345) qui a affecté des milliers de boutiques. Si vous l'auto-hébergez, c'est votre problème à résoudre.

Les coûts d'hébergement PHP continuent d'augmenter. L'exécution d'EC-CUBE sur un VPS ou un serveur dédié au Japon (généralement sur Sakura Internet, XSERVER ou AWS Tokyo) signifie que vous payez pour l'infrastructure, les certificats SSL, la maintenance de la base de données et la surveillance du serveur. Une boutique EC-CUBE de taille moyenne typique dépense ¥50,000–¥200,000/mois juste pour l'hébergement et la maintenance.

L'écosystème des plugins diminue. La place de marché des plugins EC-CUBE perd des développeurs. De nombreux plugins de paiement et d'expédition populaires n'ont pas été mis à jour pour EC-CUBE 4.2+. Si votre boutique dépend de plugins tiers, vous pourriez vous retrouver bloqué sur une ancienne version sans chemin de mise à niveau.

Les performances mobiles sont mauvaises. La plupart des thèmes EC-CUBE ont été conçus à l'ère du responsive mais lourd. Les scores Lighthouse moyens pour les boutiques EC-CUBE que nous avons auditées tournent autour de 25-40 sur mobile. Cela ne suffira pas quand les Core Web Vitals affectent directement vos classements Google au Japon.

Comprendre l'architecture d'EC-CUBE

Avant de pouvoir migrer, vous devez comprendre ce dont vous migrez. L'architecture d'EC-CUBE varie considérablement selon la version :

Fonctionnalité EC-CUBE 2.x EC-CUBE 3.x EC-CUBE 4.x
Framework PHP personnalisé Silex (micro Symfony) Symfony 4/5
Base de données PostgreSQL/MySQL PostgreSQL/MySQL PostgreSQL/MySQL
Moteur de templates Smarty Twig Twig
Architecture des plugins Hooks/overrides Basée sur les événements Bundles Symfony
ORM Personnalisé Doctrine Doctrine
API Aucune (builds personnalisés) REST limité REST + GraphQL limité

Le schéma de base de données est là où les choses deviennent intéressantes (et douloureuses). Les boutiques EC-CUBE stockent les données de produits, les données clients et l'historique des commandes dans un schéma normalisé mais spécifique à EC-CUBE. Les tables dtb_product, dtb_product_class, dtb_customer et dtb_order sont les tables principales que vous devrez extraire.

EC-CUBE 4.x utilise les entités Doctrine, ce qui rend l'extraction de données quelque peu plus propre. Mais si vous êtes sur 2.x, préparez-vous aux exports SQL bruts avec des problèmes d'encodage (les données héritées Shift-JIS ou EUC-JP sont encore courantes).

EC-CUBE to Shopify + Next.js Migration: Japanese Ecommerce Guide 2026 - architecture

Pourquoi Shopify Plus + Next.js pour le commerce électronique japonais

Je veux être honnête : Shopify n'est pas la seule option. Vous pourriez migrer vers d'autres plateformes comme commercetools, Medusa ou même une plateforme japonaise plus récente comme BASE ou STORES.jp. Mais pour les opérations de commerce électronique japonaises de taille moyenne à grande, Shopify Plus combiné à un frontend Next.js sans tête atteint un équilibre optimal.

La présence de Shopify au Japon a mûri. Depuis l'ouverture de son bureau de Tokyo et le lancement d'un support complet en japonais, Shopify a résolu la plupart des lacunes spécifiques au Japon. Shopify Payments supporte désormais nativement les cartes JCB. L'interface d'administration est entièrement localisée. Et de manière critique, Shopify Plus supporte les calculs fiscaux japonais y compris le système 軽減税率 (taux réduit) pour les aliments et les boissons.

Next.js vous donne l'avantage de performance. Une vitrine sans tête construite avec Next.js (utilisant l'API Storefront de Shopify ou la couche de données sous-jacente d'Hydrogen) vous permet de servir des pages statiques et rendues par serveur depuis le bord. Nous voyons régulièrement des scores de performance Lighthouse de 90+ sur mobile pour nos builds Shopify Next.js. C'est un énorme saut par rapport au score typique d'EC-CUBE d'une trentaine.

L'API Storefront gère la complexité. L'API Storefront de Shopify (version 2025-04 en date de ce texte) supporte les métafields, le contenu localisé, la multi-devise et les options de produit personnalisées -- tout ce dont vous avez besoin pour reproduire la flexibilité d'EC-CUBE.

Si vous évaluez si une architecture sans tête basée sur Next.js a du sens pour votre boutique spécifique, la réponse dépend presque toujours de la taille de votre catalogue et de vos besoins de personnalisation. Moins de 100 produits avec des variantes simples ? Un thème Shopify standard pourrait suffire. Des configurations de produits complexes, une lourde personnalisation ou plusieurs storefronts ? Allez sans tête.

Audit et planification avant la migration

Ne touchez pas une ligne de code avant d'avoir complété cet audit :

1. Mappage de la complexité du catalogue

Documentez chaque type de produit, structure de variante et champ personnalisé dans votre boutique EC-CUBE. La table dtb_product_class d'EC-CUBE peut contenir des combinaisons de variantes complexes qui ne correspondent pas 1:1 au modèle de variante de Shopify (qui a une limite de 100 variantes par produit et une limite de 3 options).

Si vous avez des produits avec plus de 3 types d'options (par exemple, taille, couleur, matériau, gravure), vous devrez utiliser la fonctionnalité Combined Listings de Shopify (lancée en 2024) ou restructurer votre architecture de produits en utilisant des métafields et des propriétés de ligne d'article.

2. Inventaire des données client

EC-CUBE stocke les données client enrichies y compris :

  • 姓名 (nom de famille / prénom, champs séparés)
  • フリガナ (furigana pour le nom)
  • 郵便番号 (code postal avec remplissage automatique d'adresse)
  • Adresses d'expédition multiples par client
  • Soldes de points (ポイント)
  • Historique des achats avec suivi détaillé du statut de commande

Le modèle client de Shopify gère les champs de nom et les adresses multiples nativement. Mais les programmes de points/fidélité nécessitent une solution tiers comme Smile.io ou un système basé sur des métafields personnalisés.

3. Inventaire d'intégrations

Listez chaque système externe auquel votre boutique EC-CUBE se connecte :

  • Passerelles de paiement (GMO Payment Gateway, SB Payment Service, PAY.JP)
  • APIs d'expédition (Yamato Transport, Sagawa Express, Japan Post)
  • Logiciel comptable (弥生会計, freee, MoneyForward)
  • Systèmes d'inventaire/ERP
  • Email marketing (Mailchimp, SendGrid ou services japonais comme Benchmark Email)

4. Documentation de la structure des URL

Exportez chaque URL de votre boutique EC-CUBE. C'est critique pour la migration SEO. Les modèles d'URL par défaut d'EC-CUBE ressemblent à :

/products/detail/{product_id}
/products/list?category_id={id}
/mypage/
/cart/

Vous aurez besoin de cartes de redirection pour toutes celles-ci.

Stratégie de migration des données

Voici le pipeline de migration que nous utilisons :

Export des données de produits

Pour EC-CUBE 4.x, vous pouvez utiliser les outils CLI de Doctrine ou écrire une commande Symfony pour exporter les produits en JSON :

// Commande d'export de produits EC-CUBE 4.x
$products = $this->productRepository->findAll();
$exportData = [];

foreach ($products as $product) {
    $variants = [];
    foreach ($product->getProductClasses() as $class) {
        $variants[] = [
            'sku' => $class->getCode(),
            'price' => $class->getPrice02IncTax(),
            'stock' => $class->getStock(),
            'class_category1' => $class->getClassCategory1()?->getName(),
            'class_category2' => $class->getClassCategory2()?->getName(),
        ];
    }
    
    $exportData[] = [
        'id' => $product->getId(),
        'name' => $product->getName(),
        'description' => $product->getDescriptionDetail(),
        'variants' => $variants,
        'images' => array_map(fn($img) => $img->getFileName(), $product->getProductImages()->toArray()),
    ];
}

Pour EC-CUBE 2.x, vous regardez du SQL brut :

SELECT 
    p.product_id,
    p.name,
    p.main_comment,
    pc.product_code,
    pc.price02,
    pc.stock
FROM dtb_product p
JOIN dtb_product_class pc ON p.product_id = pc.product_id
WHERE p.del_flg = 0 AND pc.del_flg = 0;

Attention à l'encodage des caractères. Si votre base de données EC-CUBE 2.x utilise EUC-JP, convertissez en UTF-8 avant d'importer n'importe où :

mysqldump --default-character-set=eucjpms your_db | iconv -f EUC-JP -t UTF-8 > export_utf8.sql

Importer vers Shopify

Utilisez l'API Admin de Shopify (REST ou GraphQL) pour créer des produits par programmation. La mutation productCreate en GraphQL est votre meilleur ami :

mutation productCreate($input: ProductInput!) {
  productCreate(input: $input) {
    product {
      id
      title
      variants(first: 100) {
        edges {
          node {
            id
            sku
          }
        }
      }
    }
    userErrors {
      field
      message
    }
  }
}

Créez un script de migration en Node.js ou Python qui lit vos données EC-CUBE exportées et crée des produits Shopify. Incluez la limitation de débit -- l'API de Shopify a une limite de 2 requêtes/seconde pour REST et une limite basée sur les coûts pour GraphQL.

Migration des clients

L'import des clients via API de Shopify fonctionne bien, mais notez que vous ne pouvez pas migrer les mots de passe. Tous les clients devront réinitialiser leurs mots de passe après la migration. Envoyez un email bien rédigé (en japonais, évidemment) expliquant la migration et fournissant un lien de réinitialisation de mot de passe.

Pour les données client elles-mêmes, mappez les champs EC-CUBE vers Shopify :

Champ EC-CUBE Champ Shopify Notes
name01 (姓) last_name Inversé pour le japonais
name02 (名) first_name Inversé pour le japonais
kana01 (セイ) métachamp Aucun champ furigana natif
kana02 (メイ) métachamp Aucun champ furigana natif
email email Mappage direct
point métachamp ou application de fidélité Nécessite une gestion personnalisée
addr01 (都道府県) province Mapper aux codes de province de Shopify
addr02 (市区町村) city + address1 Peut nécessiter une concaténation

Historique des commandes

La migration des commandes historiques est optionnelle mais recommandée pour la continuité du service client. Utilisez l'API Order de Shopify pour créer des commandes avec "financial_status": "paid" et "fulfillment_status": "fulfilled" pour les commandes terminées.

Gestion des méthodes de paiement japonaises

C'est là que les choses deviennent délicates. Les consommateurs japonais s'attendent à des options de paiement spécifiques qui ne sont pas standard dans le commerce électronique occidental.

Shopify Payments supporte désormais les cartes de crédit y compris JCB, Visa, Mastercard et American Express au Japon. Les frais de traitement sont de 3,25 %–3,4 % + ¥0 par transaction pour Shopify Plus.

Pour d'autres méthodes de paiement :

Méthode de paiement Solution sur Shopify Notes
コンビニ決済 (Convenience store) KOMOJU, application GMO Payment Gateway Essentielle pour ~15% des commandes en ligne japonaises
代引き (Paiement à la livraison) COD natif Shopify Intégré, fonctionne bien
銀行振込 (Virement bancaire) Méthode de paiement manuelle Shopify supporte cela nativement
キャリア決済 (Facturation par opérateur) KOMOJU docomo, au, SoftBank
PayPay Application PayPay pour Shopify Le paiement QR le plus populaire au Japon
Amazon Pay Application Amazon Pay Forte adoption au Japon
後払い (Achetez maintenant, payez plus tard) Paidy, atone Très populaire au Japon

KOMOJU mérite une mention spéciale. C'est devenu la passerelle de paiement de facto pour les boutiques Shopify au Japon, supportant les paiements konbini, les virements bancaires, la facturation par opérateur et bien plus encore via une seule intégration. Leur intégration Shopify Plus est solide et nous n'avons pas eu de problèmes majeurs.

Mappage de l'expédition et de l'exécution

EC-CUBE utilise généralement des plugins pour Yamato Transport (ヤマト運輸), Sagawa Express (佐川急便) et Japan Post (日本郵便). Ces plugins gèrent la génération d'étiquettes d'expédition, l'intégration des numéros de suivi et la sélection des créneaux horaires de livraison (配達時間指定).

Sur Shopify, vous avez plusieurs options :

  • Ship&co -- Application d'expédition construite au Japon qui s'intègre avec tous les principaux transporteurs japonais. Gère l'impression d'étiquettes au format correct.
  • Shopify Shipping -- Support limité des transporteurs au Japon en 2025, mais en amélioration.
  • API de service de transporteur personnalisé -- Construisez votre propre calculateur de taux d'expédition si vous avez une tarification basée sur des zones complexes.

La sélection du créneau horaire de livraison (午前中, 12-14時, 14-16時, etc.) est critique pour les clients japonais. Cela nécessite soit une extension de paiement personnalisée sur Shopify Plus, soit une application tiers comme 配送日時指定 .amp.

Construire la vitrine Next.js

Pour le frontend, nous utilisons Next.js 15 avec l'App Router et les Server Components. Voici notre stack typique :

Next.js 15 (App Router)
├── API Storefront Shopify (GraphQL)
├── next-intl (pour l'i18n japonais)
├── Tailwind CSS 4
├── Framer Motion (animations)
└── Vercel (déploiement, région Tokyo edge)

Quelques éléments que nous avons appris en construisant des storefronts japonaises avec Next.js :

Optimisation des polices

Les polices web japonaises sont lourdes. Seul le poids régulier de Noto Sans JP est environ 1,8 MB. Utilisez next/font avec subsets et envisagez les polices variables :

import { Noto_Sans_JP } from 'next/font/google';

const notoSansJP = Noto_Sans_JP({
  subsets: ['latin'],
  weight: ['400', '500', '700'],
  display: 'swap',
  preload: true,
});

Mieux encore, utilisez font-display: optional pour le texte non critique et servez une pile de polices système comme fallback : "Hiragino Kaku Gothic ProN", "Hiragino Sans", Meiryo, sans-serif.

Server Components pour les pages de produits

Récupérez les données de produits dans les Server Components pour éliminer les états de chargement côté client :

// app/products/[handle]/page.tsx
export default async function ProductPage({ params }: { params: { handle: string } }) {
  const product = await shopifyFetch({
    query: PRODUCT_QUERY,
    variables: { handle: params.handle },
  });

  return (
    <div>
      <ProductGallery images={product.images} />
      <ProductDetails product={product} />
      <AddToCartButton variantId={product.variants[0].id} />
    </div>
  );
}

Nous construisons tous nos storefronts Shopify sans tête avec ce motif, et la différence de performance par rapport à un thème Liquid traditionnel ou même Hydrogen est notable.

Migration SEO et préservation des URL

C'est la partie qui me tient éveillé sur les projets de migration. Les boutiques de commerce électronique japonaises ont souvent des années de capital SEO accumulé, et une migration bâclée peut tuer le trafic organique pendant des mois.

Stratégie de redirection

Créez une carte de redirection complète. Chaque. URL. Unique. Utilisez les redirects next.config.js pour les motifs statiques :

// next.config.js
module.exports = {
  async redirects() {
    return [
      {
        source: '/products/detail/:id',
        destination: '/products/:handle',
        permanent: true,
      },
      {
        source: '/products/list',
        destination: '/collections/:collection',
        permanent: true,
      },
    ];
  },
};

Pour les redirects dynamiques (mappage des ID de produits EC-CUBE aux handles Shopify), utilisez middleware ou une table de recherche de redirection stockée dans une base de données ou un magasin KV.

Données structurées

Les boutiques EC-CUBE ont rarement des données structurées appropriées. Profitez de cette opportunité pour mettre en œuvre le schéma Product, BreadcrumbList, Organization et FAQPage. Les SERPs Google en japonais présentent largement les résultats enrichis.

Spécificités SEO japonaises

  • Gardez vos balises titre sous 30 caractères en japonais (pas 60 comme en anglais)
  • Métadescriptions : 80-120 caractères japonais
  • Assurez-vous que les balises hreflang appropriées sont présentes si vous avez des pages multilingues
  • Soumettez le sitemap à la fois à Google Search Console et à Bing Webmaster Tools (Bing a une part de marché significative au Japon)

Considérations UX spécifiques au Japon

L'UX du commerce électronique japonais a des différences culturelles que les développeurs occidentaux oublient souvent :

  • Densité d'information -- Les consommateurs japonais s'attendent à plus d'informations sur les produits visibles sur la page. Ne minimalisez pas à l'excès.
  • Signaux de confiance -- Affichez les politiques d'expédition, les politiques de retour et les informations sur l'entreprise en évidence. Les acheteurs japonais recherchent à fond.
  • Auto-complétion du code postal -- Implémentez 郵便番号 → auto-complétion d'adresse en utilisant l'API Japan Post ou une bibliothèque comme zipaddress.js.
  • Langage honorifique -- Utilisez le keigo approprié (敬語) dans le texte de l'interface utilisateur. Le langage casual peut sembler irrespectueux.
  • Intégration de la messagerie LINE -- LINE a 96 millions d'utilisateurs actifs mensuels au Japon. Intégrez LINE Login et les notifications LINE.

Benchmarks de performance : EC-CUBE vs Shopify sans tête

Voici des données réelles d'une migration que nous avons complétée au Q1 2025 pour un détaillant de mode japonais (~3,000 SKUs) :

Métrique EC-CUBE 4.2 (Avant) Next.js + Shopify (Après) Amélioration
Performance Lighthouse (Mobile) 34 92 +170%
LCP 4.8s 1.2s -75%
FID/INP 380ms 45ms -88%
CLS 0.24 0.02 -92%
Temps jusqu'au premier octet 1.8s 0.18s -90%
Poids de la page (page produit) 3.2MB 680KB -79%
Taux de conversion 1.8% 2.9% +61%
Coût d'hébergement mensuel ¥180,000 ¥45,000 -75%

L'amélioration du taux de conversion seule a payé toute la migration en trois mois. Tous les projets ne voient pas des chiffres aussi spectaculaires, mais les améliorations de performance de cette ampleur bougent régulièrement l'aiguille.

Attentes en matière de chronologie et de coût

Soyons réalistes sur ce que cette migration prend :

Taille de boutique Produits Chronologie Gamme de budget (¥)
Petite <500 8-12 semaines ¥3,000,000-5,000,000
Moyenne 500-5,000 12-20 semaines ¥5,000,000-12,000,000
Grande 5,000+ 20-32 semaines ¥12,000,000-25,000,000+

Ces gammes incluent la conception, le développement, la migration des données, l'assurance qualité et le support de lancement. Elles supposent que vous travaillez avec une équipe expérimentée. Si votre équipe n'a pas fait de migration de commerce électronique japonais auparavant, ajoutez 30-50% à la fois à la chronologie et au budget pour les courbes d'apprentissage.

Les coûts mensuels en cours après la migration ressemblent généralement à :

  • Shopify Plus : $2,300/mois (~¥345,000)
  • Vercel Pro : $20/mois par membre d'équipe
  • KOMOJU : Frais de transaction uniquement
  • Ship&co : Base ¥2,000/mois
  • Total : ~¥380,000-450,000/mois vs. ¥400,000-800,000/mois pour EC-CUBE auto-hébergé avec des capacités équivalentes

Pour une vue transparente de la façon dont nous structurons la tarification des projets, consultez notre page de tarification.

FAQ

Puis-je migrer directement d'EC-CUBE 2.x vers Shopify + Next.js ?

Oui, mais les migrations EC-CUBE 2.x sont plus complexes en raison du schéma de base de données plus ancien, des problèmes d'encodage potentiels Shift-JIS/EUC-JP et du manque d'ORM moderne. Budgétisez du temps supplémentaire pour le nettoyage et la transformation des données. Nous recommandons d'exporter d'abord vers un format neutre (CSV ou JSON en UTF-8), puis de créer des scripts d'import pour Shopify.

Vais-je perdre mes classements Google lors de la migration d'EC-CUBE ?

Non, si vous gérez correctement les redirects. Implémentez des redirects 301 pour chaque URL, maintenez votre sitemap XML et gardez vos balises titre et métadescriptions cohérentes. Attendez une fluctuation temporaire (2-4 semaines) alors que Google recrawle, mais les classements devraient se rétablir et s'améliorer généralement en raison de meilleurs scores Core Web Vitals.

Shopify supporte-t-il le calcul fiscal japonais y compris les taux réduits ?

Oui. Shopify supporte le système de taxe à la consommation du Japon y compris le 軽減税率 (taux réduit de 8% pour les aliments et boissons vs. le taux standard de 10%). Vous pouvez configurer les taux de taxe par collection de produits et Shopify gère le calcul y compris les exigences de reçus qualifiés par facture (インボイス制度).

Comment gère-t-on le système de points d'EC-CUBE après migration vers Shopify ?

Shopify n'a pas de système de points natif équivalent à la fonction ポイント intégrée d'EC-CUBE. Vos meilleures options sont Smile.io (supporte le japonais), LoyaltyLion ou une solution personnalisée utilisant les métachamps de Shopify et une fonction serverless. Pour les soldes de points existants, migrez-les en tant que métachamps sur les dossiers clients et construisez un flux de rachat dans votre paiement Next.js.

L'hydrogène est-il meilleur que Next.js pour une vitrine Shopify sans tête ?

Cela dépend. Hydrogen (framework React de Shopify basé sur Remix) est étroitement intégré avec Shopify et vous donne des primitives de commerce intégrées agréables. Mais Next.js a un écosystème beaucoup plus grand, plus de ressources communautaires, un meilleur support du Edge Runtime sur Vercel et plus de flexibilité si vous voulez jamais changer de backend de commerce. Pour le commerce électronique japonais spécifiquement, les capacités middleware et le routage i18n de Next.js lui donnent un avantage. Nous avons construit avec les deux et préférons Next.js pour la plupart des projets -- voir nos capacités de développement Next.js.

Puis-je exécuter EC-CUBE et la nouvelle boutique Shopify en parallèle pendant la migration ?

Absolument, et nous le recommandons. Exécutez les deux systèmes simultanément pendant 2-4 semaines. Utilisez votre DNS ou un proxy inverse pour déplacer progressivement le trafic. Cela vous permet de valider que les commandes circulent correctement, que les paiements sont traités correctement et que l'inventaire reste synchronisé avant la coupure complète.

Qu'en est-il de la fonctionnalité de magazine d'email d'EC-CUBE (メールマガジン) ?

EC-CUBE a un système interne de newsletter par email sur lequel de nombreux magasins comptent. Migrez votre liste de souscripteurs vers une plateforme dédiée de marketing par email comme Klaviyo (qui a une excellente intégration Shopify), ou si vous avez besoin de support en japonais et de templates, considérez Benchmark Email ou SendGrid. La migration est simple -- exportez les adresses email et les dates de consentement de la table dtb_customer d'EC-CUBE et importez dans votre nouvelle plateforme.

Combien de temps prend la migration de données réelle ?

L'exécution du script de migration elle-même est généralement rapide -- quelques heures pour la plupart des boutiques. La partie qui prend du temps est la construction et le test des scripts de migration, la validation de l'intégrité des données et la gestion des cas limites (produits avec des images manquantes, clients avec des formats d'email invalides, commandes avec des statuts personnalisés). Pour une boutique avec 3,000 produits et 50,000 clients, attendez 2-3 semaines de temps de développement et de test de migration.