Guia de Migração de Movable Type para Next.js para Empresas Japonesas
Guia de Migração de Movable Type para Next.js para Empresas Japonesas
Se você trabalha com sites corporativos japoneses há algum tempo, quase certamente já encontrou Movable Type. O CMS da Six Apart teve um domínio notavelmente forte no mercado japonês desde meados dos anos 2000, alimentando desde sites corporativos de grandes fabricantes até portais governamentais e sites de universidades. Mas aqui está o ponto -- estamos em 2026, e a web avançou. Sua instalação de Movable Type provavelmente não.
Ajudei a migrar vários sites corporativos japoneses do Movable Type nos últimos dois anos, e vou ser honesto: não é um projeto trivial. Existem peculiaridades em torno da codificação de caracteres, estruturas de conteúdo exclusivas de sites corporativos japoneses e preocupações organizacionais que tornam essas migrações diferentes de seu típico movimento de WordPress para Next.js. Este guia abrange tudo que aprendi da forma mais difícil.
Índice
- Por que Empresas Japonesas Estão Deixando Movable Type
- Entendendo a Arquitetura do Movable Type
- Escolhendo Seu Backend de CMS Headless
- Auditoria de Conteúdo e Extração de Dados
- Tratando Especificidades de Conteúdo Japonês
- Construindo o Frontend Next.js
- Estratégia de Migração SEO para Busca Japonesa
- Implantação e Infraestrutura
- Planejamento de Timeline e Orçamento
- FAQ
Por que Empresas Japonesas Estão Deixando Movable Type
Vamos deixar o óbvio de lado: Movable Type não está morto. A Six Apart Japan ainda mantém, e Movable Type 8 (lançado no final de 2024) adicionou alguns recursos modernos. Mas há sinais claros de que o fim está próximo por várias razões.
Preocupações de Performance
Movable Type usa um modelo de publicação estática -- ele reconstrói arquivos HTML quando o conteúdo muda. Isso soa ótimo até você ter um site com 15.000 páginas e um editor de conteúdo esperando 20 minutos para uma reconstrução terminar. Já vi sites corporativos japoneses onde editores agendariam reconstruções durante a noite porque o processo era tão lento.
Next.js com ISR (Incremental Static Regeneration) ou revalidação sob demanda resolve isso completamente. As páginas se regeneram individualmente em milissegundos.
Custo de Propriedade
O licenciamento Movable Type no Japão custa aproximadamente ¥600.000-¥1.200.000 por ano para licenças empresariais a partir de 2026. Isso é $4.000-$8.000 USD anuais apenas pela licença de CMS, antes de hospedagem, plugins ou desenvolvimento customizado. Comparado a um CMS headless como microCMS (popular no Japão, começando em ¥4.900/mês para planos de negócios) pareado com Next.js no Vercel, a matemática começa a parecer muito diferente.
Escassez de Desenvolvedores
Este é o grande problema que ninguém fala publicamente. Encontrar desenvolvedores que conhecem Perl (a linguagem do Movable Type) e estão dispostos a trabalhar com templates MT está se tornando genuinamente difícil no Japão. A idade média dos desenvolvedores com experiência em MT que encontrei ultrapassa 45 anos. Enquanto isso, desenvolvedores Next.js estão em toda parte -- é o framework que empresas de tecnologia japonesas estão contratando em 2026.
Segurança e Conformidade
Movable Type teve várias CVEs sérias ao longo dos anos, incluindo a infame vulnerabilidade XMLRPC (CVE-2021-20837) que foi ativamente explorada contra sites japoneses. Com os requisitos do APPI (Lei sobre a Proteção de Informações Pessoais) emendado no Japão ficando mais rigorosos em 2025-2026, as empresas estão reavaliando sua postura de segurança.
Entendendo a Arquitetura do Movable Type
Antes de migrar, você precisa entender do que está migrando. O modelo de dados do Movable Type é diferente de WordPress ou da maioria dos CMSes modernos.
Estruturas de Dados Principais
| Conceito MT | Descrição | Equivalente Next.js/Headless |
|---|---|---|
| Blog | Contêiner de conteúdo de nível superior | Site ou workspace |
| Entry | Postagem de blog ou artigo | Item de conteúdo (tipo blog) |
| Page | Página estática | Item de conteúdo (tipo página) |
| Category | Taxonomia hierárquica | Sistema de categoria/tag |
| Template | Templates HTML com tags MT | Componentes React + layouts |
| Custom Field | Campos estendidos de entrada | Campos de modelo de conteúdo |
| Asset | Arquivos de mídia enviados | Biblioteca de mídia/asset |
| Website | Contêiner pai para blogs | Configuração multi-site |
A linguagem de template do Movable Type usa tags como <mt:EntryTitle> e <mt:Entries>. Estas não mapeiam 1:1 para nada na stack moderna -- você estará reconstruindo a camada de apresentação do zero.
A Camada de Banco de Dados
MT suporta MySQL, PostgreSQL e SQLite. A maioria das instalações corporativas japonesas usa MySQL. O esquema do banco de dados é bem documentado mas... excêntrico. Campos customizados são armazenados em uma tabela separada mt_entry_meta usando um padrão chave-valor, o que torna a extração não trivial.
Aqui está como a tabela de entrada parece:
SELECT
entry_id,
entry_title,
entry_text,
entry_text_more,
entry_excerpt,
entry_created_on,
entry_modified_on,
entry_basename,
entry_status
FROM mt_entry
WHERE entry_blog_id = 1
AND entry_status = 2 -- 2 = published
ORDER BY entry_created_on DESC;
Note a divisão entry_text e entry_text_more. MT divide o conteúdo do corpo em dois campos -- um padrão da era inicial de blogs que você precisará concatenar durante a migração.
Escolhendo Seu Backend de CMS Headless
Next.js é seu framework frontend. Mas você precisa de um lugar para gerenciar conteúdo. Para empresas japonesas, reduzi para quatro opções realistas.
microCMS
Esta é a escolha padrão para empresas japonesas, e por boas razões. É construída por uma empresa japonesa, tem UI nativa em japonês, suporte ao cliente em japonês e residência de dados no Japão. Os preços começam em ¥4.900/mês (Hobby é gratuito para pequenos projetos). A API é limpa, o suporte a webhooks funciona bem com ISR do Next.js, e seus editores de conteúdo não precisarão de habilidades em inglês.
Newt
Outro CMS headless feito no Japão que tem ganhado força. É ligeiramente mais amigável para desenvolvedores do que microCMS e tem maior flexibilidade de modelagem de conteúdo. Boa opção se seu site tem estruturas de conteúdo complexas.
Contentful
A escolha corporativa global. Suporte sólido de localização, API excelente e um ecossistema maduro. A desvantagem para empresas japonesas: suporte é em inglês, a UI é em inglês e os preços são em USD. A ¥300/mês para o plano Team (preço de 2026), é significativamente mais caro do que alternativas japonesas.
Sanity
Mencionei Sanity porque é tecnicamente excelente, e seu Studio customizável pode ser configurado com rótulos em japonês. Mas a curva de aprendizado é mais íngreme, e você não encontrará tantos desenvolvedores japoneses com experiência em Sanity.
| CMS | UI Japonesa | Residência de Dados Japão | Preço Inicial | Melhor Para |
|---|---|---|---|---|
| microCMS | ✅ | ✅ | ¥4.900/mês | A maioria dos sites corporativos japoneses |
| Newt | ✅ | ✅ | ¥3.300/mês | Modelos de conteúdo complexos |
| Contentful | ❌ | ❌ (EU/US) | ~$300/mês | Empresas globais |
| Sanity | Parcial | ❌ | $99/mês (Team) | Equipes com foco em desenvolvedores |
Para a maioria das empresas japonesas migrando do Movable Type, recomendo microCMS ou Newt. A redução de atrito de ter tudo em japonês vale mais do que você pensaria. Trabalhamos extensivamente com todos esses através de nossa prática de desenvolvimento de CMS headless.
Auditoria de Conteúdo e Extração de Dados
Aqui é onde o trabalho real começa. Não pule a fase de auditoria -- já vi migrações fracassarem porque equipes pularam direto para a extração sem entender o que realmente tinham.
Passo 1: Inventariar Tudo
Conecte ao seu banco de dados MT e execute contagens:
-- Contar entradas por blog
SELECT
b.blog_name,
COUNT(e.entry_id) as entry_count
FROM mt_entry e
JOIN mt_blog b ON e.entry_blog_id = b.blog_id
WHERE e.entry_status = 2
GROUP BY b.blog_name;
-- Contar campos customizados por blog
SELECT
b.blog_name,
em.entry_meta_type,
COUNT(*) as field_count
FROM mt_entry_meta em
JOIN mt_entry e ON em.entry_meta_entry_id = e.entry_id
JOIN mt_blog b ON e.entry_blog_id = b.blog_id
GROUP BY b.blog_name, em.entry_meta_type;
Passo 2: Exportar Conteúdo
MT tem um formato de exportação integrado, mas é limitado. Prefiro extração direta do banco de dados com um script Python:
import mysql.connector
import json
import html
def extract_mt_entries(config):
conn = mysql.connector.connect(**config)
cursor = conn.cursor(dictionary=True)
cursor.execute("""
SELECT
e.entry_id,
e.entry_title,
e.entry_text,
e.entry_text_more,
e.entry_excerpt,
e.entry_basename,
e.entry_created_on,
e.entry_modified_on,
GROUP_CONCAT(c.category_label) as categories
FROM mt_entry e
LEFT JOIN mt_placement p ON e.entry_id = p.placement_entry_id
LEFT JOIN mt_category c ON p.placement_category_id = c.category_id
WHERE e.entry_status = 2
GROUP BY e.entry_id
""")
entries = cursor.fetchall()
for entry in entries:
# Combinar text e text_more
body = (entry['entry_text'] or '') + (entry['entry_text_more'] or '')
entry['full_body'] = body
# Tratar codificação
entry['entry_title'] = entry['entry_title']
with open('mt_export.json', 'w', encoding='utf-8') as f:
json.dump(entries, f, ensure_ascii=False, default=str, indent=2)
return entries
Passo 3: Migração de Assets de Mídia
MT armazena assets no sistema de arquivos, geralmente em /path/to/mt/support/uploads/. Você precisará:
- Inventariar todos os arquivos e compatibilizá-los com registros de banco de dados em
mt_asset - Re-enviar para seu novo CMS ou um CDN (Cloudinary, imgix ou armazenamento integrado do CMS)
- Atualizar todas as referências no HTML do corpo do conteúdo
Isso é tedioso. Dedique tempo para isso.
Tratando Especificidades de Conteúdo Japonês
Esta seção é o motivo pelo qual escrevi este artigo. Guias genéricos de migração não cobrem esses problemas.
Codificação de Caracteres
Instalações mais antigas de Movable Type (pré-MT5) às vezes armazenavam conteúdo em codificação EUC-JP ou Shift_JIS, mesmo que o banco de dados fosse nominalmente UTF-8. Verifique seus dados reais:
# Detectar problemas de codificação
import chardet
def check_encoding(text_bytes):
result = chardet.detect(text_bytes)
if result['encoding'] != 'utf-8':
print(f"Aviso: detectado {result['encoding']} "
f"com {result['confidence']:.0%} de confiança")
return result
Se encontrar incompatibilidades de codificação, converta tudo para UTF-8 antes de importar para seu novo CMS. Mojibake quebrado (文字化け) em um site corporativo é um evento limitante de carreira.
Texto Ruby (Furigana)
Sites corporativos japoneses frequentemente usam anotações ruby -- pequenos auxiliares de leitura acima dos caracteres kanji. Templates MT frequentemente tratam isso com tags customizadas. Em Next.js, você usará elementos HTML <ruby> padrão:
// components/RubyText.tsx
export function RubyText({ base, reading }: { base: string; reading: string }) {
return (
<ruby>
{base}
<rp>(</rp>
<rt>{reading}</rt>
<rp>)</rp>
</ruby>
);
}
Certifique-se de que seu script de migração de conteúdo preserva qualquer markup ruby existente.
Formatação de Data Japonesa
Sites corporativos japoneses frequentemente exibem datas em 和暦 (formato de era japonesa): 令和8年1月15日 em vez de 2026-01-15. Trate isso em seus componentes Next.js:
function formatJapaneseDate(dateString: string): string {
const date = new Date(dateString);
return date.toLocaleDateString('ja-JP-u-ca-japanese', {
era: 'long',
year: 'numeric',
month: 'long',
day: 'numeric',
});
}
Layouts de Texto Vertical
Alguns sites japoneses, particularmente em publicação ou indústrias tradicionais, usam texto vertical (縦書き). CSS trata isso:
.vertical-text {
writing-mode: vertical-rl;
text-orientation: mixed;
}
Next.js trata isso bem, mas teste minuciosamente em navegadores.
Construindo o Frontend Next.js
Com seu conteúdo extraído e seu CMS escolhido, é hora de construir. Aqui está a arquitetura que recomendo para sites corporativos japoneses.
App Router com Geração Estática
Use o App Router do Next.js 15 com geração estática para a maioria das páginas. Sites corporativos japoneses são típicos e heavy em conteúdo com atualizações infrequentes -- perfeito para geração estática com revalidação sob demanda.
// app/news/[slug]/page.tsx
import { getArticle, getAllArticleSlugs } from '@/lib/cms';
export async function generateStaticParams() {
const slugs = await getAllArticleSlugs();
return slugs.map((slug) => ({ slug }));
}
export default async function NewsArticle({
params
}: {
params: Promise<{ slug: string }>
}) {
const { slug } = await params;
const article = await getArticle(slug);
return (
<article>
<h1>{article.title}</h1>
<time dateTime={article.publishedAt}>
{formatJapaneseDate(article.publishedAt)}
</time>
<div dangerouslySetInnerHTML={{ __html: article.body }} />
</article>
);
}
Configuração i18n
Muitos sites corporativos japoneses precisam de versões em japonês e inglês. O App Router do Next.js trata isso com grupos de rota ou detecção de locale baseada em middleware:
// middleware.ts
import { NextRequest, NextResponse } from 'next/server';
export function middleware(request: NextRequest) {
const pathname = request.nextUrl.pathname;
const locale = pathname.startsWith('/en') ? 'en' : 'ja';
request.headers.set('x-locale', locale);
return NextResponse.next();
}
Construímos dezenas de sites corporativos japoneses bilíngues usando Next.js -- nossa equipe de desenvolvimento Next.js pode guiá-lo pelas nuances.
Estratégia de Migração SEO para Busca Japonesa
Isso é inegociável. Empresas japonesas vivem e morrem por seus rankings de busca do Google (Yahoo! Japan usa o mecanismo de busca do Google, então é realmente apenas Google). Uma migração fracassada pode derrubar o tráfego orgânico por meses.
Mapeamento de URL
Movable Type gera URLs com padrões configuráveis. Os comuns que vejo em sites japoneses:
/blog/2024/01/entry-basename.html/news/category/entry_basename.html/archives/000123.html(o padrão mais antigo)
Crie um mapeamento completo de URL antes de construir qualquer coisa:
// scripts/generate-redirects.ts
interface RedirectMap {
source: string;
destination: string;
permanent: boolean;
}
function generateRedirects(mtEntries: MTEntry[]): RedirectMap[] {
return mtEntries.map(entry => ({
source: buildMTUrl(entry), // Padrão de URL MT antigo
destination: `/news/${entry.entry_basename}`, // Nova URL Next.js
permanent: true, // redirecionamento 301
}));
}
Coloque esses em seu next.config.ts:
const nextConfig = {
async redirects() {
const redirects = await import('./redirects.json');
return redirects.default;
},
};
Para sites com milhares de redirecionamentos, use middleware em vez disso -- redirecionamentos next.config.ts têm um limite prático.
Dados Estruturados
Resultados de Google japonês apresentam muito snippets ricos. Adicione JSON-LD para artigos, FAQs e informações de organização:
function ArticleJsonLd({ article }: { article: Article }) {
const jsonLd = {
'@context': 'https://schema.org',
'@type': 'Article',
headline: article.title,
datePublished: article.publishedAt,
dateModified: article.updatedAt,
author: {
'@type': 'Organization',
name: article.companyName,
},
inLanguage: 'ja',
};
return (
<script
type="application/ld+json"
dangerouslySetInnerHTML={{ __html: JSON.stringify(jsonLd) }}
/>
);
}
Implantação e Infraestrutura
Para audiências japonesas, a latência importa. Aqui está o que funciona:
| Plataforma | Nós de Edge Japão | Melhor Para | Custo Mensal (típico) |
|---|---|---|---|
| Vercel | Tokyo | Maioria dos sites Next.js | $20-150/mês |
| AWS (CloudFront + Lambda@Edge) | Tokyo, Osaka | Conformidade empresarial | $100-500/mês |
| Google Cloud Run + Cloud CDN | Tokyo | Equipes nativas de GCP | $50-200/mês |
| Cloudflare Pages | Tokyo + muitos | Sites estáticos simples | Free-$25/mês |
Vercel é minha recomendação padrão. É construída propositalmente para Next.js, tem um nó de edge em Tokyo e a DX é incomparável. Para empresas com requisitos rigorosos de residência de dados (governo, finanças), AWS em ap-northeast-1 (Tokyo) é a escolha segura.
Se está considerando Astro em vez de Next.js para um site com muito conteúdo e interatividade mínima, essa é uma escolha válida também -- verifique nossas capacidades de desenvolvimento Astro.
Planejamento de Timeline e Orçamento
Com base em migrações reais que completei, aqui está o que esperar:
| Fase | Duração | Atividades Principais |
|---|---|---|
| Descoberta & Auditoria | 2-3 semanas | Inventário de conteúdo, entrevistas com stakeholders, mapeamento de URL |
| Configuração de CMS & Modelagem de Conteúdo | 2-4 semanas | Design de schema, scripts de migração de conteúdo |
| Migração de Conteúdo | 3-6 semanas | Transferência de dados, migração de mídia, QA |
| Desenvolvimento de Frontend | 6-10 semanas | Build Next.js, biblioteca de componentes, i18n |
| SEO & QA | 2-3 semanas | Teste de redirecionamento, tuning de performance, QA cross-browser |
| Rollout Encenado | 1-2 semanas | Cutover de DNS, monitoramento, hotfixes |
Total: 16-28 semanas para um site corporativo japonês típico com 1.000-10.000 páginas.
Falando em orçamento, você está olhando para ¥5.000.000-¥15.000.000 ($33.000-$100.000 USD) dependendo da complexidade. Isso pode parecer uma quantidade grande, mas considere: você provavelmente está pagando ¥1.000.000+ anuais por licenciamento MT e desenvolvimento especializado já. A migração se paga em 2-3 anos através de custos operacionais reduzidos e maior velocidade de desenvolvedor.
Precisa de uma estimativa detalhada para sua situação específica? Entre em contato conosco ou verifique nossa página de preços para modelos de engajamento.
FAQ
Podemos continuar usando Movable Type como um CMS headless com Next.js?
Tecnicamente sim -- Movable Type 7+ tem uma Data API que pode servir conteúdo para um frontend. Mas é lento, mal documentado e não possui webhooks para revalidação. Tentei essa abordagem em um projeto e não recomendaria. Você gastará mais tempo contornando as limitações da API do MT do que migrando para um CMS headless apropriado.
Como tratamos o modelo de reconstrução MT vs. ISR do Next.js?
Eles são fundamentalmente diferentes. MT reconstrói inteiras seções do site de uma vez (geração estática em lote). ISR do Next.js regenera páginas individuais sob demanda. Isso significa que seus editores obtêm tempos de publicação instantâneos em vez de esperar por reconstruções. A mudança de modelo mental é na verdade mais fácil para editores -- eles apenas clicam publicar e a página está ativa em segundos.
O que acontece com nossos plugins MT durante a migração?
Todo plugin MT precisa de uma substituição ou reimplementação. Os comuns como formulários de contato (plugins de formulário baseados em MT) são substituídos por manipulação de formulário Next.js ou serviços como Formspree. Plugins de busca são substituídos por Algolia ou a busca integrada do CMS. Faça um inventário completo de plugin durante a fase de auditoria.
Nossos rankings do Google cairão durante a migração?
Podem, mas não precisam. Os fatores críticos são: redirecionamentos 301 para cada URL, mantendo títulos de página e meta descrições idênticas ou melhoradas, preservando estrutura de link interna e enviando um sitemap atualizado. Já vi migrações onde rankings realmente melhoraram porque o novo site era mais rápido e tinha melhores scores de Core Web Vitals.
Como tratamos elementos SEO específicos do Japão como Yahoo! Japan?
Yahoo! Japan tem usado o mecanismo de busca do Google desde 2010, então sua estratégia SEO do Google cobre Yahoo! também. A única exceção são as propriedades próprias do Yahoo! Japan (Yahoo! News, etc.) que têm processos de envio separados. Para busca orgânica geral, foque no Google e você está coberto.
Devemos migrar todo conteúdo ou usar isso como uma oportunidade para limpeza?
Sempre limpe. Em cada migração de site corporativo japonês que fiz, 30-50% do conteúdo era desatualizado, redundante ou tinha zero tráfego. Migrar conteúdo morto desperdiça tempo e dilui a autoridade temática do seu site. Use dados de análises para identificar páginas que vale a pena migrar e deixe o resto ir (com respostas 410 Gone apropriadas, não 404s).
Podemos executar Movable Type e Next.js em paralelo durante a migração?
Sim, e recomendo. Use um subdomínio ou roteamento baseado em caminho para servir o novo site Next.js para seções migradas enquanto MT trata o resto. Isso permite migrar em fases em vez de fazer um cutover arriscado de big-bang. Configurações de proxy reverso com nginx ou Cloudflare Workers tornam isso direto.
E quanto ao controle de acesso integrado do Movable Type e recursos de membro?
Se seu site MT usa login de membro, conteúdo fechado ou acesso baseado em função, você precisará implementar autenticação em Next.js. NextAuth.js (agora Auth.js) funciona bem para isso, ou você pode usar um serviço como Clerk ou Auth0. Isso adiciona complexidade e custo -- fatore isso em seu planejamento desde o início.