EC-CUBE zu Shopify + Next.js Migration: Japanischer E-Commerce Leitfaden 2026
EC-CUBE zu Shopify + Next.js Migration: Japanischer E-Commerce Guide 2026
Wenn Sie einen EC-CUBE-Shop in Japan betreiben und die Schmerzen der Verwaltung eines selbst gehosteten PHP-Monolithen spüren, sind Sie nicht allein. Wir haben in den letzten zwei Jahren mehrere japanische E-Commerce-Unternehmen von EC-CUBE (Versionen 2.x, 3.x und 4.x) zu Headless-Shopify-Storefronts migriert, die mit Next.js gebaut wurden. Jedes einzelne hat danach das Gleiche gesagt: "Wir hätten das früher tun sollen."
Aber hier ist der Punkt -- diese Migration ist wirklich komplex. EC-CUBE hat tiefe Wurzeln in der japanischen Handelskultur. Es verarbeitet Dinge wie Furigana-Felder in Adressen, japanische Zahlungsmethoden (Konbini-Zahlungen, Carrier Billing, Banküberweis via Pay-easy) und Versandberechnungen basierend auf Japan Post-Zonen. Sie können nicht einfach einen Schalter umlegen und zu Shopify wechseln. Sie brauchen eine Strategie.
Dieser Leitfaden ist das Strategiedokument, das ich mir gewünscht hätte, als wir unsere erste EC-CUBE-Migration Anfang 2024 durchgeführt haben.

Inhaltsverzeichnis
- Warum 2026 von EC-CUBE migrieren
- Die EC-CUBE-Architektur verstehen
- Warum Shopify Plus + Next.js für japanischen E-Commerce
- Vorbereitung: Audit und Planung
- Datenmigrationsstrategie
- Umgang mit japanischen Zahlungsmethoden
- Versand- und Fulfillment-Zuordnung
- Aufbau des Next.js Storefront
- SEO-Migration und URL-Erhaltung
- Japanspezifische UX-Überlegungen
- Performance-Benchmarks: EC-CUBE vs. Headless Shopify
- Zeitplan und Kostenerwartungen
- Häufig gestellte Fragen
Warum 2026 von EC-CUBE migrieren
EC-CUBE ist seit fast zwei Jahrzehnten das Rückgrat des japanischen E-Commerce. Von Lockon Co., Ltd. (jetzt EC-CUBE Co., Ltd.) entwickelt, dominierte es den japanischen Markt, als die Optionen begrenzt waren. Aber die Landschaft hat sich dramatisch verschoben.
Hier ist, was Unternehmen zum Weggehen treibt:
Die Sicherheitswartung ist ein Albtraum. EC-CUBE 2.x hat das Ende seiner Lebensdauer vor Jahren erreicht, aber eine überraschende Anzahl von Shops führt es immer noch aus. Selbst EC-CUBE 4.x erfordert konstante Patches. Allein 2024 gab es drei kritische Sicherheitshinweise für EC-CUBE 4, einschließlich einer SQL-Injection-Anfälligkeit (CVE-2024-22345), die Tausende von Shops beeinträchtigte. Wenn Sie selbst hosten, ist das Ihr Problem zu beheben.
Die PHP-Hosting-Kosten steigen weiter. Wenn Sie EC-CUBE auf einem VPS oder dedizierten Server in Japan betreiben (typischerweise auf Sakura Internet, XSERVER oder AWS Tokyo), zahlen Sie für Infrastruktur, SSL-Zertifikate, Datenbankwartung und Serverüberwachung. Ein typischer mittelgroßer EC-CUBE-Shop gibt ¥50.000–¥200.000/Monat allein für Hosting und Wartung aus.
Das Plugin-Ökosystem schrumpft. Der EC-CUBE-Plugin-Marktplatz verliert Entwickler. Viele beliebte Zahlungs- und Versand-Plugins wurden nicht für EC-CUBE 4.2+ aktualisiert. Wenn Ihr Shop auf Plugins von Drittanbietern angewiesen ist, könnten Sie auf einer alten Version feststecken, ohne Upgrade-Pfad.
Mobile Performance ist schlecht. Die meisten EC-CUBE-Designs wurden in der reaktionsschnellen, aber schweren Ära entwickelt. Durchschnittliche Lighthouse-Scores für EC-CUBE-Shops, die wir auditiert haben, liegen bei etwa 25-40 auf mobilen Geräten. Das wird nicht ausreichen, wenn Core Web Vitals Ihre Google-Rankings in Japan direkt beeinflussen.
Die EC-CUBE-Architektur verstehen
Bevor Sie migrieren können, müssen Sie verstehen, woher Sie migrieren. Die EC-CUBE-Architektur unterscheidet sich erheblich je nach Version:
| Funktion | EC-CUBE 2.x | EC-CUBE 3.x | EC-CUBE 4.x |
|---|---|---|---|
| Framework | Custom PHP | Silex (Symfony-Micro) | Symfony 4/5 |
| Datenbank | PostgreSQL/MySQL | PostgreSQL/MySQL | PostgreSQL/MySQL |
| Template Engine | Smarty | Twig | Twig |
| Plugin-Architektur | Hooks/Overrides | Event-basiert | Symfony Bundles |
| ORM | Custom | Doctrine | Doctrine |
| API | Keine (benutzerdefinierte Builds) | Limitiertes REST | REST + limitiertes GraphQL |
Das Datenbankschema ist dort, wo es interessant (und schmerzhaft) wird. EC-CUBE speichert Produktdaten, Kundendaten und Bestellhistorie in einem normalisierten, aber EC-CUBE-spezifischen Schema. Die Tabellen dtb_product, dtb_product_class, dtb_customer und dtb_order sind die wichtigsten, die Sie extrahieren müssen.
EC-CUBE 4.x verwendet Doctrine-Entitäten, was die Datenextraktion etwas sauberer macht. Aber wenn Sie auf 2.x sind, bereiten Sie sich auf Raw-SQL-Exporte mit Kodierungsproblemen vor (Shift-JIS oder EUC-JP Legacy-Daten sind immer noch verbreitet).

Warum Shopify Plus + Next.js für japanischen E-Commerce
Ich will ehrlich sein: Shopify ist nicht die einzige Option. Sie könnten zu anderen Plattformen wie commercetools, Medusa oder sogar einer neueren japanischen Plattform wie BASE oder STORES.jp migrieren. Aber für mittelgroße bis große japanische E-Commerce-Operationen trifft Shopify Plus kombiniert mit einem Headless-Next.js-Frontend einen süßen Punkt.
Shopifys Präsenz in Japan ist ausgereifter geworden. Seit der Eröffnung ihres Tokio-Büros und dem Start der vollständigen Unterstützung der japanischen Sprache hat Shopify die meisten Japan-spezifischen Lücken behoben. Shopify Payments unterstützt jetzt nativ JCB-Karten. Die Admin-Oberfläche ist vollständig lokalisiert. Und kritisch, Shopify Plus unterstützt japanische Steuerberechnungen einschließlich des 軽減税率 (reduzierter Steuersatz) Systems für Lebensmittel und Getränke.
Next.js gibt Ihnen den Performance-Vorteil. Ein Headless-Storefront, das mit Next.js gebaut ist (mit der Shopify Storefront API oder dem zugrunde liegenden Datenlayer von Hydrogen), lässt Sie statische und servergerundete Seiten von der Edge bedienen. Wir sehen routinemäßig Lighthouse Performance-Scores von 90+ auf Mobilgeräten für unsere Next.js Shopify Builds. Das ist ein massiver Sprung von EC-CUBEs typischen Score von 30-etwas.
Die Storefront API verarbeitet die Komplexität. Shopifys Storefront API (Version 2025-04 ab diesem Schreiben) unterstützt Metafields, lokalisierte Inhalte, Multi-Währung und benutzerdefinierte Produktoptionen -- alles, was Sie brauchen, um EC-CUBEs Flexibilität zu replizieren.
Wenn Sie evaluieren, ob eine Next.js-basierte Headless-Architektur für Ihren spezifischen Store sinnvoll ist, kommt die Antwort fast immer auf Ihre Katalogsgröße und Anpassungsanforderungen an. Unter 100 Produkten mit einfachen Varianten? Standard-Shopify-Theme könnte ausreichen. Komplexe Produktkonfigurationen, umfangreiche Anpassung oder mehrere Storefronts? Gehen Sie Headless.
Vorbereitung: Audit und Planung
Berühren Sie keine Codezeile, bis Sie dieses Audit abgeschlossen haben:
1. Katalog-Komplexitätsmapping
Dokumentieren Sie jeden Produkttyp, jede Variantenstruktur und jedes benutzerdefinierte Feld in Ihrem EC-CUBE-Shop. EC-CUBEs dtb_product_class-Tabelle kann komplexe Variantenkombinationen halten, die nicht 1:1 zu Shopifys Variantenmodell passen (das eine Grenze von 100 Varianten pro Produkt und eine 3-Optionslimit hat).
Wenn Sie Produkte mit mehr als 3 Optionstypen haben (z. B. Größe, Farbe, Material, Gravur), müssen Sie Shopifys Combined Listings Feature verwenden (eingeführt 2024) oder Ihre Produktarchitektur mithilfe von Metafields und Line Item Properties umstrukturieren.
2. Kundenbestands-Inventar
EC-CUBE speichert umfangreiche Kundendaten, einschließlich:
- 姓名 (Familienname/Vorname, separate Felder)
- フリガナ (Furigana für Namen)
- 郵便番号 (Postleitzahl mit Auto-Adressfüllung)
- Mehrere Versandadressen pro Kunde
- Kontoguthaben (ポイント)
- Kaufhistorie mit detailliertem Bestellstatus-Tracking
Shopifys Kundenmodell verarbeitet Namenfelder und mehrere Adressen nativ. Aber Punkte/Loyalitätsprogramme benötigen eine Lösung von Drittanbietern wie Smile.io oder ein benutzerdefiniertes metafield-basiertes System.
3. Integrationsbestands-Inventar
Erstellen Sie eine Liste aller externen Systeme, mit denen Ihr EC-CUBE-Shop verbunden ist:
- Zahlungsgateways (GMO Payment Gateway, SB Payment Service, PAY.JP)
- Versand-APIs (Yamato Transport, Sagawa Express, Japan Post)
- Buchhaltungssoftware (弥生会計, freee, MoneyForward)
- Inventar-/ERP-Systeme
- E-Mail-Marketing (Mailchimp, SendGrid, oder japanische Services wie Benchmark Email)
4. URL-Strukturdokumentation
Exportieren Sie jede URL aus Ihrem EC-CUBE-Shop. Dies ist für die SEO-Migration kritisch. EC-CUBEs Standard-URL-Muster sehen so aus:
/products/detail/{product_id}
/products/list?category_id={id}
/mypage/
/cart/
Sie benötigen Umleitungszuordnungen für alle diese.
Datenmigrationsstrategie
Hier ist die Migrationspipeline, die wir verwenden:
Produktdaten-Export
Für EC-CUBE 4.x können Sie Doctrines CLI-Tools verwenden oder einen Symfony-Befehl schreiben, um Produkte als JSON zu exportieren:
// EC-CUBE 4.x Produktexport-Befehl
$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()),
];
}
Für EC-CUBE 2.x sehen Sie sich Raw-SQL an:
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;
Achten Sie auf die Zeichenkodierung. Wenn Ihre EC-CUBE 2.x-Datenbank EUC-JP verwendet, konvertieren Sie zu UTF-8, bevor Sie irgendwohin importieren:
mysqldump --default-character-set=eucjpms your_db | iconv -f EUC-JP -t UTF-8 > export_utf8.sql
Import zu Shopify
Verwenden Sie Shopifys Admin API (REST oder GraphQL), um Produkte programmatisch zu erstellen. Die productCreate-Mutation in GraphQL ist Ihr bester Freund hier:
mutation productCreate($input: ProductInput!) {
productCreate(input: $input) {
product {
id
title
variants(first: 100) {
edges {
node {
id
sku
}
}
}
}
userErrors {
field
message
}
}
}
Bauen Sie ein Migrations-Skript in Node.js oder Python, das Ihre exportierten EC-CUBE-Daten liest und Shopify-Produkte erstellt. Integrieren Sie Rate Limiting -- Shopifys API hat eine Grenze von 2 Anfragen/Sekunde für REST und eine kostenbasierte Grenze für GraphQL.
Kundenmigration
Der Import von Shopify-Kunden über die API funktioniert gut, aber beachten Sie, dass Sie Passwörter nicht migrieren können. Alle Kunden müssen ihre Passwörter nach der Migration zurücksetzen. Senden Sie eine gut gestaltete E-Mail (auf Japanisch, natürlich) mit einer Erklärung der Migration und einem Passwort-Reset-Link.
Für die Kundendaten selbst ordnen Sie EC-CUBE-Felder zu Shopify zu:
| EC-CUBE-Feld | Shopify-Feld | Anmerkungen |
|---|---|---|
| name01 (姓) | last_name | Für Japanisch umgekehrt |
| name02 (名) | first_name | Für Japanisch umgekehrt |
| kana01 (セイ) | metafield | Kein natives Furigana-Feld |
| kana02 (メイ) | metafield | Kein natives Furigana-Feld |
| Direkte Zuordnung | ||
| point | metafield oder Loyalitäts-App | Benötigt benutzerdefinierte Verarbeitung |
| addr01 (都道府県) | province | Mit Shopify-Provinzcodes zuordnen |
| addr02 (市区町村) | city + address1 | Kann Verkettung benötigen |
Bestellhistorie
Die Migration historischer Bestellungen ist optional, wird aber zur Kontinuität des Kundendiensts empfohlen. Verwenden Sie Shopifys Order API, um Bestellungen mit "financial_status": "paid" und "fulfillment_status": "fulfilled" für abgeschlossene Bestellungen zu erstellen.
Umgang mit japanischen Zahlungsmethoden
Hier wird es knifflig. Japanische Verbraucher erwarten bestimmte Zahlungsoptionen, die nicht Standard im westlichen E-Commerce sind.
Shopify Payments unterstützt jetzt Kreditkarten einschließlich JCB, Visa, Mastercard und American Express in Japan. Die Bearbeitungsgebühren betragen 3,25%–3,4% + ¥0 pro Transaktion für Shopify Plus.
Für andere Zahlungsmethoden:
| Zahlungsmethode | Lösung auf Shopify | Anmerkungen |
|---|---|---|
| コンビニ決済 (Convenience Store) | KOMOJU, GMO Payment Gateway App | Essentiell für ~15% der japanischen Online-Bestellungen |
| 代引き (Nachnahme) | Shopify Native COD | Built-in, funktioniert gut |
| 銀行振込 (Banküberweisung) | Manuelle Zahlungsmethode | Shopify unterstützt dies nativ |
| キャリア決済 (Carrier-Abrechnung) | KOMOJU | docomo, au, SoftBank |
| PayPay | PayPay für Shopify App | Japans beliebteste QR-Zahlung |
| Amazon Pay | Amazon Pay App | Hohe Annahme in Japan |
| 後払い (Jetzt kaufen, später bezahlen) | Paidy, atone | Sehr beliebt in Japan |
KOMOJU verdient besondere Erwähnung. Es ist zum De-facto-Zahlungsgateway für Shopify-Shops in Japan geworden und unterstützt Konbini-Zahlungen, Banküberweisungen, Carrier Billing und mehr über eine einzige Integration. Ihre Shopify Plus-Integration ist solide und wir hatten damit keine größeren Probleme.
Versand- und Fulfillment-Zuordnung
EC-CUBE verwendet typischerweise Plugins für Yamato Transport (ヤマト運輸), Sagawa Express (佐川急便) und Japan Post (日本郵便). Diese Plugins verarbeiten die Generierung von Versandetiketten, die Integration von Trackingnummern und die Auswahl von Lieferzeitfenstern (配達時間指定).
Bei Shopify haben Sie mehrere Optionen:
- Ship&co -- In Japan gebaute Versand-App, die sich in alle großen japanischen Carrier integriert. Verarbeitet die Etikettendruck im richtigen Format.
- Shopify Shipping -- Begrenzte Unterstützung von Japan-Carriern ab 2025, aber verbessert sich.
- Custom Carrier Service API -- Bauen Sie Ihren eigenen Versandtarifrechner, wenn Sie komplexe zonenbasierte Preisgestaltung haben.
Die Auswahl des Lieferzeitfensters (午前中, 12-14時, 14-16時, usw.) ist entscheidend für japanische Kunden. Dies erfordert entweder eine benutzerdefinierte Checkout-Erweiterung auf Shopify Plus oder eine Drittanbieter-App wie 配送日時指定 .amp.
Aufbau des Next.js Storefront
Für das Frontend verwenden wir Next.js 15 mit dem App Router und Server Components. Hier ist unser typischer Stack:
Next.js 15 (App Router)
├── Shopify Storefront API (GraphQL)
├── next-intl (für japanische i18n)
├── Tailwind CSS 4
├── Framer Motion (Animationen)
└── Vercel (Deployment, Tokio-Region Edge)
Ein paar Dinge, die wir beim Bauen japanischer Storefronts mit Next.js gelernt haben:
Schriftoptimierung
Japanische Web-Fonts sind schwer. Noto Sans JP Standardgewicht allein ist ~1,8 MB. Verwenden Sie next/font mit subsets und berücksichtigen Sie variable Fonts:
import { Noto_Sans_JP } from 'next/font/google';
const notoSansJP = Noto_Sans_JP({
subsets: ['latin'],
weight: ['400', '500', '700'],
display: 'swap',
preload: true,
});
Noch besser, verwenden Sie font-display: optional für nicht-kritischen Text und bedienen Sie einen System-Font-Stack als Fallback: "Hiragino Kaku Gothic ProN", "Hiragino Sans", Meiryo, sans-serif.
Server Components für Produktseiten
Rufen Sie Produktdaten in Server Components ab, um Client-seitige Ladezustände zu eliminieren:
// 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>
);
}
Wir bauen alle unsere Headless-Shopify-Storefronts mit diesem Muster, und der Performance-Unterschied gegenüber einem traditionellen Liquid-Theme oder sogar Hydrogen ist spürbar.
SEO-Migration und URL-Erhaltung
Dies ist der Teil, der mich bei Migrationsprojekten nachts wach hält. Japanische E-Commerce-Shops haben oft Jahre angesammeltes SEO-Guthaben, und eine fehlerhafte Migration kann den organischen Traffic für Monate senken.
Umleitungsstrategie
Erstellen Sie eine vollständige Umleitungszuordnung. Jede. Einzelne. URL. Verwenden Sie Next.js' next.config.js-Umleitungen für statische Muster:
// 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,
},
];
},
};
Für dynamische Umleitungen (Zuordnung von EC-CUBE-Produkt-IDs zu Shopify-Handles), verwenden Sie Middleware oder eine Umleitungs-Lookup-Tabelle, die in einer Datenbank oder KV-Speicher gespeichert ist.
Strukturierte Daten
EC-CUBE-Shops haben selten richtige strukturierte Daten. Nutzen Sie diese Gelegenheit, um Product, BreadcrumbList, Organization und FAQPage Schema zu implementieren. Japanische Google SERPs zeigen stark rich results.
Japanische SEO-Besonderheiten
- Halten Sie Ihre Title Tags unter 30 Zeichen auf Japanisch (nicht 60 wie Englisch)
- Meta-Beschreibungen: 80-120 japanische Zeichen
- Sorgen Sie für richtige
hreflang-Tags, wenn Sie mehrsprachige Seiten haben - Sitemap an Google Search Console und Bing Webmaster Tools einreichen (Bing hat einen bedeutenden Marktanteil in Japan)
Japanspezifische UX-Überlegungen
Japanischer E-Commerce UX hat kulturelle Unterschiede, die westliche Entwickler oft übersehen:
- Informationsdichte -- Japanische Verbraucher erwarten mehr Produktinformationen, die auf der Seite sichtbar sind. Minimieren Sie nicht übermäßig.
- Vertrauenssignale -- Zeigen Sie Versandrichtlinien, Rückgaberichtlinien und Unternehmensinformationen prominent an. Japanische Käufer recherchieren gründlich.
- Postleitzahl-Autofüllung -- Implementieren Sie 郵便番号 → Adress-Autovervollständigung mit der Japan Post API oder einer Bibliothek wie
zipaddress.js. - Ehrenhafter Sprachgebrauch -- Verwenden Sie angemessenes Keigo (敬語) in UI-Kopien. Lässiger Sprachgebrauch kann sich respektlos anfühlen.
- LINE-Messaging-Integration -- LINE hat 96 Millionen monatlich aktive Benutzer in Japan. Integrieren Sie LINE Login und LINE-Benachrichtigungen.
Performance-Benchmarks: EC-CUBE vs. Headless Shopify
Hier sind echte Daten aus einer Migration, die wir Q1 2025 für einen japanischen Modehändler abgeschlossen haben (~3.000 SKUs):
| Metrik | EC-CUBE 4.2 (Vorher) | Next.js + Shopify (Nachher) | Verbesserung |
|---|---|---|---|
| Lighthouse Performance (Mobilgeräte) | 34 | 92 | +170% |
| LCP | 4,8 s | 1,2 s | -75% |
| FID/INP | 380 ms | 45 ms | -88% |
| CLS | 0,24 | 0,02 | -92% |
| Time to First Byte | 1,8 s | 0,18 s | -90% |
| Seitengröße (Produktseite) | 3,2 MB | 680 KB | -79% |
| Umwandlungsrate | 1,8% | 2,9% | +61% |
| Monatliche Hosting-Kosten | ¥180.000 | ¥45.000 | -75% |
Die Verbesserung der Umwandlungsrate allein zahlte die gesamte Migration innerhalb von drei Monaten. Nicht jedes Projekt sieht so dramatische Zahlen, aber Performance-Verbesserungen dieser Größenordnung bewegen konsistent die Nadel.
Zeitplan und Kostenerwartungen
Lassen Sie uns realistisch über das sein, was diese Migration kostet:
| Shop-Größe | Produkte | Zeitplan | Budget-Bereich (¥) |
|---|---|---|---|
| Klein | <500 | 8-12 Wochen | ¥3.000.000-5.000.000 |
| Mittel | 500-5.000 | 12-20 Wochen | ¥5.000.000-12.000.000 |
| Groß | 5.000+ | 20-32 Wochen | ¥12.000.000-25.000.000+ |
Diese Bereiche beinhalten Design, Entwicklung, Datenmigration, QA und Launch-Unterstützung. Sie gehen davon aus, dass Sie mit einem erfahrenen Team arbeiten. Wenn Ihr Team noch keine japanische E-Commerce-Migration durchgeführt hat, fügen Sie 30-50% zu Zeitplan und Budget für Lernkurven hinzu.
Die laufenden monatlichen Kosten nach der Migration sehen typischerweise so aus:
- Shopify Plus: $2.300/Monat (~¥345.000)
- Vercel Pro: $20/Monat pro Teamlied
- KOMOJU: Nur Transaktionsgebühren
- Ship&co: ¥2.000/Monat Basis
- Gesamt: ~¥380.000-450.000/Monat vs. ¥400.000-800.000/Monat für selbst gehostetes EC-CUBE mit gleichwertigen Funktionen
Für einen transparenten Blick darauf, wie wir die Projektpreisgestaltung strukturieren, sehen Sie sich unsere Preisseite an.
Häufig gestellte Fragen
Kann ich direkt von EC-CUBE 2.x zu Shopify + Next.js migrieren? Ja, aber EC-CUBE 2.x-Migrationen sind komplexer aufgrund des älteren Datenbankschemas, möglicher Shift-JIS/EUC-JP-Kodierungsprobleme und des Fehlens eines modernen ORM. Budgetieren Sie zusätzliche Zeit für Datenbereinigung und Transformation. Wir empfehlen, zuerst in ein neutrales Format (CSV oder JSON in UTF-8) zu exportieren, dann Import-Skripte für Shopify zu bauen.
Werde ich meine Google-Rankings verlieren, wenn ich von EC-CUBE migriere? Nicht, wenn Sie Umleitungen richtig verarbeiten. Implementieren Sie 301-Umleitungen für jede URL, erhalten Sie Ihr XML-Sitemap und behalten Sie Ihre Title Tags und Meta-Beschreibungen konsistent. Erwarten Sie eine vorübergehende Schwankung (2-4 Wochen), während Google erneut durchsucht, aber Rankings sollten sich erholen und sich typischerweise aufgrund besserer Core Web Vitals Scores verbessern.
Unterstützt Shopify japanische Steuerberechnung einschließlich reduzierter Steuersätze? Ja. Shopify unterstützt Japans Verbrauchssteuersystem einschließlich der 軽減税率 (8% reduzierter Satz für Lebensmittel und Getränke gegenüber dem Standard-10%-Satz). Sie können Steuersätze pro Produktkollektion konfigurieren und Shopify verarbeitet die Berechnung einschließlich Rechnungsausgaben-Anforderungen (インボイス制度).
Wie verarbeite ich EC-CUBEs Punktsystem nach der Migration zu Shopify? Shopify hat kein natives Punktsystem equivalent zu EC-CUBEs eingebautem ポイント-Feature. Ihre beste Optionen sind Smile.io (unterstützt Japanisch), LoyaltyLion oder eine benutzerdefinierte Lösung mit Shopify Metafields und einer serverless Funktion. Für vorhandene Punktguthaben, migrieren Sie diese als Metafields auf Kundendatensätzen und bauen Sie einen Rückzahlungsflow in Ihr Next.js Checkout.
Ist Hydrogen besser als Next.js für einen Headless-Shopify-Storefront? Das kommt darauf an. Hydrogen (Shopifys React-Framework auf Basis von Remix) ist eng mit Shopify integriert und gibt Ihnen einige schöne eingebaute Commerce-Primitive. Aber Next.js hat ein viel größeres Ökosystem, mehr Community-Ressourcen, bessere Edge-Runtime-Unterstützung auf Vercel und mehr Flexibilität, wenn Sie jemals Commerce-Backends wechseln möchten. Für japanischen E-Commerce spezifisch, geben Next.js' Middleware-Fähigkeiten und i18n-Routing ihm einen Vorteil. Wir haben mit beiden gebaut und bevorzugen Next.js für die meisten Projekte -- sehen Sie sich unsere Next.js-Entwicklungsfähigkeiten an.
Kann ich EC-CUBE und den neuen Shopify-Shop während der Migration parallel betreiben? Absolut, und wir empfehlen es. Betreiben Sie beide Systeme gleichzeitig für 2-4 Wochen. Verwenden Sie Ihr DNS oder einen Reverse Proxy, um Traffic schrittweise zu verschieben. Dies lässt Sie validieren, dass Bestellungen richtig fließen, Zahlungen korrekt verarbeitet werden und der Bestand synchron bleibt, bevor Sie vollständig überschalten.
Was ist mit EC-CUBEs Mail Magazine (メールマガジン) Feature?
EC-CUBE hat ein eingebautes E-Mail-Newsletter-System, auf das sich viele Shops verlassen. Migrieren Sie Ihre Abonnentenliste auf eine dedizierte E-Mail-Marketing-Plattform wie Klaviyo (die ausgezeichnete Shopify-Integration hat), oder wenn Sie Unterstützung für Japanisch und Vorlagen benötigen, berücksichtigen Sie Benchmark Email oder SendGrid. Die Migration ist unkompliziert -- exportieren Sie E-Mail-Adressen und Zustimmungsdaten aus EC-CUBEs dtb_customer Tabelle und importieren Sie auf Ihre neue Plattform.
Wie lange dauert die tatsächliche Datenmigration? Die Migrationsskript-Ausführung selbst ist normalerweise schnell -- ein paar Stunden für die meisten Shops. Der zeitaufwändige Teil ist das Bauen und Testen der Migrationsskripte, das Validieren von Datenintegrität und das Verarbeiten von Edge Cases (Produkte mit fehlenden Bildern, Kunden mit ungültigen E-Mail-Formaten, Bestellungen mit benutzerdefinierten Status). Für einen Shop mit 3.000 Produkten und 50.000 Kunden, erwarten Sie 2-3 Wochen Migrationsentwicklung und Testzeit.