Migração Next.js / Astro em Lisboa

#Em Lisboa o calendário decide antes do framework

Num site de reservas de Lisboa, a pergunta mais importante de um projeto de migração não é técnica, é de agenda. Entre maio e setembro, um hotel ou um operador de experiências fatura uma parte desproporcionada do ano, e nenhum ganho de Core Web Vitals justifica pôr essa receita em jogo. Por isso planeamos migrações de trás para a frente, a partir do calendário: construção e testes durante a época alta, sem tocar no sistema em produção, cutover nas primeiras semanas de novembro, quando a ocupação cai, e janela de medição ao longo da época baixa, para que o sistema novo chegue ao primeiro verão já validado. Cutover em julho é uma expressão que não existe no nosso vocabulário. Para uma loja que exporta, o raciocínio é o mesmo com outras datas: a Black Friday e o Natal fazem o papel do agosto.

A janela de medição dura tipicamente quatro a oito semanas. Observamos o estado de indexação e o comportamento de crawling na Search Console, os rankings dos termos que trazem reservas nas três línguas, os Core Web Vitals com dados de utilizadores reais e as taxas de erro da camada de redirecionamentos. Oscilações pequenas nas primeiras duas semanas fazem parte, porque os motores de busca digerem os sinais novos aos poucos; o que interessa é a tendência ao longo da janela inteira.

E o regresso? Antes de qualquer alteração de DNS, o caminho de volta já foi ensaiado em ambiente de teste. O sistema antigo permanece intocado e operacional durante toda a janela de medição, a mudança faz-se por DNS ou routing e desfaz-se em minutos se surgir um problema que não se resolva depressa; a análise do erro faz-se depois, com calma, fora de produção. Só quando os indicadores estabilizam no nível de partida ou acima é que o sistema antigo é congelado e arquivado. Guardamos essa cópia, porque a pergunta por um conteúdo de há seis anos chega sempre quando ninguém está à espera.

#Três línguas, um risco: hreflang em sites PT, EN e FR

A segunda especificidade de Lisboa é linguística. Uma fatia enorme dos sites de hotelaria, restauração e experiências da cidade vive em português, inglês e francês, e vive sobretudo de tráfego internacional. Isso faz do hreflang a peça mais sensível de toda a migração: um mapa de alternates mal reconstruído envia utilizadores franceses para a versão inglesa durante semanas, e ninguém dá por nada, porque o site “funciona”. Reconstruímos o esqueleto hreflang URL a URL, validamo-lo contra o inventário completo e comparamos o resultado com o sistema antigo de forma automatizada antes do cutover.

O inventário em si nasce de três fontes. O crawl do sistema antigo e os dados de desempenho da Search Console dão o retrato oficial, mas contam só metade da história. A metade que falta está nos logs do servidor dos últimos meses: endereços que já não constam de nenhum sitemap nem recebem links, e mesmo assim continuam a ser abertos por pessoas, vindos de newsletters de 2019, de marcadores, de threads em fóruns de viagem e de PDFs com o URL impresso. Quem monta o mapa de redirecionamentos sem os logs deixa esses visitantes a cair em páginas 404 e nunca chega a sabê-lo.

Cada endereço do inventário recebe então uma decisão explícita: mantém-se no mesmo URL, é redirecionado por 301 para um sucessor, ou é reformado com o código de estado certo, e essa reforma fica escrita. Em instalações Joomla antigas aparecem quase sempre famílias de URLs esquecidas, por exemplo endereços com index.php e parâmetros que foram indexados em paralelo às versões SEF e produzem conteúdo duplicado há anos; a migração é o momento de fechar essas contas. O mesmo cuidado vale para dados estruturados: o schema de hotel, de produto ou de evento que uma extensão gerava no sistema antigo tem de renascer no frontend novo, ou os rich snippets desaparecem em silêncio.

#A herança das agências: Joomla e Drupal ainda em produção

Os projetos que nos chegam de Lisboa raramente partem de um sistema saudável, e a razão está na história digital da cidade, que acumulou três camadas. A mais antiga é a do turismo: uma parte considerável dos sites de alojamento, restauração e experiências foi construída entre 2008 e 2015, quando Joomla e Drupal dominavam as agências locais. Esses sites continuam online, em três línguas, com motores de reserva pendurados por iframe e extensões que ninguém atualiza desde que o programador original mudou de vida. A segunda camada nasceu com a Web Summit e o ecossistema que cresceu à sua volta: startups internacionais com equipas mistas e sites MVP montados num fim de semana antes de uma ronda de financiamento, que nunca mais foram substituídos e servem públicos em inglês antes do português. A terceira é o comércio local a crescer para exportação: cortiça, conservas, cerâmica e vinho a vender para Espanha, França e Reino Unido a partir do alojamento partilhado barato que chegava para o mercado nacional.

Para as três camadas, um frontend moderno em Astro ou Next.js é uma saída realista, desde que o projeto seja tratado como aquilo que é: uma mudança de casa com inventário, não um recomeço de bulldozer. Tudo o que está nas secções anteriores, o calendário, o hreflang e o inventário de URLs, existe para que a mudança leve consigo os anos de visibilidade acumulada em vez de os deixar no passeio.

#Astro ou Next.js, decidido rota a rota

A escolha do framework é tratada muitas vezes como questão de fé. Nos nossos projetos é uma tabela com tipos de página. O Astro gera as páginas no build como HTML estático e só entrega JavaScript onde um componente o pede expressamente; para presenças institucionais, páginas de quartos e tarifas, blogues e landing pages é a arquitetura mais eficiente disponível: entrega rápida, nenhum servidor no caminho do pedido, superfície de ataque mínima. O Next.js justifica-se quando as páginas mudam por utilizador: áreas de cliente, motores de reserva com disponibilidade em tempo real, pesquisas com filtros complexos.

Para muitas empresas de Lisboa a resposta honesta é: os dois, em sítios diferentes. O site de marketing do hotel em três línguas corre como build Astro, o fluxo de reserva com disponibilidade e pagamento corre como aplicação Next.js, ambos atrás do mesmo domínio, separados por routing. Quem constrói tudo em Next.js por princípio paga infraestrutura de servidor para páginas que o HTML estático serviria melhor; quem espreme tudo em Astro por princípio deforma aplicações interativas num modelo que não foi pensado para elas.

Há ainda a pergunta que costuma ficar esquecida: quem trata do sistema depois de nós? Projetos Astro com Markdown ou ligação a CMS são mantidos sem drama por equipas pequenas. Aplicações Next.js pedem experiência de React, que nas startups pós-Web Summit costuma existir e numa agência de hotelaria com um webmaster a tempo parcial normalmente não existe. Documentamos a decisão rota a rota, com justificação, para que continue legível daqui a dois anos, mesmo com outras pessoas na sala. Uma comparação detalhada e independente da cidade está no nosso guia de migração para Astro e Next.js.

#A redação não pára: publicar durante o projeto

A preocupação que mais vezes abre as primeiras conversas não é técnica: podemos continuar a publicar durante a migração? Podem, e a arquitetura é a razão. Na maioria dos nossos projetos o WordPress mantém-se integralmente como backend editorial. A vossa equipa trabalha na interface de sempre, com os mesmos fluxos, papéis e aprovações, e o frontend novo vai buscar os conteúdos pela REST API ou pelo WPGraphQL para construir as páginas entregues.

As consequências práticas são três. Não há content freeze de semanas: até ao cutover os conteúdos novos aparecem no frontend antigo, depois no novo, e a data da mudança custa à equipa poucas horas. A formação quase desaparece, porque a ferramenta de trabalho não muda, muda o que os visitantes veem. E o risco do projeto desce, porque conteúdos e frontend evoluem em separado; se algo falha no frontend, os conteúdos ficam intactos.

Com sistemas Joomla ou Drupal antigos o caminho é outro, porque aí o backend costuma ser parte do problema. Extraímos os conteúdos da base de dados, limpamo-los e passamo-los para um backend WordPress novo ou, em volumes pequenos, diretamente para Markdown versionado no projeto Astro. Para equipas que vêm do Joomla, a mudança para o editor do WordPress tem sido, pela nossa experiência, um alívio e não um obstáculo. Se a evolução da vossa base WordPress já estiver na agenda, a migração encaixa no desenvolvimento WordPress em Lisboa: um interlocutor para backend e frontend.

#RGPD e geografia de dados

Uma migração altera os fluxos de dados, e isso pertence ao planeamento do projeto, não à correção posterior. Três perguntas são esclarecidas por norma. Onde se constrói e entrega? Builds estáticos podem ser gerados e servidos em localizações europeias, e em plataformas globalmente distribuídas configuramos o processamento para que os dados pessoais fiquem na UE. O que acontece a formulários e serviços incorporados? A mudança é o momento certo para inventariar incorporações antigas, porque em instalações com dez anos aparecem serviços de terceiros que já ninguém usa mas continuam a carregar dados, de widgets de meteorologia a mapas com chaves expiradas. E o registo de atividades de tratamento: depois da migração documentamos os novos fluxos de dados de forma a que o vosso encarregado de proteção de dados o atualize sem ter de fazer engenharia inversa da arquitetura.

Um efeito lateral que nas conversas com empresas de Lisboa costuma pesar na decisão: um frontend estático sem CMS acessível ao público reduz drasticamente a superfície de ataque. O backend fica atrás de uma restrição de acesso e as páginas entregues não contêm ligação à base de dados que possa ser comprometida. Para hotelaria que processa dados de reservas e para lojas com clientes em vários países, isto não é um tema lateral.

#Migrar, relançar ou deixar estar: a mesma conta, três respostas

Migração e relançamento misturam-se nas conversas, mas designam coisas diferentes. Um relançamento renova design e conteúdos dentro do sistema existente; uma migração troca a base técnica e leva consigo conteúdos, URLs e visibilidade nos motores de busca. E há uma terceira resposta que raramente encontra lugar nas páginas de quem vive de vender projetos de migração, por razões fáceis de adivinhar: às vezes o melhor conselho é não mexer em nada de estrutural.

A favor da migração pesa o sistema antigo ser ele próprio o problema: instalações Joomla ou Drupal cujo caminho de atualização custaria mais do que reconstruir o frontend, temas WordPress onde cada alteração provoca efeitos secundários em sítios inesperados, lojas cujos tempos de carregamento não descem apesar dos plugins de cache empilhados, e cenários de segurança em que um CMS público com extensões abandonadas é um risco que nenhum contrato de manutenção cobre.

A favor de um relançamento no sistema atual pesa o sistema estar saudável e só o aspeto estar datado: um WordPress bem mantido, com PHP atual, tema leve e lista de plugins arrumada, precisa de bom design, não de arquitetura nova. E a favor de deixar estar pesa o problema real ser outro. Textos desatualizados não melhoram com um framework novo, apenas são entregues mais depressa. Um frontend moderno sem ninguém que assuma a sua operação envelhece tão depressa como o antigo. E um calendário contra o projeto, três semanas antes da época que concentra a faturação do ano, é motivo para adiar, não para acelerar. Dizemos isto no audit mesmo quando adia o projeto, porque uma migração feita à pressa por causa de um prazo cobra os atalhos a dobrar mais tarde.

Um indicador honesto da prática: se a vossa equipa editorial gosta do CMS e só os visitantes sofrem com o site, separar backend de frontend é a solução mais elegante. Se a equipa também luta contra o sistema todos os dias, a pergunta do backend entra na mesa. Avaliamos os três caminhos no audit sem posição pré-definida, porque trabalhamos em todos eles, mas só um é o certo para o vosso caso.

#Três projetos de Lisboa, três pontos de partida

Os nomes ficam de fora por contrato, mas estes três arranques descrevem com precisão o que costuma estar em cima da mesa quando uma empresa da cidade nos escreve.

O hotel boutique com motor de reservas: um alojamento em Alfama operava um site Joomla de 2012 em três línguas, com o motor de reservas acoplado por iframe e uma extensão de galeria que bloqueava a atualização do PHP. O tráfego vinha em dois terços de pesquisas em inglês e francês. A migração separou os dois mundos: as páginas de conteúdo, quartos, localização e histórias do bairro passaram para um build Astro com hreflang reconstruído URL a URL, o fluxo de reserva ficou como aplicação dedicada atrás do mesmo domínio. O cutover aconteceu em novembro, com a época baixa como janela de medição. Na primavera seguinte as três versões linguísticas estavam indexadas de forma estável e o site aguentou a época alta sem o alojamento cair, o que no sistema antigo acontecia todos os agostos.

A startup com o site MVP de 2020: uma empresa internacional do ecossistema pós-Web Summit tinha um site WordPress montado à pressa antes de uma ronda de financiamento, com page builder, vinte plugins e um blogue que a equipa de marketing alimentava em inglês. Quatro anos depois, o site era o cartão de visita mais lento da empresa. Como a equipa tinha experiência de React, a decisão foi Next.js para todo o site, com o WordPress a manter-se como backend headless para o blogue. O inventário de URLs revelou centenas de landing pages de campanhas antigas com backlinks ativos, que receberam destinos 301 em vez de desaparecerem. O cutover foi um não-evento de vinte minutos, e foi isso que se pretendia.

A loja a crescer para exportação: um comerciante de conservas e produtos de cortiça vendia há anos para o mercado nacional a partir de um WooCommerce em alojamento partilhado. Com a entrada nos mercados espanhol e francês, os tempos de carregamento internacionais e as quebras nas campanhas tornaram-se um travão à faturação. Em vez de uma mudança total de uma vez, o projeto foi faseado: primeiro as páginas de conteúdo e de categoria como build Astro entregue na borda da rede, o checkout ficou no WooCommerce comprovado. A época de Natal correu nas páginas novas e rápidas, a mudança do checkout seguiu-se em janeiro, com calma e sem risco de receita. A camada de entrega e os redirecionamentos correm na borda da rede, o padrão que descrevemos na página de desenvolvimento Cloudflare Workers em Lisboa. Para projetos deste tipo, migração e desenvolvimento WooCommerce em Lisboa trabalham de mãos dadas.

#Como trabalhamos com empresas de Lisboa

Trabalhamos em modelo remote-first, em inglês ou português conforme a equipa, a partir da UE e com apenas uma hora de diferença horária, o que na prática significa reuniões dentro do horário normal dos dois lados e nenhuma espera de um dia por respostas. Contratos no quadro jurídico europeu, interlocutores fixos e etapas aceites uma a uma.

No início está o audit de migração: levantamento do sistema antigo, inventário de URLs nas três línguas, avaliação dos conteúdos e uma recomendação fundamentada, mesmo que ela seja a de que não precisam de migração. Seguem-se a decisão de framework rota a rota, a construção em paralelo contra o backend em funcionamento, o cutover na época baixa com caminho de volta ensaiado e a janela de medição com relatório. Cada etapa termina com um resultado que se sustenta sozinho e com uma decisão sobre a continuação. Isso protege os dois lados: não ficam presos a um megaprojeto de fim incerto, e nós trabalhamos contra critérios de aceitação definidos em vez de expectativas móveis. O orçamento é individual e estimado etapa a etapa, não como pacote fechado sobre incógnitas que ninguém consegue quantificar a sério no arranque.

A entrega final inclui a documentação da arquitetura, da camada de redirecionamentos e dos processos de build, além da formação da vossa equipa. O critério de sucesso que usamos é prosaico: meio ano depois, a vossa equipa altera templates, publica e faz deploy sem precisar de nos telefonar. Quem quiser manutenção contínua tem um modelo de operação à disposição; quem não quiser fica com tudo o que é preciso para seguir sozinho. O primeiro passo não compromete nada: um audit com recomendação clara e uma estimativa de esforço com a qual podem decidir internamente.

Última atualização: 10 de julho de 2026