Migração Next.js / Astro em Praga

Passamos sites existentes do WordPress ou de um CMS mais antigo para uma arquitetura headless com frontend em Next.js ou Astro. O backend de conteúdo pode manter-se (WordPress como fonte headless via REST ou GraphQL) ou mudar, consoante quem edita os conteúdos no dia a dia. Não reconstruímos projetos que ficam mais baratos se forem corrigidos onde estão.

De forma incremental, por norma. O novo frontend assume uma secção de cada vez enquanto o resto continua a correr no sistema antigo, com um reverse proxy ou regras no edge a dividir o tráfego até concluirmos. Uma migração de uma só vez só faz sentido em sites pequenos, onde manter dois stacks em paralelo custa mais do que um corte limpo.

Mapeamos todos os URLs antigos antes de começar e associamo-los um a um no novo site, com redirecionamentos 301 sempre que um endereço muda. Títulos, meta, dados estruturados e canónicos transitam, e depois do lançamento acompanhamos a Search Console para detetar quebras de indexação cedo. Qualquer alteração de endereço fica registada por escrito de propósito, não como efeito secundário.

É um compromisso, não uma questão de fé. Escolho o Astro para sites com muito conteúdo (blogues, sites institucionais, documentação) porque envia zero JavaScript por omissão; Next.js quando há interatividade real, uma área autenticada ou renderização no servidor para dados dinâmicos. Deixo a recomendação por escrito para que a justificação possa ser revista um ano depois.

Protegemos os Core Web Vitals com um orçamento de desempenho no CI, por isso uma regressão no LCP ou no CLS falha o build antes de chegar a produção. O código segue com documentação, convenções e um pipeline de deploy que a sua equipa pode assumir sem nós. A passagem inclui o repositório, as variáveis de ambiente e um guia breve para publicar alterações.