Seu time de desenvolvimento abre o painel do WordPress e exporta 847 posts, 12 tipos de post personalizados e 3.200 assets de mídia. O dump do banco de dados chega a 4,2GB. Alguém pergunta quanto tempo essa migração realmente leva — não a estimativa polida do deck de kickoff, mas o cronograma que considera shortcodes quebrados, desajustes de campos ACF e o mapa de redirecionamento que cresce de 200 linhas para 1.800 na segunda semana. Lideiei mais de 40 migrações de CMS em cinco anos, a maioria delas WordPress para Next.js. A resposta depende de quatro variáveis que a maioria das agências não mencionará até você já estar assinado. Aqui está o que realmente determina se você lança em 3 semanas ou 6 meses.

A questão é que a resposta real é quase sempre mais longa do que você quer, mas mais curta do que seus piores medos. Um pequeno site de marketing? Você está vendo 3-6 semanas. Uma empresa de médio porte com blog, e-commerce e integrações personalizadas? Planeje 2-4 meses. Uma empresa com 10.000+ páginas, múltiplas localidades e sistemas legados? Prepare-se para 4-8 meses.

Mas esses intervalos não têm significado sem contexto. Deixe-me detalhar exatamente o que acontece em cada fase, onde os times perdem tempo e como evitar que sua migração se torne uma daquelas histórias de horror que se arrasta por um ano.

Índice

Cronograma de Migração de CMS: WordPress para Next.js em 2026

Por que migrar do WordPress para Next.js em 2026?

Seja direto: nem todo site WordPress precisa migrar. Se você está rodando um blog pessoal ou um pequeno site de negócios que está funcionando bem, WordPress ainda é totalmente capaz. Mas há razões reais e mensuráveis pelas quais os times estão se movendo para Next.js com um CMS headless em 2026:

  • Performance: Sites Next.js com geração estática e renderização edge consistentemente marcam 90+ no Core Web Vitals. Sites WordPress ficam em média em torno de 50-65 sem trabalho significativo de otimização.
  • Segurança: Desacoplar o frontend do CMS elimina os vetores de ataque mais comuns do WordPress. Em 2025, a Sucuri reportou que WordPress representava 96,2% dos sites CMS infectados.
  • Experiência do desenvolvedor: Arquitetura de componentes baseada em React significa iteração mais rápida e contratação mais fácil. O pool de talentos PHP do WordPress está encolhendo — a pesquisa de 2025 do Stack Overflow mostrou PHP caindo para o 14º lugar em popularidade de linguagem.
  • Escalabilidade: Sites Next.js implantados em edge na Vercel ou Cloudflare lidam com picos de tráfego sem a abordagem "vamos adicionar mais servidores".

Se você está lidando com problemas de performance, preocupações com segurança ou um time de desenvolvimento que teme mexer na sua base de código WordPress, a migração faz sentido. Cobrimos a abordagem técnica em detalhes na nossa página de capacidades de desenvolvimento Next.js.

Visão geral do cronograma de migração por tamanho de site

Aqui está o detalhamento honesto. Esses cronogramas assumem um time dedicado (não pessoas dividindo tempo com outros projetos) e stakeholders razoavelmente responsivos.

Tamanho do Site Páginas Complexidade Típica Cronograma Tamanho do Time
Pequeno (Marketing/Brochura) 5-50 Baixa — poucas integrações, conteúdo padrão 3-6 semanas 2-3 pessoas
Médio (Negócio) 50-500 Média — blog, formulários, algumas integrações, múltiplos templates 8-16 semanas 3-5 pessoas
Grande (Mid-Market) 500-5.000 Alta — e-commerce, multi-autor, workflows complexos 3-5 meses 4-7 pessoas
Corporativo 5.000+ Muito Alta — múltiplas localidades, integrações legadas, conformidade 4-8 meses 6-12 pessoas

Esses são cronogramas de build, não cronogramas de calendário. O tempo de calendário é sempre mais longo por causa de revisões de stakeholders, loops de feedback e as inevitáveis duas semanas onde o VP de Marketing está de férias durante a fase de aprovação de design.

Fase 1: Descoberta e Auditoria

Duração: 1-3 semanas

É aqui onde a maioria das agências se apressa e a maioria das migrações sai dos trilhos. Descoberta não é apenas "olhar o site WordPress e fazer uma lista". É trabalho forense.

O Que Realmente Acontece

  • Inventário de conteúdo: Cataloga cada tipo de conteúdo, taxonomia, campo personalizado e asset de mídia. Uso Screaming Frog para rastrear o site existente e exportar um mapa completo de URLs. Para um site de 2.000 páginas, isso sozinho leva um dia inteiro para organizar adequadamente.
  • Auditoria de plugins: Documente cada plugin ativo e o que ele faz. O site WordPress médio tem 20-30 plugins. Cada um representa funcionalidade que você precisa replicar, substituir por uma ferramenta SaaS ou intencionalmente descartar.
  • Mapeamento de integrações: Formulários vão para HubSpot? Processamento de pagamento via WooCommerce? Analytics via Google Tag Manager com eventos personalizados? Desenhe o quadro completo.
  • Baseline de SEO: Exporte todos os títulos meta, descrições, URLs canônicas, dados estruturados e padrões de linking interno. Você não pode se dar ao luxo de perder equity de SEO durante a migração.
  • Entrevistas com stakeholders: Converse com as pessoas que realmente usam o CMS diariamente. Editores de conteúdo, profissionais de marketing, quem quer que gerencia o blog. Seus workflows importam mais que a arquitetura técnica.

Entregáveis de Descoberta

  • Documento de modelo de conteúdo
  • Mapa de dependência de integração
  • Plano de migração de SEO
  • Registro de riscos (coisas que podem explodir o cronograma)
  • Recomendação de arquitetura preliminar

Pular ou apressar a descoberta é a causa número um de blowouts de cronograma. Vi uma migração "rápida de 6 semanas" virar um ordeal de 5 meses porque ninguém documentou que o site WordPress tinha 47 Gravity Forms personalizadas com lógica condicional canalizando dados para três CRMs diferentes.

Cronograma de Migração de CMS: WordPress para Next.js em 2026 - arquitetura

Fase 2: Arquitetura e Planejamento

Duração: 1-2 semanas

Com dados de descoberta em mãos, você toma as grandes decisões.

Escolhendo seu CMS Headless

Next.js é seu framework frontend, mas você ainda precisa de um backend de gerenciamento de conteúdo. As principais opções em 2026:

CMS Melhor Para Preço (2026) Curva de Aprendizado
Sanity Modelos de conteúdo complexos, colaboração em tempo real Tier gratuito, depois $99-$949/mês Moderada
Contentful Times empresariais, governança forte $300/mês e acima Moderada
Storyblok Edição visual, times de marketing Tier gratuito, depois €106-€399/mês Baixa
Payload CMS Desenvolvedor-primeiro, controle auto-hospedado Grátis (open source), Cloud a partir de $50/mês Maior
WordPress (Headless) Times querendo manter admin WordPress Custos de hospedagem existentes Baixa (familiar)

Sim, você pode usar WordPress como um CMS headless com WPGraphQL ou a API REST. Alguns times fazem isso para manter seus editores de conteúdo em um ambiente familiar enquanto conseguem Next.js no frontend. É uma abordagem válida, embora você herde alguma sobrecarga de manutenção do WordPress.

Ajudamos times a avaliar essas opções como parte do nosso trabalho de desenvolvimento de CMS headless. A escolha correta depende muito do conforto técnico do seu time editorial.

Decisões de Arquitetura

  • Estratégia de renderização: Static Site Generation (SSG), Incremental Static Regeneration (ISR) ou Server-Side Rendering (SSR)? A maioria dos sites em 2026 usa um híbrido — ISR para páginas de conteúdo, SSR para páginas personalizadas ou em tempo real.
  • Hospedagem: Vercel é o padrão para Next.js, mas Netlify, Cloudflare Pages e AWS Amplify são todas viáveis. O plano Pro da Vercel a $20/usuário/mês cobre a maioria dos times.
  • Arquitetura de API: Você usará a API nativa do CMS, construirá uma camada de middleware ou irá com algo como tRPC para chamadas de API type-safe?
  • Autenticação: Se você tem conteúdo gated ou áreas de membro, planeje isso cedo. NextAuth.js (agora Auth.js v5) trata a maioria dos padrões.

Fase 3: Modelagem de Conteúdo e Configuração do CMS

Duração: 1-3 semanas

É aqui onde você constrói sua estrutura de conteúdo no novo CMS. Não apenas replique sua estrutura WordPress — esta é sua chance de corrigir anos de dívida técnica de conteúdo acumulada.

Design de Modelo de Conteúdo

WordPress tende a encorajar um modelo de conteúdo plano: posts, páginas e uma bagunça de campos personalizados via ACF ou Meta Box. Um CMS headless permite que você pense em conteúdo estruturado.

// Exemplo: modelo de conteúdo Blog Post em Sanity
export default defineType({
  name: 'blogPost',
  title: 'Blog Post',
  type: 'document',
  fields: [
    defineField({
      name: 'title',
      type: 'string',
      validation: (Rule) => Rule.required().max(70),
    }),
    defineField({
      name: 'slug',
      type: 'slug',
      options: { source: 'title' },
    }),
    defineField({
      name: 'author',
      type: 'reference',
      to: [{ type: 'author' }],
    }),
    defineField({
      name: 'body',
      type: 'portableText', // Conteúdo estruturado rico
    }),
    defineField({
      name: 'seo',
      type: 'seoFields', // Objeto SEO reutilizável
    }),
  ],
})

Conteúdo estruturado significa que o corpo do seu blog post não é apenas um blob de HTML. É blocos estruturados que seu frontend pode renderizar da forma que quiser — web, app mobile, newsletter por email, o que for.

Configuração do CMS

  • Configure papéis e permissões
  • Configure funcionalidade de visualização prévia (live preview em Next.js é essencial para adoção do editor)
  • Construa quaisquer componentes de entrada personalizados ou regras de validação
  • Configure webhooks para ativar rebuilds em mudanças de conteúdo

Fase 4: Construção do Frontend

Duração: 2-8 semanas (a maior variável)

É aqui onde a maioria do tempo de calendário é gasto. Construir o frontend Next.js envolve:

Design e Sistema de Componentes

Se você está redesenhando durante a migração (o que cerca de 70% dos nossos clientes fazem), adicione 2-4 semanas. Se você está replicando o design existente, você pode se mover mais rápido.

// Exemplo de arquitetura orientada a componentes
export default function BlogPost({ post }: { post: BlogPostType }) {
  return (
    <article>
      <PageHeader title={post.title} date={post.publishedAt} />
      <AuthorCard author={post.author} />
      <PortableText 
        value={post.body} 
        components={customComponents} 
      />
      <RelatedPosts posts={post.related} />
      <NewsletterSignup />
    </article>
  )
}

Recomendo fortemente construir uma biblioteca de componentes primeiro, então montar páginas. Parece mais lento inicialmente mas compensa massivamente quando você está construindo seu 15º template de página.

Tarefas Principais de Build

  • Templates de página para cada tipo de conteúdo
  • Roteamento dinâmico e rotas catch-all
  • Navegação (incluindo mega menus se aplicável)
  • Funcionalidade de busca (Algolia, Meilisearch ou built-in do Next.js)
  • Implementações de formulários (substituindo Gravity Forms, Contact Form 7, etc.)
  • Integrações de terceiros (analytics, chat widgets, conexões CRM)
  • Otimização de imagem (componente Next.js Image com o image CDN do seu CMS)
  • Geração de sitemap
  • Feeds RSS
  • Mapeamento de redirecionamento 301

O mapeamento de redirecionamento sozinho pode levar dias em um site grande. Cada URL que muda precisa de um redirecionamento, ou você está jogando away equity de SEO.

Fase 5: Migração de Conteúdo

Duração: 1-4 semanas

Migração de conteúdo é ou trivialmente simples ou horrivelmente complexa. Não há meio termo.

Migração Automatizada

Para conteúdo estruturado (blog posts, produtos, membros de time), escreva scripts de migração:

// Script simplificado de migração WordPress para Sanity
import { createClient } from '@sanity/client'
import { wpClient } from './wordpress-api'

const sanity = createClient({
  projectId: 'seu-projeto',
  dataset: 'production',
  token: process.env.SANITY_WRITE_TOKEN,
  apiVersion: '2026-01-01',
})

async function migratePosts() {
  const wpPosts = await wpClient.posts().perPage(100).get()
  
  for (const post of wpPosts) {
    await sanity.create({
      _type: 'blogPost',
      title: post.title.rendered,
      slug: { current: post.slug },
      // Transformar HTML do WordPress para Portable Text
      body: htmlToPortableText(post.content.rendered),
      publishedAt: post.date,
    })
  }
}

O passo htmlToPortableText é onde as coisas ficam complicadas. Conteúdo WordPress é cheio de shortcodes, estilos inline e markup específico de plugin que não mapeia limpar para conteúdo estruturado. Orce tempo para limpeza.

Trabalho de Conteúdo Manual

Algum conteúdo só precisa de atenção humana:

  • Páginas com layouts complexos construídos em Elementor, Divi ou WPBakery
  • Conteúdo com shortcodes incorporados de plugins desativados
  • Mídia que precisa de re-otimização ou texto alternativo
  • Links internos que precisam ser atualizados

Para um site de 500 páginas, planeje 40-80 horas de trabalho de conteúdo manual. Sim, realmente.

Fase 6: QA e Testes

Duração: 1-3 semanas

Não economize aqui. Vi lançamentos atrasados por meses porque QA foi tratado como um afterthought.

Checklist de QA

  • Testes funcionais: Cada formulário, cada elemento interativo, cada recurso dinâmico
  • Testes cross-browser: Chrome, Firefox, Safari, Edge. Safari sempre tem algo estranho.
  • Testes mobile: Dispositivos reais, não apenas Chrome DevTools. Teste em iPhones e dispositivos Android reais.
  • Verificação de conteúdo: Faça spot-check de pelo menos 20% do conteúdo migrado para problemas de formatação
  • Auditoria de SEO: Compare meta tags antigas com novas. Verifique dados estruturados. Teste todos os redirecionamentos.
  • Testes de performance: Scores do Lighthouse, Core Web Vitals em campo, teste de carga com ferramentas como k6
  • Acessibilidade: Conformidade WCAG 2.2 AA. Execute axe-core, mas também faça testes de navegação apenas com teclado.
  • Verificação de analytics: Certifique-se de que o rastreamento dispara corretamente em todos os eventos

Testes de Redirecionamento

Isso merece seu próprio chamado. Exporte cada URL do site antigo. Mapeie cada uma para sua nova URL. Teste cada redirecionamento individual. Para sites empresariais com milhares de URLs, use testes automatizados:

# Testar redirecionamentos com curl
while IFS=, read -r old_url new_url; do
  status=$(curl -o /dev/null -s -w "%{http_code}" -L "$old_url")
  final=$(curl -o /dev/null -s -w "%{url_effective}" -L "$old_url")
  echo "$old_url -> $final (Status: $status)"
done < redirects.csv

Fase 7: Lançamento e Pós-lançamento

Duração: 1-2 semanas

Dia do Lançamento

Prefiro lançar em uma terça ou quarta-feira de manhã. Nunca na sexta (você não quer debugar no fim de semana) e nunca na segunda (as pessoas ainda estão se recuperando do fim de semana).

Checklist de lançamento:

  • Mudanças de DNS (TTL deve ser reduzido 48 horas antes)
  • Verificação de certificado SSL
  • Aquecimento de cache do CDN
  • Monitorar taxas de erro pelas primeiras 4 horas
  • Verificar Google Search Console para erros de rastreamento
  • Verificar todas as integrações de terceiros estão disparando

Pós-lançamento (2 semanas)

  • Monitore Core Web Vitals no Google Search Console
  • Observe erros 404 e adicione redirecionamentos faltantes
  • Rastreie o desempenho de busca orgânica diariamente pelo primeiro mês
  • Recolha feedback dos editores de conteúdo sobre o novo CMS
  • Aborde casos extremos que escaparam do QA

Uma queda de tráfego temporária de 5-15% em busca orgânica é normal após uma migração importante. Deve se recuperar dentro de 2-4 semanas se seus redirecionamentos e SEO forem tratados adequadamente. Se não se recuperar, algo deu errado com o mapeamento de redirecionamento ou paridade de conteúdo.

Atrasos comuns e como evitá-los

Após dezenas de migrações, aqui estão os reais timeline killers:

Scope creep durante o build: "Enquanto estamos nisso, podemos também adicionar um portal de cliente?" Sim, mas isso é um projeto separado. Scope creep adiciona uma média de 3-6 semanas às migrações.

Disponibilidade de stakeholder: Revisões de design que ficam na caixa de entrada de alguém por duas semanas. Orce o tempo de calendário de acordo e defina SLAs claros para rounds de feedback.

Gaps de funcionalidade de plugin: Aquele plugin obscuro do WordPress fazendo algo crítico que ninguém documentou. Descoberta deve pegar isso, mas às vezes as coisas escapam.

Treinamento de editor de conteúdo: Se seu time não consegue usar o novo CMS, você não terminou a migração. Orce 1-2 dias para treinamento e documentação.

Perfeccionismo em migração de conteúdo: Algum conteúdo não vale a pena migrar. Blog posts de 2014 com zero tráfego? Deixe ir. Configure um redirecionamento para o índice do blog e siga em frente.

Expectativas de Custo para 2026

Vou dar-lhe números honestos. Taxas de agência para este trabalho em 2026:

Tamanho do Site Cronograma Custo Estimado (Agência) Custo Estimado (Freelancer)
Pequeno 3-6 semanas $15.000-$35.000 $8.000-$18.000
Médio 8-16 semanas $40.000-$90.000 $25.000-$55.000
Grande 3-5 meses $80.000-$200.000 $50.000-$120.000
Corporativo 4-8 meses $150.000-$500.000+ Raramente apropriado

Esses intervalos refletem o que vimos em todo o mercado. A variância é enorme porque "site médio" pode significar coisas muito diferentes. Um site de 200 páginas com um blog simples e formulário de contato é muito diferente de um site de 200 páginas com conteúdo multilíngue, e-commerce e um portal de membros.

Se você quiser discutir sua situação específica, nossa página de preços descreve nossos modelos de engajamento, ou você pode entrar em contato diretamente para uma estimativa com escopo.

FAQ

Quanto tempo leva uma migração simples de WordPress para Next.js?

Um pequeno site de marketing (menos de 50 páginas) com tipos de conteúdo padrão e integrações mínimas normalmente leva 3-6 semanas do kickoff ao lançamento. Isso assume um time de 2-3 desenvolvedores trabalhando sem grandes mudanças de design. Se você também está redesenhando, adicione 2-3 semanas para a fase de design.

Posso migrar WordPress para Next.js sem perder rankings de SEO?

Absolutamente, mas requer planejamento cuidadoso. Os elementos críticos são: manter estruturas de URL onde possível, implementar redirecionamentos 301 para qualquer URL que mude, preservar todos os meta tags e dados estruturados, e garantir que o novo site tenha paridade de conteúdo com o antigo. Uma queda temporária de 5-15% em tráfego orgânico é normal e deve se recuperar dentro de 2-4 semanas. O maior fator de risco é redirecionamentos faltantes — um mapeamento de redirecionamento botado pode derrubar uma seção do tráfego do seu site.

Devo usar WordPress como um CMS headless com Next.js ou mudar completamente para um CMS diferente?

Depende do seu time. Se seus editores de conteúdo são profundamente familiares com WordPress e resistentes à mudança, WordPress headless com WPGraphQL é um meio termo razoável. Você consegue os benefícios do frontend Next.js mantendo a interface admin familiar. Porém, você ainda carrega o fardo de manutenção do WordPress (atualizações, patches de segurança, hospedagem). Se você está aberto a mudanças, CMSes headless de propósito específico como Sanity, Contentful ou Storyblok oferecem melhor conteúdo estruturado, colaboração em tempo real e menos sobrecarga operacional.

Quais são os maiores riscos durante uma migração de CMS?

Os três principais são: regressão de SEO de mapeamento de redirecionamento ruim (corrigível mas custoso em tráfego perdido), blowout de cronograma de descoberta inadequada (normalmente porque complexidade oculta surge no meio do build) e falha de adoção do editor (seu time se recusa a usar o novo CMS porque é muito diferente ou não foi construído com seus workflows em mente). Os três são evitáveis com planejamento adequado.

Quanto custa migrar do WordPress para Next.js em 2026?

Custos de agência variam de $15.000 para um pequeno site brochura a $500.000+ para migrações empresariais grandes com integrações complexas. A mediana para sites de negócios de médio porte é grosseiramente $50.000-$90.000 em uma agência especializada. Taxas de freelancer são tipicamente 40-60% mais baixas mas vêm com risco maior em torno de disponibilidade e gerenciamento de projeto. O custo é impulsionado principalmente pelo número de templates únicos, complexidade de integrações e volume de conteúdo que precisa de atenção manual.

Preciso migrar todo meu conteúdo de uma vez?

Não, e na verdade uma migração em fases geralmente reduz risco. Alguns times começam migrando suas páginas de marketing para Next.js enquanto mantêm o blog no WordPress, depois migram o blog em uma segunda fase. Você pode usar regras de reverse proxy para servir diferentes seções de diferentes origens sob o mesmo domínio. Esta abordagem adiciona alguma complexidade arquitetônica mas deixa você lançar mais rápido e validar a abordagem antes de ir tudo-em-um.

Qual é a diferença entre uma replatform e um redesign?

Uma replatform move o design e conteúdo existentes do seu site para nova tecnologia (WordPress para Next.js) com mudanças visuais mínimas. Um redesign muda a aparência, sensação e potencialmente a arquitetura de informações. Combinar ambos em um projeto é comum mas adiciona 30-50% ao cronograma. Se orçamento ou cronograma é apertado, recomendo replatformar primeiro, depois redesenhar iterativamente uma vez que você está na nova stack.

Posso usar Astro em vez de Next.js para minha migração?

Sim, e para sites com mucho conteúdo com interatividade mínima, Astro pode ser uma escolha excelente. Astro envia zero JavaScript por padrão e suporta hidratação parcial ("arquitetura de ilhas"), o que significa suas páginas de conteúdo carregam incrivelmente rápido. Next.js é melhor quando você precisa de interatividade heavy do lado do cliente, autenticação ou recursos em tempo real. Fizemos migrações para ambos os frameworks e a escolha correta depende inteiramente dos requisitos do seu site.