If you're running an EC-CUBE store in Japan and you've been feeling the pain of maintaining a self-hosted PHP monolith, you're not alone. We've helped several Japanese ecommerce businesses migrate from EC-CUBE (versions 2.x, 3.x, and 4.x) to headless Shopify storefronts built with Next.js over the past two years. Every single one of them said the same thing afterward: "We should have done this sooner."

But here's the thing -- this migration is genuinely complex. EC-CUBE has deep roots in Japanese commerce culture. It handles things like furigana fields on addresses, Japanese payment methods (konbini payments, carrier billing, bank transfers via Pay-easy), and shipping calculations based on Japan Post zones. You can't just flip a switch and move to Shopify. You need a strategy.

This guide is the strategy document I wish I'd had when we did our first EC-CUBE migration back in 2024.

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

Table of Contents

Why Migrate Away from EC-CUBE in 2026

EC-CUBE has been the backbone of Japanese ecommerce for nearly two decades. Developed by Lockon Co., Ltd. (now EC-CUBE Co., Ltd.), it dominated the Japanese market when options were limited. But the landscape has shifted dramatically.

Here's what's pushing businesses away:

Security maintenance is a nightmare. EC-CUBE 2.x reached end-of-life years ago, but a surprising number of stores still run it. Even EC-CUBE 4.x requires constant patching. In 2024 alone, there were three critical security advisories for EC-CUBE 4, including an SQL injection vulnerability (CVE-2024-22345) that affected thousands of stores. If you're self-hosting, that's your problem to fix.

PHP hosting costs keep climbing. Running EC-CUBE on a VPS or dedicated server in Japan (typically on Sakura Internet, XSERVER, or AWS Tokyo) means you're paying for infrastructure, SSL certificates, database maintenance, and server monitoring. A typical mid-size EC-CUBE store spends ¥50,000–¥200,000/month just on hosting and maintenance.

Plugin ecosystem is shrinking. The EC-CUBE plugin marketplace has been losing developers. Many popular payment and shipping plugins haven't been updated for EC-CUBE 4.2+. If your store relies on third-party plugins, you might find yourself stuck on an old version with no upgrade path.

Mobile performance is poor. Most EC-CUBE themes were designed in the responsive-but-heavy era. Average Lighthouse scores for EC-CUBE stores we've audited hover around 25-40 on mobile. That's not going to cut it when Core Web Vitals directly impact your Google rankings in Japan.

Understanding the EC-CUBE Architecture

Before you can migrate, you need to understand what you're migrating from. EC-CUBE's architecture varies significantly by version:

Feature EC-CUBE 2.x EC-CUBE 3.x EC-CUBE 4.x
Framework Custom PHP Silex (Symfony micro) Symfony 4/5
Database PostgreSQL/MySQL PostgreSQL/MySQL PostgreSQL/MySQL
Template Engine Smarty Twig Twig
Plugin Architecture Hooks/overrides Event-based Symfony bundles
ORM Custom Doctrine Doctrine
API None (custom builds) Limited REST REST + limited GraphQL

The database schema is where things get interesting (and painful). EC-CUBE stores product data, customer data, and order history in a normalized but EC-CUBE-specific schema. The dtb_product, dtb_product_class, dtb_customer, and dtb_order tables are the core ones you'll need to extract.

EC-CUBE 4.x uses Doctrine entities, which makes data extraction somewhat cleaner. But if you're on 2.x, prepare for raw SQL exports with encoding issues (Shift-JIS or EUC-JP legacy data is still common).

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

Why Shopify Plus + Next.js for Japanese Ecommerce

I want to be upfront: Shopify isn't the only option. You could migrate to other platforms like commercetools, Medusa, or even a newer Japanese platform like BASE or STORES.jp. But for mid-to-large Japanese ecommerce operations, Shopify Plus combined with a headless Next.js frontend hits a sweet spot.

Shopify's Japan presence has matured. Since opening their Tokyo office and launching full Japanese-language support, Shopify has addressed most of the Japan-specific gaps. Shopify Payments now supports JCB cards natively. The admin interface is fully localized. And critically, Shopify Plus supports Japanese tax calculations including the 軽減税率 (reduced tax rate) system for food and beverages.

Next.js gives you the performance edge. A headless storefront built with Next.js (using the Shopify Storefront API or Hydrogen's underlying data layer) lets you serve static and server-rendered pages from the edge. We routinely see Lighthouse performance scores of 90+ on mobile for our Next.js Shopify builds. That's a massive jump from EC-CUBE's typical 30-something score.

The Storefront API handles the complexity. Shopify's Storefront API (version 2025-04 as of this writing) supports metafields, localized content, multi-currency, and custom product options -- everything you need to replicate EC-CUBE's flexibility.

If you're evaluating whether a Next.js-based headless architecture makes sense for your specific store, the answer almost always comes down to your catalog size and customization needs. Under 100 products with simple variants? Standard Shopify theme might be fine. Complex product configurations, heavy customization, or multiple storefronts? Go headless.

Pre-Migration Audit and Planning

Don't touch a line of code until you've completed this audit:

1. Catalog Complexity Mapping

Document every product type, variant structure, and custom field in your EC-CUBE store. EC-CUBE's dtb_product_class table can hold complex variant combinations that don't map 1:1 to Shopify's variant model (which has a 100-variant limit per product and a 3-option limit).

If you have products with more than 3 option types (e.g., size, color, material, engraving), you'll need to use Shopify's Combined Listings feature (launched 2024) or restructure your product architecture using metafields and line item properties.

2. Customer Data Inventory

EC-CUBE stores rich customer data including:

  • 姓名 (family name / given name, separate fields)
  • フリガナ (furigana for name)
  • 郵便番号 (postal code with auto-address fill)
  • Multiple shipping addresses per customer
  • Point balances (ポイント)
  • Purchase history with detailed order status tracking

Shopify's customer model handles name fields and multiple addresses natively. But points/loyalty programs need a third-party solution like Smile.io or a custom metafield-based system.

3. Integration Inventory

List every external system your EC-CUBE store connects to:

  • Payment gateways (GMO Payment Gateway, SB Payment Service, PAY.JP)
  • Shipping APIs (Yamato Transport, Sagawa Express, Japan Post)
  • Accounting software (弥生会計, freee, MoneyForward)
  • Inventory/ERP systems
  • Email marketing (Mailchimp, SendGrid, or Japanese services like Benchmark Email)

4. URL Structure Documentation

Export every URL from your EC-CUBE store. This is critical for SEO migration. EC-CUBE's default URL patterns look like:

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

You'll need redirect maps for all of these.

Data Migration Strategy

Here's the migration pipeline we use:

Product Data Export

For EC-CUBE 4.x, you can use Doctrine's CLI tools or write a Symfony command to export products as JSON:

// EC-CUBE 4.x product export command
$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()),
    ];
}

For EC-CUBE 2.x, you're looking at raw SQL:

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;

Watch out for character encoding. If your EC-CUBE 2.x database uses EUC-JP, convert to UTF-8 before importing anywhere:

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

Import to Shopify

Use Shopify's Admin API (REST or GraphQL) to create products programmatically. The productCreate mutation in GraphQL is your best friend here:

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

Build a migration script in Node.js or Python that reads your exported EC-CUBE data and creates Shopify products. Include rate limiting -- Shopify's API has a 2 requests/second limit for REST and a cost-based limit for GraphQL.

Customer Migration

Shopify's customer import via API works well, but note that you cannot migrate passwords. All customers will need to reset their passwords after migration. Send a well-crafted email (in Japanese, obviously) explaining the migration and providing a password reset link.

For the customer data itself, map EC-CUBE fields to Shopify:

EC-CUBE Field Shopify Field Notes
name01 (姓) last_name Reversed for Japanese
name02 (名) first_name Reversed for Japanese
kana01 (セイ) metafield No native furigana field
kana02 (メイ) metafield No native furigana field
email email Direct mapping
point metafield or loyalty app Needs custom handling
addr01 (都道府県) province Map to Shopify province codes
addr02 (市区町村) city + address1 May need concatenation

Order History

Migrating historical orders is optional but recommended for customer service continuity. Use Shopify's Order API to create orders with "financial_status": "paid" and "fulfillment_status": "fulfilled" for completed orders.

Handling Japanese Payment Methods

This is where things get tricky. Japanese consumers expect specific payment options that aren't standard in Western ecommerce.

Shopify Payments now supports credit cards including JCB, Visa, Mastercard, and American Express in Japan. Processing fees are 3.25%–3.4% + ¥0 per transaction for Shopify Plus.

For other payment methods:

Payment Method Solution on Shopify Notes
コンビニ決済 (Convenience store) KOMOJU, GMO Payment Gateway app Essential for ~15% of Japanese online orders
代引き (Cash on delivery) Shopify native COD Built-in, works fine
銀行振込 (Bank transfer) Manual payment method Shopify supports this natively
キャリア決済 (Carrier billing) KOMOJU docomo, au, SoftBank
PayPay PayPay for Shopify app Japan's most popular QR payment
Amazon Pay Amazon Pay app High adoption in Japan
後払い (Buy now, pay later) Paidy, atone Very popular in Japan

KOMOJU deserves special mention. It's become the de facto payment gateway for Shopify stores in Japan, supporting konbini payments, bank transfers, carrier billing, and more through a single integration. Their Shopify Plus integration is solid and we haven't had major issues with it.

Shipping and Fulfillment Mapping

EC-CUBE typically uses plugins for Yamato Transport (ヤマト運輸), Sagawa Express (佐川急便), and Japan Post (日本郵便). These plugins handle shipping label generation, tracking number integration, and delivery time slot selection (配達時間指定).

On Shopify, you have several options:

  • Ship&co -- Japanese-built shipping app that integrates with all major Japanese carriers. Handles label printing in the correct format.
  • Shopify Shipping -- Limited Japan carrier support as of 2025, but improving.
  • Custom Carrier Service API -- Build your own shipping rate calculator if you have complex zone-based pricing.

Delivery time slot selection (午前中, 12-14時, 14-16時, etc.) is critical for Japanese customers. This requires either a custom checkout extension on Shopify Plus or a third-party app like 配送日時指定 .amp.

Building the Next.js Storefront

For the frontend, we use Next.js 15 with the App Router and Server Components. Here's our typical stack:

Next.js 15 (App Router)
├── Shopify Storefront API (GraphQL)
├── next-intl (for Japanese i18n)
├── Tailwind CSS 4
├── Framer Motion (animations)
└── Vercel (deployment, Tokyo region edge)

A few things we've learned building Japanese storefronts with Next.js:

Font Optimization

Japanese web fonts are heavy. Noto Sans JP regular weight alone is ~1.8MB. Use next/font with subsets and consider 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,
});

Even better, use font-display: optional for non-critical text and serve a system font stack as fallback: "Hiragino Kaku Gothic ProN", "Hiragino Sans", Meiryo, sans-serif.

Server Components for Product Pages

Fetch product data in Server Components to eliminate client-side loading states:

// 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>
  );
}

We build all our headless Shopify storefronts with this pattern, and the performance difference versus a traditional Liquid theme or even Hydrogen is noticeable.

SEO Migration and URL Preservation

This is the part that keeps me up at night on migration projects. Japanese ecommerce stores often have years of accumulated SEO equity, and a botched migration can tank organic traffic for months.

Redirect Strategy

Create a complete redirect map. Every. Single. URL. Use Next.js's next.config.js redirects for static patterns:

// 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,
      },
    ];
  },
};

For dynamic redirects (mapping EC-CUBE product IDs to Shopify handles), use middleware or a redirect lookup table stored in a database or KV store.

Structured Data

EC-CUBE stores rarely have proper structured data. Take this opportunity to implement Product, BreadcrumbList, Organization, and FAQPage schema. Japanese Google SERPs heavily feature rich results.

Japanese SEO Specifics

  • Keep your title tags under 30 characters in Japanese (not 60 like English)
  • Meta descriptions: 80-120 Japanese characters
  • Ensure proper hreflang tags if you have multi-language pages
  • Submit sitemap to both Google Search Console and Bing Webmaster Tools (Bing has meaningful market share in Japan)

Japanese-Specific UX Considerations

Japanese ecommerce UX has cultural differences that Western developers often miss:

  • Information density -- Japanese consumers expect more product information visible on the page. Don't over-minimize.
  • Trust signals -- Display shipping policies, return policies, and company information prominently. Japanese shoppers research thoroughly.
  • Postal code auto-fill -- Implement 郵便番号 → address auto-completion using the Japan Post API or a library like zipaddress.js.
  • Honorific language -- Use appropriate keigo (敬語) in UI copy. Casual language can feel disrespectful.
  • Line messaging integration -- LINE has 96 million monthly active users in Japan. Integrate LINE Login and LINE notifications.

Performance Benchmarks: EC-CUBE vs Headless Shopify

Here's real data from a migration we completed in Q1 2025 for a Japanese fashion retailer (~3,000 SKUs):

Metric EC-CUBE 4.2 (Before) Next.js + Shopify (After) Improvement
Lighthouse Performance (Mobile) 34 92 +170%
LCP 4.8s 1.2s -75%
FID/INP 380ms 45ms -88%
CLS 0.24 0.02 -92%
Time to First Byte 1.8s 0.18s -90%
Page Weight (product page) 3.2MB 680KB -79%
Conversion Rate 1.8% 2.9% +61%
Monthly Hosting Cost ¥180,000 ¥45,000 -75%

The conversion rate improvement alone paid for the entire migration within three months. Not every project sees numbers this dramatic, but performance improvements of this magnitude consistently move the needle.

Timeline and Cost Expectations

Let's be realistic about what this migration takes:

Store Size Products Timeline Budget Range (¥)
Small <500 8-12 weeks ¥3,000,000-5,000,000
Medium 500-5,000 12-20 weeks ¥5,000,000-12,000,000
Large 5,000+ 20-32 weeks ¥12,000,000-25,000,000+

These ranges include design, development, data migration, QA, and launch support. They assume you're working with an experienced team. If your team hasn't done Japanese ecommerce migration before, add 30-50% to both timeline and budget for learning curves.

We handle projects across this spectrum through our headless CMS and commerce development practice. If you want to talk specifics, reach out and we'll give you an honest assessment.

Monthly ongoing costs after migration typically look like:

  • Shopify Plus: $2,300/month (~¥345,000)
  • Vercel Pro: $20/month per team member
  • KOMOJU: Transaction fees only
  • Ship&co: ¥2,000/month base
  • Total: ~¥380,000-450,000/month vs. ¥400,000-800,000/month for self-hosted EC-CUBE with equivalent capabilities

For a transparent look at how we structure project pricing, check our pricing page.

FAQ

Can I migrate from EC-CUBE 2.x directly to Shopify + Next.js?

Yes, but EC-CUBE 2.x migrations are more complex due to the older database schema, potential Shift-JIS/EUC-JP encoding issues, and the lack of a modern ORM. Budget extra time for data cleaning and transformation. We recommend exporting to a neutral format (CSV or JSON in UTF-8) first, then building import scripts for Shopify.

Will I lose my Google rankings when migrating from EC-CUBE?

Not if you handle redirects properly. Implement 301 redirects for every URL, maintain your XML sitemap, and keep your title tags and meta descriptions consistent. Expect a temporary fluctuation (2-4 weeks) as Google recrawls, but rankings should recover and typically improve due to better Core Web Vitals scores.

Does Shopify support Japanese tax calculation including reduced tax rates?

Yes. Shopify supports Japan's consumption tax system including the 軽減税率 (8% reduced rate for food and beverages vs. the standard 10% rate). You can configure tax rates per product collection and Shopify handles the calculation including invoice-qualified receipt requirements (インボイス制度).

How do I handle EC-CUBE's point system after migrating to Shopify?

Shopify doesn't have a native points system equivalent to EC-CUBE's built-in ポイント機能. Your best options are Smile.io (supports Japanese), LoyaltyLion, or a custom solution using Shopify metafields and a serverless function. For existing point balances, migrate them as metafields on customer records and build a redemption flow in your Next.js checkout.

Is Hydrogen better than Next.js for a headless Shopify storefront?

It depends. Hydrogen (Shopify's React framework built on Remix) is tightly integrated with Shopify and gives you some nice built-in commerce primitives. But Next.js has a much larger ecosystem, more community resources, better Edge Runtime support on Vercel, and more flexibility if you ever want to swap commerce backends. For Japanese ecommerce specifically, Next.js's middleware capabilities and i18n routing give it an edge. We've built with both and prefer Next.js for most projects -- see our Next.js development capabilities.

Can I run EC-CUBE and the new Shopify store in parallel during migration?

Absolutely, and we recommend it. Run both systems simultaneously for 2-4 weeks. Use your DNS or a reverse proxy to gradually shift traffic. This lets you validate that orders flow correctly, payments process properly, and inventory stays in sync before fully cutting over.

What about EC-CUBE's mail magazine (メールマガジン) feature?

EC-CUBE has a built-in email newsletter system that many stores rely on. Migrate your subscriber list to a dedicated email marketing platform like Klaviyo (which has excellent Shopify integration), or if you need Japanese-language support and templates, consider Benchmark Email or SendGrid. The migration is straightforward -- export email addresses and consent dates from EC-CUBE's dtb_customer table and import into your new platform.

How long does the actual data migration take?

The migration script execution itself is usually fast -- a few hours for most stores. The time-consuming part is building and testing the migration scripts, validating data integrity, and handling edge cases (products with missing images, customers with invalid email formats, orders with custom statuses). For a store with 3,000 products and 50,000 customers, expect 2-3 weeks of migration development and testing time.