Quanto tempo demora uma migração para headless WordPress em 2026?
Seis a dezasseis semanas para projetos típicos. A forma é em quatro fases: descoberta, scoping, construção e cutover, afinação. As variáveis que esticam ou comprimem o cronograma são o tamanho do catálogo, o número de integrações, a preservação de URLs e a prontidão da equipa editorial, não a escolha do framework.
Este artigo está ancorado no pilar de serviços headless WordPress e emparelha com a matriz de decisão Next.js vs Astro para o ângulo do framework e com Cloudflare Workers e WordPress no edge para a camada de runtime.
TL;DR
- Sites apenas editoriais com menos de cinquenta páginas: quatro a seis semanas.
- WooCommerce até alguns milhares de SKUs com integrações standard: dez a catorze semanas.
- Multi-região ou multilingue com integrações personalizadas: catorze a dezasseis semanas, por vezes mais.
- As semanas caras são o scoping (semana um e dois) e o cutover (último fim de semana), não a construção em si.
- O preço é individual por projeto; publicamos o cronograma, não o preço.
As quatro fases em tempo real
As fases não são rótulos num diagrama de Gantt; mapeiam-se em modos de trabalho distintos que precisam de pessoas diferentes na sala.
Fase 1, descoberta (semana zero a duas)
As partes envolvidas, a equipa editorial, o responsável de analítica e o contacto técnico passam por três a cinco sessões ao longo de uma a duas semanas. Os entregáveis são uma auditoria do modelo de conteúdo, uma baseline de desempenho retirada do site em produção (TTFB, TTI, LCP por template), um inventário de plugins e integrações e um esboço do mapa de migração SEO.
O resultado da descoberta é input de decisão, não arquitetura. A equipa que salta a descoberta para “poupar tempo” paga o custo de volta na semana oito, quando aparece uma integração não declarada e a camada de dados precisa de ser redesenhada.
Fase 2, scoping (semana dois a três)
Decisão de arquitetura: Astro 5+ ou Next.js 15, escolha do rendering por rota, padrão de obtenção de dados (REST ou GraphQL), estratégia de invalidação de cache. O mapa de redirecionamentos é assinado aqui, não mais tarde. O fluxo editorial é finalizado: pré-visualizações, rascunhos, publicações agendadas, fluxos com vários autores.
O scoping termina com um engagement letter escrito e uma lista fechada de entregáveis. Tudo o que faltar aqui torna-se uma change order na semana dez, que é o momento mais caro para negociar âmbito.
Fase 3, construção e cutover (semana três a doze)
A construção corre em sprints de duas semanas com uma demo semanal. Cada demo é em staging, não em localhost, para que a equipa veja como o lado editorial se comporta de facto na nova stack. O primeiro sprint é o design system e um único template ponta a ponta; os sprints seguintes distribuem-se por tipo de template.
O próprio cutover é uma janela de quarenta e oito a setenta e duas horas, planeada deliberadamente. Dois padrões funcionam: troca de DNS (mais limpa, rollback mais lento) e cutover por reverse proxy (rollback mais rápido, mais peças móveis). O mapa de redirecionamentos é aplicado no edge, não em PHP.
A janela de medição lado a lado corre uma a duas semanas antes do cutover. Apanha regressões em etiquetas de tracking, validação de schema e Core Web Vitals antes de chegarem a produção.
Fase 4, afinação e retainer (semana doze a dezasseis)
Os TTLs de cache no edge são afinados por rota. A observability (Cloudflare Logpush, testes sintéticos, alertas em TTFB e taxas 5xx) é ligada. A entrega ao retainer cobre trabalho de novas funcionalidades, revisões trimestrais de Tech Radar e um roadmap para as necessidades em evolução da equipa editorial.
Esta é a fase mais frequentemente saltada. Saltá-la custa seis meses de incidentes de baixa intensidade que a equipa não consegue diagnosticar porque nada está instrumentado.
O que estica o cronograma
Três padrões empurram um projeto de seis semanas para doze e um projeto de doze semanas para vinte.
Descoberta tardia de integrações. Um gateway de pagamento personalizado, uma integração de ERP legado por SOAP, um plugin de nicho sem superfície REST. Cada um exige um adaptador à medida. Cada adaptador acrescenta duas a quatro semanas de construção, mais negociação contratual se um terceiro detiver o sistema upstream.
Preservação de URLs. Um site com trinta padrões únicos de URL é trabalho mecânico. Um site com trezentos padrões mais uma reestruturação de permalinks é um projeto à parte. O mapa de 301 é assinado no scoping, não improvisado na semana dez.
Reformulação do modelo de conteúdo. Quando o conteúdo WordPress existente está estruturado em torno dos templates do tema em vez de campos estruturados, o frontend não consegue consumi-lo de forma determinística. Reconstruir o modelo de conteúdo acrescenta duas a seis semanas e exige disponibilidade da equipa editorial que a maioria das equipas subestima.
O que comprime o cronograma
Quatro condições encurtam o calendário de forma consistente.
Modelo de conteúdo limpo. Custom post types, grupos de campos ACF ou Meta Box, ou uma mudança recente para o editor de blocos com padrões estruturados. O frontend lê dados estruturados e renderiza de forma determinística. Poupa duas a quatro semanas.
Design system pré-existente. Uma biblioteca em Figma, um conjunto de tokens ou uma biblioteca de componentes que a equipa já usou antes. Poupa uma a duas semanas de trabalho de fundação no primeiro sprint.
Disponibilidade da equipa editorial. Quando a equipa editorial pode estar presente em pré-visualizações semanais e aprovar fluxos, a construção não fica parada à espera de esclarecimentos. Poupa uma a duas semanas ao longo do projeto.
Equipa sénior dos dois lados. Um senior product owner do lado do cliente reduz para metade o ciclo de pergunta e resposta. A agência não pode fabricar isto; tem de vir do comprador.
Quando a resposta de seis semanas está errada
Uma loja WooCommerce com três mil SKUs e um checkout personalizado não migra em seis semanas. Quem cota esse cronograma está a vender um âmbito diferente e a renegociar mais tarde. A resposta honesta para este perfil é doze a catorze semanas.
Um site multi-região com cinco locales e fluxos de comércio específicos por locale também não é um projeto de seis semanas. Fluxos de tradução, validação de hreflang, estratégias de cache específicas por locale e integrações de pagamento por região acrescentam quatro a seis semanas mesmo a uma baseline saudável.
Quando a resposta de dezasseis semanas está errada
Um site editorial pequeno, uma instalação WordPress fresca, um modelo de conteúdo limpo e uma equipa sénior conseguem entregar em cinco semanas. Cotar dezasseis para este perfil é âmbito inflacionado.
Um site headless greenfield (sem componente de migração, apenas um novo frontend num WordPress novo) salta a maior parte da fase um e encurta a fase três. Seis a oito semanas no total.
Como é o preço
O preço é individual por projeto. Não publicamos preços de serviços no site público. O engagement letter liga horas às quatro fases acima, com um teto fixo na fase um (está limitada pelo número de entrevistas, não por algo que escale) e time-and-materials ou fixed-scope na fase três (consoante a estabilidade do âmbito após o scoping).
Faturamos em EUR ou USD, jurisdição UE, contrato B2B. Veja o pilar de serviços headless WordPress para o modelo de colaboração.
Cluster reading
Os artigos de apoio do cluster, por tema.
- Cloudflare Workers e WordPress no edge sobre a camada de runtime da nova stack.
