Se você está executando uma loja EC-CUBE no Japão e vem sentindo as dores de manter um monólito PHP auto-hospedado, você não está sozinho. Ajudamos vários negócios de ecommerce japonês a migrar do EC-CUBE (versões 2.x, 3.x e 4.x) para vitrines Shopify headless construídas com Next.js nos últimos dois anos. Todos eles disseram a mesma coisa depois: "Deveríamos ter feito isso mais cedo."

Mas aqui está o ponto -- essa migração é genuinamente complexa. EC-CUBE tem raízes profundas na cultura de comércio japonês. Ele lida com coisas como campos de furigana em endereços, métodos de pagamento japoneses (pagamentos em konbini, faturamento de operadora, transferências bancárias via Pay-easy) e cálculos de envio baseados em zonas dos Correios Japoneses. Você não pode simplesmente virar uma chave e mudar para Shopify. Você precisa de uma estratégia.

Este guia é o documento de estratégia que eu gostaria de ter tido quando fizemos nossa primeira migração EC-CUBE em 2024.

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

Índice

Por Que Migrar do EC-CUBE em 2026

EC-CUBE foi a espinha dorsal do ecommerce japonês por quase duas décadas. Desenvolvido pela Lockon Co., Ltd. (agora EC-CUBE Co., Ltd.), dominou o mercado japonês quando as opções eram limitadas. Mas a paisagem mudou dramaticamente.

Aqui está o que está afastando negócios:

A manutenção de segurança é um pesadelo. EC-CUBE 2.x chegou ao fim da vida útil há anos, mas um número surpreendente de lojas ainda a executa. Até mesmo EC-CUBE 4.x requer aplicação de patches constante. Apenas em 2024, houve três avisos de segurança crítica para EC-CUBE 4, incluindo uma vulnerabilidade de injeção SQL (CVE-2024-22345) que afetou milhares de lojas. Se você estiver auto-hospedando, esse é seu problema para corrigir.

Os custos de hospedagem PHP continuam subindo. Executar EC-CUBE em um VPS ou servidor dedicado no Japão (tipicamente em Sakura Internet, XSERVER ou AWS Tokyo) significa que você está pagando por infraestrutura, certificados SSL, manutenção de banco de dados e monitoramento de servidor. Uma loja EC-CUBE de tamanho médio típico gasta ¥50.000–¥200.000/mês apenas em hospedagem e manutenção.

O ecossistema de plugins está encolhendo. O marketplace de plugins EC-CUBE perdeu desenvolvedores. Muitos plugins de pagamento e envio populares não foram atualizados para EC-CUBE 4.2+. Se sua loja depender de plugins de terceiros, você pode se encontrar preso em uma versão antiga sem caminho de atualização.

O desempenho móvel é ruim. A maioria dos temas EC-CUBE foi projetada na era responsiva-mas-pesada. As pontuações médias do Lighthouse para lojas EC-CUBE que auditamos giram em torno de 25-40 no celular. Isso não vai funcionar quando Core Web Vitals impactar diretamente seus rankings no Google no Japão.

Entendendo a Arquitetura do EC-CUBE

Antes de você poder migrar, você precisa entender o que está migrando. A arquitetura do EC-CUBE varia significativamente por versão:

Recurso EC-CUBE 2.x EC-CUBE 3.x EC-CUBE 4.x
Framework PHP Customizado Silex (Symfony micro) Symfony 4/5
Banco de Dados PostgreSQL/MySQL PostgreSQL/MySQL PostgreSQL/MySQL
Template Engine Smarty Twig Twig
Plugin Architecture Hooks/overrides Event-based Symfony bundles
ORM Custom Doctrine Doctrine
API Nenhuma (builds customizados) REST limitado REST + GraphQL limitado

O esquema do banco de dados é onde as coisas ficam interessantes (e dolorosas). As lojas EC-CUBE armazenam dados de produtos, dados de clientes e histórico de pedidos em um esquema normalizado, mas específico do EC-CUBE. As tabelas dtb_product, dtb_product_class, dtb_customer e dtb_order são as principais que você precisará extrair.

EC-CUBE 4.x usa entidades Doctrine, o que torna a extração de dados um pouco mais limpa. Mas se você estiver na 2.x, prepare-se para exportações SQL brutas com problemas de codificação (dados legados Shift-JIS ou EUC-JP ainda são comuns).

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

Por Que Shopify Plus + Next.js para Ecommerce Japonês

Quero ser direto: Shopify não é a única opção. Você poderia migrar para outras plataformas como commercetools, Medusa, ou até uma plataforma japonesa mais nova como BASE ou STORES.jp. Mas para operações de ecommerce japonês médias a grandes, Shopify Plus combinado com um frontend Next.js headless atinge um ponto ideal.

A presença do Shopify no Japão amadureceu. Desde a abertura de seu escritório em Tóquio e o lançamento de suporte completo em japonês, Shopify abordou a maioria das lacunas específicas do Japão. Shopify Payments agora suporta cartões JCB nativamente. A interface de administrador está totalmente localizada. E criticamente, Shopify Plus suporta cálculos de impostos japoneses, incluindo o sistema 軽減税率 (taxa de imposto reduzida) para alimentos e bebidas.

Next.js oferece a vantagem de desempenho. Uma vitrine headless construída com Next.js (usando a Storefront API do Shopify ou a camada de dados subjacente do Hydrogen) permite que você sirva páginas estáticas e renderizadas no servidor a partir do edge. Rotineiramente vemos pontuações de desempenho do Lighthouse de 90+ no celular para nossas compilações Next.js Shopify. Esse é um grande salto em relação à pontuação típica de 30 e poucos do EC-CUBE.

A Storefront API lida com a complexidade. A Storefront API do Shopify (versão 2025-04 a partir da redação) suporta metafields, conteúdo localizado, múltiplas moedas e opções de produtos customizadas -- tudo que você precisa para replicar a flexibilidade do EC-CUBE.

Se você estiver avaliando se uma arquitetura headless baseada em Next.js faz sentido para sua loja específica, a resposta quase sempre se resume ao seu tamanho de catálogo e necessidades de customização. Menos de 100 produtos com variantes simples? O tema Shopify padrão pode ser bom. Configurações de produtos complexas, customização pesada ou múltiplas vitrines? Vá headless.

Auditoria Pré-Migração e Planejamento

Não toque em uma linha de código até ter concluído esta auditoria:

Documente cada tipo de produto, estrutura de variante e campo customizado em sua loja EC-CUBE. A tabela dtb_product_class do EC-CUBE pode conter combinações de variantes complexas que não mapeiam 1:1 para o modelo de variante do Shopify (que tem um limite de 100 variantes por produto e um limite de 3 opções).

Se você tiver produtos com mais de 3 tipos de opção (por exemplo, tamanho, cor, material, gravação), você precisará usar o recurso Combined Listings do Shopify (lançado 2024) ou reestruturar sua arquitetura de produto usando metafields e propriedades de item de linha.

2. Inventário de Dados do Cliente

EC-CUBE armazena dados de cliente ricos, incluindo:

  • 姓名 (sobrenome / nome, campos separados)
  • フリガナ (furigana para nome)
  • 郵便番号 (código postal com preenchimento automático de endereço)
  • Múltiplos endereços de envio por cliente
  • Saldos de pontos (ポイント)
  • Histórico de compras com rastreamento de status de pedido detalhado

O modelo de cliente do Shopify lida com campos de nome e múltiplos endereços nativamente. Mas programas de pontos/fidelidade precisam de uma solução de terceiros como Smile.io ou um sistema baseado em metafield customizado.

3. Inventário de Integrações

Liste todos os sistemas externos aos quais sua loja EC-CUBE se conecta:

  • Gateways de pagamento (GMO Payment Gateway, SB Payment Service, PAY.JP)
  • APIs de envio (Yamato Transport, Sagawa Express, Japan Post)
  • Software de contabilidade (弥生会計, freee, MoneyForward)
  • Sistemas de Inventário/ERP
  • Email marketing (Mailchimp, SendGrid ou serviços japoneses como Benchmark Email)

4. Documentação de Estrutura de URL

Exporte cada URL de sua loja EC-CUBE. Isso é crítico para migração de SEO. Os padrões de URL padrão do EC-CUBE são assim:

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

Você precisará de mapas de redirecionamento para todos esses.

Estratégia de Migração de Dados

Aqui está o pipeline de migração que usamos:

Exportação de Dados de Produtos

Para EC-CUBE 4.x, você pode usar as ferramentas CLI do Doctrine ou escrever um comando Symfony para exportar produtos como JSON:

// Comando de exportação de produtos 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()),
    ];
}

Para EC-CUBE 2.x, você está procurando SQL bruto:

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;

Cuidado com a codificação de caracteres. Se seu banco de dados EC-CUBE 2.x usar EUC-JP, converta para UTF-8 antes de importar em qualquer lugar:

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

Importar para Shopify

Use a Admin API do Shopify (REST ou GraphQL) para criar produtos programaticamente. A mutação productCreate em GraphQL é seu melhor amigo aqui:

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

Construa um script de migração em Node.js ou Python que leia seus dados EC-CUBE exportados e crie produtos Shopify. Inclua limitação de taxa -- a API do Shopify tem um limite de 2 requests/segundo para REST e um limite baseado em custo para GraphQL.

Migração de Clientes

A importação de clientes do Shopify via API funciona bem, mas observe que você não pode migrar senhas. Todos os clientes precisarão redefinir suas senhas após a migração. Envie um email bem redigido (em japonês, obviamente) explicando a migração e fornecendo um link de redefinição de senha.

Para os dados do cliente em si, mapeie campos EC-CUBE para Shopify:

Campo EC-CUBE Campo Shopify Notas
name01 (姓) last_name Invertido para japonês
name02 (名) first_name Invertido para japonês
kana01 (セイ) metafield Sem campo de furigana nativo
kana02 (メイ) metafield Sem campo de furigana nativo
email email Mapeamento direto
point metafield ou app de fidelidade Precisa de tratamento customizado
addr01 (都道府県) province Mapa para códigos de província do Shopify
addr02 (市区町村) city + address1 Pode precisar de concatenação

Histórico de Pedidos

Migrar pedidos históricos é opcional, mas recomendado para continuidade de atendimento ao cliente. Use a Order API do Shopify para criar pedidos com "financial_status": "paid" e "fulfillment_status": "fulfilled" para pedidos concluídos.

Lidando com Métodos de Pagamento Japoneses

Aqui é onde as coisas ficam complicadas. Os consumidores japoneses esperam opções de pagamento específicas que não são padrão no ecommerce ocidental.

Shopify Payments agora suporta cartões de crédito incluindo JCB, Visa, Mastercard e American Express no Japão. As taxas de processamento são 3,25%–3,4% + ¥0 por transação para Shopify Plus.

Para outros métodos de pagamento:

Método de Pagamento Solução no Shopify Notas
コンビニ決済 (Loja de conveniência) KOMOJU, app GMO Payment Gateway Essencial para ~15% dos pedidos online japoneses
代引き (Pagamento na entrega) COD nativo do Shopify Built-in, funciona bem
銀行振込 (Transferência bancária) Método de pagamento manual Shopify suporta isso nativamente
キャリア決済 (Faturamento de operadora) KOMOJU docomo, au, SoftBank
PayPay Aplicativo PayPay para Shopify Método QR mais popular do Japão
Amazon Pay Aplicativo Amazon Pay Alta adoção no Japão
後払い (Compre agora, pague depois) Paidy, atone Muito popular no Japão

KOMOJU merece menção especial. Tornou-se o gateway de pagamento de fato para lojas Shopify no Japão, suportando pagamentos em konbini, transferências bancárias, faturamento de operadora e muito mais através de uma única integração. Sua integração com Shopify Plus é sólida e não temos tido problemas significativos com isso.

Mapeamento de Envio e Atendimento

EC-CUBE geralmente usa plugins para Yamato Transport (ヤマト運輸), Sagawa Express (佐川急便) e Japan Post (日本郵便). Esses plugins lidam com geração de rótulos de envio, integração de números de rastreamento e seleção de horário de entrega (配達時間指定).

No Shopify, você tem várias opções:

  • Ship&co -- Aplicativo de envio construído no Japão que se integra a todas as principais transportadoras japonesas. Lida com impressão de rótulos no formato correto.
  • Shopify Shipping -- Suporte limitado de transportadora no Japão a partir de 2025, mas melhorando.
  • Custom Carrier Service API -- Construa seu próprio calculador de taxa de envio se tiver preços complexos baseados em zonas.

A seleção de horário de entrega (午前中, 12-14時, 14-16時, etc.) é crítica para clientes japoneses. Isso requer uma extensão de checkout customizada no Shopify Plus ou um aplicativo de terceiros como 配送日時指定 .amp.

Construindo a Vitrine Next.js

Para o frontend, usamos Next.js 15 com App Router e Server Components. Aqui está nossa pilha típica:

Next.js 15 (App Router)
├── Shopify Storefront API (GraphQL)
├── next-intl (para i18n em japonês)
├── Tailwind CSS 4
├── Framer Motion (animações)
└── Vercel (deployment, região Tokyo edge)

Algumas coisas que aprendemos construindo vitrines japonesas com Next.js:

Otimização de Fonte

As fontes da web japonesas são pesadas. Noto Sans JP apenas com peso regular é ~1,8MB. Use next/font com subsets e considere fontes variáveis:

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

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

Ainda melhor, use font-display: optional para texto não crítico e sirva uma pilha de fonte do sistema como fallback: "Hiragino Kaku Gothic ProN", "Hiragino Sans", Meiryo, sans-serif.

Server Components para Páginas de Produto

Busque dados de produto em Server Components para eliminar estados de carregamento do lado do cliente:

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

Construímos todas as nossas vitrines Shopify headless com esse padrão, e a diferença de desempenho versus um tema Liquid tradicional ou até mesmo Hydrogen é notável.

Migração de SEO e Preservação de URL

Esta é a parte que me deixa acordado à noite em projetos de migração. As lojas de ecommerce japonesas frequentemente têm anos de patrimônio de SEO acumulado, e uma migração mal feita pode derrubar o tráfego orgânico por meses.

Estratégia de Redirecionamento

Crie um mapa de redirecionamento completo. Cada. URL. Use redirecionamentos de next.config.js para padrões estáticos:

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

Para redirecionamentos dinâmicos (mapeamento de IDs de produtos EC-CUBE para handles Shopify), use middleware ou uma tabela de pesquisa de redirecionamento armazenada em um banco de dados ou armazenamento de KV.

Dados Estruturados

As lojas EC-CUBE raramente têm dados estruturados apropriados. Aproveite essa oportunidade para implementar esquema Product, BreadcrumbList, Organization e FAQPage. Os SERPs japoneses do Google apresentam muito resultados avançados.

Especificidades de SEO Japonês

  • Mantenha suas tags de título em menos de 30 caracteres em japonês (não 60 como em inglês)
  • Meta descriptions: 80-120 caracteres em japonês
  • Garanta tags hreflang apropriadas se você tiver páginas multi-idioma
  • Envie sitemap para Google Search Console e Bing Webmaster Tools (Bing tem participação de mercado significativa no Japão)

Considerações de UX Específicas do Japonês

A UX de ecommerce japonês tem diferenças culturais que desenvolvedores ocidentais frequentemente perdem:

  • Densidade de informações -- Os consumidores japoneses esperam mais informações de produto visíveis na página. Não sobre-minimize.
  • Sinais de confiança -- Exiba políticas de envio, políticas de devolução e informações da empresa de forma proeminente. Os compradores japoneses pesquisam minuciosamente.
  • Preenchimento automático de código postal -- Implemente 郵便番号 → conclusão automática de endereço usando a API dos Correios Japoneses ou uma biblioteca como zipaddress.js.
  • Linguagem honorífica -- Use keigo apropriado (敬語) na cópia da UI. A linguagem casual pode parecer desrespeitosa.
  • Integração de mensagens do LINE -- LINE tem 96 milhões de usuários mensais ativos no Japão. Integre LINE Login e notificações do LINE.

Benchmarks de Desempenho: EC-CUBE vs Shopify Headless

Aqui estão dados reais de uma migração que completamos em Q1 2025 para um varejista de moda japonês (~3.000 SKUs):

Métrica EC-CUBE 4.2 (Antes) Next.js + Shopify (Depois) Melhoria
Desempenho do Lighthouse (Celular) 34 92 +170%
LCP 4.8s 1.2s -75%
FID/INP 380ms 45ms -88%
CLS 0.24 0.02 -92%
Tempo para o Primeiro Byte 1.8s 0.18s -90%
Peso da Página (página de produto) 3.2MB 680KB -79%
Taxa de Conversão 1.8% 2.9% +61%
Custo Mensal de Hospedagem ¥180.000 ¥45.000 -75%

A melhoria da taxa de conversão sozinha pagou pela migração inteira em três meses. Nem todos os projetos veem números tão dramáticos, mas melhorias de desempenho desta magnitude consistentemente movem a agulha.

Expectativas de Cronograma e Custo

Vamos ser realistas sobre o que essa migração requer:

Tamanho da Loja Produtos Cronograma Faixa de Orçamento (¥)
Pequena <500 8-12 semanas ¥3.000.000-5.000.000
Média 500-5.000 12-20 semanas ¥5.000.000-12.000.000
Grande 5.000+ 20-32 semanas ¥12.000.000-25.000.000+

Essas faixas incluem design, desenvolvimento, migração de dados, QA e suporte de lançamento. Eles assumem que você está trabalhando com um time experiente. Se seu time nunca fez migração de ecommerce japonês antes, adicione 30-50% tanto ao cronograma quanto ao orçamento para curvas de aprendizado.

Lidamos com projetos neste espectro através da nossa prática de desenvolvimento de CMS e comércio headless. Se você quer falar de detalhes específicos, entre em contato e daremos uma avaliação honesta.

Os custos mensais em andamento após a migração geralmente se parecem com:

  • Shopify Plus: $2.300/mês (~¥345.000)
  • Vercel Pro: $20/mês por membro da equipe
  • KOMOJU: Apenas taxas de transação
  • Ship&co: Base ¥2.000/mês
  • Total: ~¥380.000-450.000/mês vs. ¥400.000-800.000/mês para EC-CUBE auto-hospedado com capacidades equivalentes

Para uma visão transparente de como estruturamos preços de projetos, confira nossa página de preços.

FAQ

Posso migrar do EC-CUBE 2.x diretamente para Shopify + Next.js?

Sim, mas migrações de EC-CUBE 2.x são mais complexas devido ao esquema de banco de dados mais antigo, possíveis problemas de codificação Shift-JIS/EUC-JP e falta de um ORM moderno. Orçamente tempo extra para limpeza e transformação de dados. Recomendamos exportar para um formato neutro (CSV ou JSON em UTF-8) primeiro, então construir scripts de importação para Shopify.

Vou perder meus rankings no Google ao migrar do EC-CUBE?

Não se você lidar com redirecionamentos corretamente. Implemente redirecionamentos 301 para cada URL, mantenha seu sitemap XML e mantenha seus títulos e meta descriptions consistentes. Espere uma flutuação temporária (2-4 semanas) enquanto o Google rastreia novamente, mas os rankings devem se recuperar e tipicamente melhorar devido a melhores pontuações de Core Web Vitals.

O Shopify suporta cálculo de impostos japonês incluindo taxas reduzidas?

Sim. Shopify suporta o sistema de imposto sobre consumo do Japão, incluindo a 軽減税率 (taxa reduzida de 8% para alimentos e bebidas vs. a taxa padrão de 10%). Você pode configurar alíquotas de imposto por coleção de produtos e Shopify lida com o cálculo, incluindo requisitos de recibos qualificados para fatura (インボイス制度).

Como faço para lidar com o sistema de pontos do EC-CUBE após migrar para Shopify?

Shopify não tem um sistema de pontos nativo equivalente à funcionalidade ポイント built-in do EC-CUBE. Suas melhores opções são Smile.io (suporta japonês), LoyaltyLion ou uma solução customizada usando metafields do Shopify e uma função serverless. Para saldos de pontos existentes, migre-os como metafields em registros de cliente e construa um fluxo de resgate em seu checkout Next.js.

Hydrogen é melhor do que Next.js para uma vitrine Shopify headless?

Depende. Hydrogen (framework React do Shopify construído em Remix) é fortemente integrado com Shopify e oferece algumas primitivas de comércio built-in agradáveis. Mas Next.js tem um ecossistema muito maior, mais recursos da comunidade, melhor suporte Edge Runtime no Vercel e mais flexibilidade se você nunca quiser trocar de backend de comércio. Para ecommerce japonês especificamente, as capacidades de middleware e roteamento i18n do Next.js dão a ele uma vantagem. Construímos com ambos e preferimos Next.js para a maioria dos projetos -- veja nossas capacidades de desenvolvimento Next.js.

Posso executar EC-CUBE e a nova loja Shopify em paralelo durante a migração?

Absolutamente, e recomendamos. Execute ambos os sistemas simultaneamente por 2-4 semanas. Use seu DNS ou um proxy reverso para deslocar o tráfego gradualmente. Isso permite que você valide se os pedidos fluem corretamente, se os pagamentos são processados apropriadamente e se o inventário permanece em sincronização antes de cortar completamente.

E sobre o recurso de revista de email (メールマガジン) do EC-CUBE?

EC-CUBE tem um sistema de newsletter de email built-in que muitas lojas dependem. Migre sua lista de inscritos para uma plataforma de marketing de email dedicada como Klaviyo (que tem excelente integração com Shopify) ou, se você precisar de suporte em idioma japonês e templates, considere Benchmark Email ou SendGrid. A migração é direta -- exporte endereços de email e datas de consentimento da tabela dtb_customer do EC-CUBE e importe para sua nova plataforma.

Quanto tempo leva a migração real de dados?

A execução do script de migração em si é geralmente rápida -- algumas horas para a maioria das lojas. A parte demorada é construir e testar os scripts de migração, validar a integridade dos dados e lidar com casos extremos (produtos sem imagens, clientes com formatos de email inválidos, pedidos com status customizados). Para uma loja com 3.000 produtos e 50.000 clientes, espere 2-3 semanas de tempo de desenvolvimento e teste de migração.