Drupal 10 chega ao fim de suporte a 9 de dezembro de 2026: atualizar para o 11 ou migrar

O Drupal 10 deixa de receber correções a 9 de dezembro de 2026, seis semanas depois da data deste artigo. Na mesma semana sai o Drupal 12. Quem tem um site em Drupal 10, ou ainda em Drupal 7, tem três caminhos: atualizar para o Drupal 11, comprar algum tempo dentro do que a política do Drupal permite, ou migrar para outra plataforma. Trabalho com Drupal e com WordPress. Este guia reúne os prazos oficiais, o procedimento de atualização que sigo, o que acontece a quem ainda está no Drupal 7 e quando é que uma migração para WordPress faz sentido.

As datas e os requisitos vêm do drupal.org e foram lidos a 28 de outubro de 2026. O calendário do Drupal muda pouco, mas confirme a página oficial antes de fechar um orçamento.

#Drupal 10 fim de suporte: quando acaba e o que muda?

O calendário oficial de versões do Drupal diz que o Drupal 10 chega ao fim de vida a 9 de dezembro de 2026 e que não haverá novas versões do Drupal 10 depois dessa data. O Drupal 10.6.0 é a última versão menor. A versão mais recente no momento em que escrevo é a 10.6.20, publicada a 21 de outubro de 2026, segundo o feed de versões do núcleo.

O mesmo calendário marca a semana de 7 de dezembro de 2026 para o lançamento do Drupal 12.0.0 e do 11.5.0, e para o fim do suporte de segurança das séries 11.3.x e 10.6.x. Este detalhe tem consequências práticas: quem atualizar agora para o 11.3 fica sem correções na mesma semana que quem ficou no 10.6. O alvo certo hoje é a série 11.4, cuja versão mais recente é a 11.4.11, também de 21 de outubro de 2026.

A página da equipa de segurança do Drupal é direta: só as versões suportadas recebem apoio da equipa de segurança, e quem usa uma versão sem suporte deve atualizar. Para um site Drupal 10, isso quer dizer que a partir de dezembro uma vulnerabilidade no núcleo deixa de ter correção oficial.

A política geral, descrita na visão geral do processo de lançamento, explica o ritmo:

• sai uma versão principal a cada dois anos;
• cada versão principal tem suporte durante pelo menos quatro anos, até sair a segunda versão principal seguinte;
• as versões menores saem em junho e dezembro, e cada uma tem suporte durante um ano, com correções gerais nos primeiros seis meses e só de segurança nos últimos seis;
• uma versão principal só tem suporte enquanto as suas dependências principais (o PHP, o Symfony) também o tiverem.

A data de fim do Drupal 11 ainda não está publicada. Com a regra dos quatro anos e das duas versões seguintes, o Drupal 11 continua suportado depois do lançamento do Drupal 12, mas não conte com uma data concreta até ela aparecer no calendário.

#O que acontece a um site Drupal 10 depois de 9 de dezembro de 2026?

O site continua a abrir no dia 10 de dezembro. As mudanças estão na segurança do núcleo, nos módulos contribuídos e no servidor.

Primeiro, a segurança do núcleo. Uma falha descoberta depois do fim de vida fica sem correção oficial, e o anúncio público dessa falha documenta o problema para quem a quiser explorar.

Segundo, os módulos contribuídos. Os mantenedores concentram o trabalho nas versões suportadas. Um módulo que hoje publica versões para o 10 e para o 11 pode, na próxima versão, deixar de aceitar o Drupal 10 na restrição do Composer. A partir daí o site fica preso a versões antigas também dos módulos.

Terceiro, o servidor. O Drupal 10 exige pelo menos PHP 8.1, segundo a tabela de requisitos de PHP. Quando o fornecedor de alojamento retirar versões antigas do PHP, um site parado no Drupal 10 com módulos antigos tem cada vez menos margem para acompanhar.

Para um site institucional com formulários, áreas reservadas ou dados pessoais, esta combinação é difícil de justificar perante uma auditoria de segurança.

#Atualizar, ganhar tempo ou migrar: como decidir

A tabela resume a decisão por perfil de site. É a grelha que uso na primeira conversa com um cliente, antes de olhar para o código.

“Ganhar tempo” tem um limite claro. A 28 de outubro de 2026 não encontrei nenhuma oferta publicada de suporte alargado para o Drupal 10. A página de parceiros de suporte alargado do drupal.org trata apenas do Drupal 7. O tempo que se pode ganhar está dentro do próprio Drupal: passar para o 11.4 agora e deixar o Drupal 12 para quando os módulos de que o site depende tiverem versões estáveis.

Se a comparação entre plataformas ainda está em aberto, a comparação de CMS para grandes sites corporativos põe o Drupal ao lado do WordPress e do TYPO3 com os mesmos critérios.

#Calendário: Drupal 10, 11 e 12 lado a lado

Os requisitos técnicos mudam bastante entre as três versões, e é aqui que os orçamentos falham. Os números vêm da tabela de PHP e dos requisitos de base de dados.

O Drupal 11.3 e seguintes aceitam PHP 8.5, que é a única versão aceite pelo Drupal 12. Se o alojamento já oferece PHP 8.5, pode atualizar para o Drupal 11.4 diretamente nessa versão e evitar uma segunda mudança de PHP no próximo ano. Os requisitos do servidor web pedem Apache 2.4.7 ou superior, ou Nginx 1.1 ou superior; um site em IIS precisa de mudar de servidor antes do Drupal 11.

#Como atualizar do Drupal 10 para o Drupal 11

O guia oficial de atualização do Drupal 10 para o 11 define as condições de partida: o site tem de estar no Drupal 10.3.0 ou posterior, o servidor precisa de PHP 8.3.0 ou superior e é preciso acesso à linha de comandos com Composer e Drush. O procedimento abaixo é o que sigo, sempre numa cópia do site e nunca diretamente em produção.

#1. Cópia do site e inventário

Faço uma cópia completa: base de dados, ficheiros carregados e o repositório com o composer.json e o composer.lock. Monto um ambiente de testes com a mesma versão de PHP que o alojamento vai ter depois da atualização. Antes de qualquer alteração, registo a lista de módulos ativos (drush pm:list --status=enabled), as versões e os patches aplicados no composer.json.

#2. Drupal 10 na última versão 10.6.x

Se o site está abaixo do 10.3, a primeira etapa é chegar à última 10.6.x e correr drush updatedb. Esta etapa já fecha muitos problemas de segurança e é a base de partida que o guia exige. Num site muito atrasado, faço esta etapa como entrega separada, para que o cliente tenha um site suportado até dezembro mesmo que o resto se atrase.

#3. Relatório do Upgrade Status

Instalo o módulo Upgrade Status na cópia. Ele avalia se o ambiente e os componentes do site estão prontos para a versão principal seguinte: versão de PHP, base de dados, cada módulo e tema contribuído e o código próprio. O relatório divide os módulos contribuídos em três grupos: os que já têm versão para o Drupal 11, os que têm versão em desenvolvimento e os que não têm nada. É este terceiro grupo que define o tamanho do projeto.

#4. Código próprio: Drupal Rector e drupal-check

Para módulos e temas desenvolvidos à medida, corro o Drupal Rector, que corrige automaticamente chamadas obsoletas; a cobertura documentada vai do Drupal 10.0 ao 11.4. Depois verifico o resultado com o drupal-check, uma análise estática baseada no PHPStan que encontra erros de obsolescência. O Rector não resolve tudo: hooks com assinaturas novas, serviços renomeados e código que mexe na base de dados diretamente ainda pedem revisão manual.

#5. Módulos contribuídos sem versão compatível

Muitos módulos funcionam no Drupal 11 e só falta atualizar a linha core_version_requirement. Para esses casos, o guia oficial recomenda o Drupal Lenient Composer plugin, que reescreve a restrição de versão para aceitar o núcleo instalado. Cada pacote tem de ser listado em extra.drupal-lenient.allowed-list, e aplico o patch de compatibilidade da fila de problemas do módulo. Se um módulo não tem manutenção, procuro um substituto ou passo a funcionalidade para código próprio.

#6. Módulos retirados do núcleo

O Drupal 11 retirou do núcleo o Actions UI, o Activity Tracker, o Book, o Forum, o Statistics e o Tour. Todos têm projeto contribuído, segundo a página de módulos obsoletos e removidos. Se o site usa algum deles, instalo a versão contribuída ainda no Drupal 10, confirmo que tudo funciona e só depois atualizo o núcleo. O CKEditor 4 já tinha saído do núcleo no Drupal 10, e um site que ainda dependa dele está atrasado em mais do que uma versão.

#7. Atualizar o núcleo e testar

Com o relatório limpo, atualizo drupal/core-recommended e os pacotes relacionados para a série 11.4 com o Composer, corro drush updatedb e drush cache:rebuild, e testo os fluxos que os editores usam todos os dias: criar e publicar conteúdo, traduzir, carregar imagens, formulários, pesquisa e permissões por papel. Só quando a cópia passa esses testes é que repito o processo em produção, com cópia de segurança feita imediatamente antes.

#8. Preparar já o Drupal 12

O Drupal 12 retira mais módulos do núcleo: Ban, Contact, Field Layout, History, Telephone, Search, Settings Tray e Shortcut ficaram obsoletos ao longo do 11.x, e a Toolbar sai do núcleo no 12.0.0. Os temas Claro e Olivero ficaram obsoletos no 11.5.0 e são removidos no 12.0.0; para a administração, o drupal.org indica o novo tema Default Admin. Na atualização para o 11 aproveito para registar quais destes o site usa. Assim o passo seguinte fica orçamentado desde o início.

Quando pede um orçamento, envio primeiro o relatório do Upgrade Status corrido numa cópia, e a partir dele a conversa passa a ser uma lista de trabalho. Na página de desenvolvedor Drupal descrevo como faço essa auditoria inicial.

#O site ainda está em Drupal 7: o que fazer agora?

O suporte de segurança do Drupal 7 terminou a 5 de janeiro de 2025. Desde essa data, o Drupal 7 não recebe atualizações de segurança nem de compatibilidade. A página de parceiros lista empresas que oferecem suporte alargado pago para o Drupal 7, o que dá tempo, mas não resolve a migração.

O Drupal 12 muda a situação dos sites Drupal 7. A migração do Drupal 7 para versões modernas usa o módulo Migrate Drupal do núcleo e, para quem prefere uma interface, o Migrate Drupal UI. Segundo a página de módulos obsoletos, ambos ficaram obsoletos durante o 11.x e são removidos no Drupal 12.0, e nenhum passa para projeto contribuído. A tarefa de remoção do Migrate Drupal está fechada. O Drupal 12 mantém a API de migração, sem as fontes do Drupal 6 e 7.

Na prática, um site Drupal 7 que queira o caminho do núcleo migra para o Drupal 11, enquanto o 11 tiver suporte, e depois segue o ciclo normal até ao 12. Começar um projeto de migração do Drupal 7 diretamente sobre o Drupal 12 obriga a escrever ou manter as fontes de migração por conta própria.

Há uma segunda opção dentro do ecossistema. O Drupal CMS 2.0, lançado a 28 de janeiro de 2026 e construído sobre o núcleo 11.3, traz o Drupal Canvas como editor visual por omissão e modelos de site que servem de ponto de partida. Para um site Drupal 7 antigo, refazer a estrutura sobre o Drupal CMS e migrar só o conteúdo pode dar menos trabalho do que transportar anos de configuração acumulada.

A terceira opção é sair do Drupal, e para isso o Drupal 7 não é obstáculo: as ferramentas de migração para WordPress leem bases de dados de várias versões do Drupal, como explico mais abaixo.

#Existe suporte alargado para o Drupal 10?

A 28 de outubro de 2026, a página da HeroDevs sobre suporte alargado de Drupal refere apenas o Drupal 7, a página de parceiros do drupal.org trata apenas do Drupal 7 e não consegui confirmar nenhuma oferta para o Drupal 10 junto de outros fornecedores. Se aparecer uma, vale a pena ler as condições com atenção: quais módulos cobre, até quando e em que versões de PHP.

Enquanto isso não existir, o tempo que se pode comprar é o do próprio Drupal 11. A série 11.4, lançada na semana de 29 de junho de 2026, tem segundo a política um ano de suporte, e o 11.5 sai em dezembro. Um site no 11.4 está coberto enquanto prepara a passagem para o 12 com calma.

#Drupal em organismos públicos em Portugal: o que pesa na decisão

Em Portugal, o Drupal aparece com frequência em universidades, institutos e câmaras municipais, onde há muitos editores, várias unidades orgânicas com permissões próprias e conteúdo em mais de uma língua. Para estes organismos, o fim do Drupal 10 cruza-se com duas obrigações.

A primeira é a acessibilidade. O Decreto-Lei n.º 83/2018, de 19 de outubro, define os requisitos de acessibilidade dos sítios web e das aplicações móveis de organismos públicos e transpõe a Diretiva (UE) 2016/2102. Uma atualização de versão principal é uma boa ocasião para rever o tema, os formulários e o editor, porque é exatamente aí que a atualização mexe. No setor privado, a Diretiva (UE) 2019/882, o Ato Europeu de Acessibilidade, aplica-se desde 28 de junho de 2025 a alguns serviços prestados a consumidores, entre eles o comércio eletrónico e os serviços bancários.

A segunda é o calendário da contratação pública. Um procedimento de contratação pública para a atualização, com caderno de encargos, prazos de propostas e adjudicação, raramente cabe em seis semanas. A forma de reduzir o risco é separar o trabalho: manter o Drupal 10 na última versão 10.6.x até dezembro, e lançar a atualização para o 11 como contrato próprio, com o relatório do Upgrade Status anexo ao caderno de encargos para que as propostas partam do mesmo levantamento.

Um caderno de encargos para esta atualização deve fixar, pelo menos, a versão de destino (11.4 ou superior), a versão de PHP do alojamento, a lista de módulos contribuídos e personalizados com o estado de cada um, os módulos retirados do núcleo que o site usa, os testes de aceitação dos fluxos editoriais e a obrigação de entregar a configuração no repositório. Para organismos que estão a pensar na plataforma a longo prazo, a página sobre websites para órgãos governamentais descreve como trabalho com o setor público.

#Migrar de Drupal para WordPress: o que passa e o que não passa

O WordPress é a plataforma mais usada na web: segundo a W3Techs, a 28 de outubro de 2026, é usado por 39,5% de todos os sites, com 58,3% de quota entre os sistemas de gestão de conteúdos, contra 0,6% e 0,9% do Drupal. Numa decisão de migração, a forma como a equipa trabalha pesa mais do que estes números.

A ferramenta mais usada para esta migração é o plugin FG Drupal to WordPress, testado com o Drupal 4 a 11, segundo a página do plugin no wordpress.org. A tabela separa o que a versão gratuita e a versão premium importam, segundo essa mesma página.

O plugin lê bases de dados MySQL, PostgreSQL e SQLite do Drupal. O WP-CLI, por si, só importa ficheiros WXR com o comando wp import e não tem um importador nativo para o Drupal.

Há trabalho que nenhuma ferramenta faz por si:

• As listagens, filtros e páginas construídas com Views têm de ser refeitas como modelos de tema, blocos de consulta ou código próprio.
• Os papéis e permissões finas do Drupal não têm equivalente direto; os papéis do WordPress são mais simples e o resto exige plugins ou código.
• As aprovações editoriais com estados (rascunho, revisão, publicado) feitas com Content Moderation precisam de outra solução.
• A estrutura de traduções do Drupal passa para um plugin multilingue do WordPress, e o mapeamento entre traduções verifica-se página a página nas secções mais visitadas.
• O conteúdo montado em Paragraphs não vira blocos do editor sem um mapeamento escrito para o site concreto.

O WordPress atual é a versão 7.1.3, e o wordpress.org recomenda PHP 8.3 ou superior e MariaDB 10.11 ou MySQL 8.0 ou superior. Na prática, o alojamento que serve para o Drupal 11 também serve para o WordPress.

Se o perfil do site aponta para o WordPress, a avaliação de migração para WordPress é o primeiro passo, e a página de desenvolvedor WordPress descreve o trabalho depois da migração. Para quem compara com outro CMS empresarial, tenho uma página sobre o desenvolvimento em TYPO3.

#Quando ficar no Drupal é a melhor escolha

Uma migração tem custos que não aparecem na primeira estimativa: formação de editores, novos fluxos, URL a redirecionar, integrações a refazer. Recomendo ficar no Drupal quando:

• há muitos editores com permissões diferentes por secção, unidade ou tipo de conteúdo;
• o site publica em várias línguas com fluxos de tradução próprios;
• a mesma instalação serve vários sites;
• há integrações com sistemas internos escritas como módulos Drupal, que funcionam e que alguém conhece;
• a equipa técnica já domina Composer, Drush e o modelo de configuração do Drupal.

Nestes casos, a atualização para o Drupal 11 é um projeto finito e a migração seria um projeto novo. O Drupal também assenta no Symfony, por isso uma equipa com experiência em PHP moderno encontra no Drupal 11 ferramentas que já conhece.

#Problemas frequentes na atualização para o Drupal 11

#O que fazer esta semana e este mês

Esta semana:

• confirmar a versão exata do núcleo em Relatórios, Relatório de estado;
• confirmar a versão de PHP e da base de dados no alojamento;
• fazer uma cópia completa do site num ambiente de testes;
• instalar o Upgrade Status na cópia e guardar o relatório;
• atualizar o Drupal 10 para a última 10.6.x se ainda não estiver lá.

Este mês:

• classificar os módulos contribuídos: com versão para o 11, em desenvolvimento, sem versão;
• correr o Drupal Rector no código próprio e corrigir o resto;
• instalar as versões contribuídas dos módulos retirados do núcleo que o site usa;
• atualizar a cópia para o 11.4 e testar os fluxos editoriais;
• decidir, com o relatório na mão, entre atualizar e migrar, e registar a razão;
• marcar a passagem para produção antes de 9 de dezembro de 2026.

Para um site Drupal 7, a lista é outra: escolher já o destino (Drupal 11, Drupal CMS ou WordPress) e começar a migração de conteúdo enquanto o Migrate Drupal ainda existe no núcleo.

Se quiser que corra esta auditoria no seu site, a página de desenvolvedor Drupal explica o que preciso para começar: acesso de leitura ao repositório e uma cópia da base de dados.