Se você ainda está rodando Drupal 7 em produção, não vou sugarcoat: você está em tempo emprestado. Drupal 7 atingiu seu fim de vida oficial em 5 de janeiro de 2025, após múltiplas extensões remontando ao prazo original de novembro de 2021. Isso significa sem mais patches de segurança, sem mais suporte da comunidade, e sem mais fingir que a migração pode esperar até o próximo trimestre. Ajudei múltiplos times enterprise através dessa situação exata nos últimos anos, e os que esperaram até o último momento sempre pagaram mais — em dinheiro, em estresse, e em débito técnico. Este guia é tudo aquilo que gostaria de poder entregar a cada VP de Engenharia ainda rodando Drupal 7.

Sumário

Drupal 7 End of Life 2025: Migration Guide for Enterprise Teams

O que o Fim de Vida do Drupal 7 Realmente Significa

Vamos ser preciso sobre o que "fim de vida" significa na prática, porque vi muita confusão aqui:

  • Sem mais atualizações de segurança. O Time de Segurança do Drupal não emitirá avisos ou patches para o núcleo do Drupal 7 ou módulos contrib. Se uma vulnerabilidade crítica de SQL injection for descoberta amanhã, você está por conta própria.
  • Sem mais correções de bugs. Qualquer coisa quebrada permanece quebrada.
  • Mantenedores de módulos contrib estão partindo. A maioria já partiu. Muitos módulos populares do Drupal 7 não recebem uma atualização há anos.
  • Provedores de hospedagem descontinuarão o suporte. Pantheon, Acquia, e Platform.sh já anunciaram timelines para deprecar ambientes de hospedagem Drupal 7. Acquia estendeu seu suporte a Drupal 7 até 2026 para clientes existentes, mas isso é um add-on pago, não uma solução de longo prazo.
  • Problemas de compatibilidade com PHP se acumularão. Drupal 7 foi construído para PHP 5.x. Ele roda em PHP 8.1 com patches, mas o próprio PHP 8.1 atinge fim de vida em dezembro de 2025. Você estará empilhando software sem suporte em cima de software sem suporte.

O risco de segurança sozinho deveria ser suficiente para desencadear ação. Se sua organização lida com qualquer forma de PII, dados financeiros, ou informações de saúde, rodar Drupal 7 sem patches é uma responsabilidade de conformidade. PCI DSS, HIPAA, SOC 2 — todos exigem que você mantenha software patchado e suportado.

Por Que Times Enterprise Continuaram Atrasando

Tive essa conversa dúzias de vezes. As razões são sempre alguma variação de:

  1. "Nosso site Drupal 7 funciona bem." Funciona. Até não funcionar. O código não parará de funcionar em 6 de janeiro, mas o perfil de risco muda dramaticamente.
  2. "A migração de Drupal 8/9/10 não é um simples upgrade." Isso é realmente verdade. Diferente do caminho de upgrade Drupal 6→7, ir de Drupal 7 para Drupal moderno é essencialmente uma reconstrução. A arquitetura é fundamentalmente diferente — baseada em Symfony, gerenciamento de configuração, templates Twig. Seus módulos customizados não portem.
  3. "Temos 15 anos de conteúdo e funcionalidade customizada." Sites Drupal 7 enterprise tendem a ser altamente customizados. Módulos customizados, configurações do Views, estruturas de taxonomia complexas, integrações com sistemas legados. O escopo da migração é genuinamente grande.
  4. "O orçamento não foi aprovado." A resposta mais honesta, e a mais comum.

Nenhuma dessas razões desapareceu, mas o prazo chegou. Então vamos falar sobre o que realmente fazer.

Suas Opções de Migração em 2025

Você tem quatro caminhos realistas para frente. Cada um tem trade-offs. Deixe-me detalhar honestamente.

Opção Timeline Faixa de Custo Melhor Para Nível de Risco
Drupal 10/11 6-18 meses $200K-$1M+ Times investidos no ecossistema Drupal Médio
Frontend Headless + Backend Drupal 4-12 meses $150K-$600K Times querendo UX moderna com CMS familiar Médio
Migração CMS Headless 3-9 meses $100K-$500K Times prontos para deixar Drupal completamente Médio-Alto
Fornecedor de Suporte Estendido Imediato $30K-$100K/ano Times precisando de 6-18 meses a mais de tempo de planejamento Baixo (curto prazo)

Drupal 7 End of Life 2025: Migration Guide for Enterprise Teams - architecture

Opção 1: Migrar para Drupal 10/11

Drupal 10 é a versão estável atual em 2025, com Drupal 11 lançado em meados de 2024 e ganhando adoção. Se seu time conhece Drupal, seu modelo de conteúdo é sólido, e você quer ficar no ecossistema, este é o caminho mais direto.

Mas "direto" não significa "fácil."

O que a migração realmente envolve

Drupal fornece uma Migrate API que pode puxar conteúdo de um banco de dados Drupal 7 para um site Drupal 10/11. Na minha experiência, ela cobre cerca de 60-70% de uma migração típica. O resto é plugins de migração customizados para:

  • Tipos de campo customizados
  • Referências complexas de entidades
  • Paragraphs (se você usou o módulo Paragraphs)
  • Ativos de arquivo e mídia
  • Aliases de URL e redirecionamentos
  • Contas de usuário e papéis

Seus módulos customizados precisam ser reescritos. Não portados — reescritos. Drupal 10/11 usa uma arquitetura completamente diferente. Se você tinha um módulo customizado que hooked em hook_node_view(), você agora está escrevendo event subscribers e plugins.

// Drupal 7 - baseado em hook
function mymodule_node_view($node, $view_mode, $langcode) {
  if ($node->type == 'article') {
    $node->content['custom_field'] = array(
      '#markup' => '<div>' . custom_logic($node) . '</div>',
      '#weight' => 10,
    );
  }
}

// Drupal 10/11 - OOP, baseado em Symfony
namespace Drupal\mymodule\EventSubscriber;

use Drupal\core_event\NodeViewEvent;
use Symfony\Component\EventDispatcher\EventSubscriberInterface;

class NodeViewSubscriber implements EventSubscriberInterface {
  public static function getSubscribedEvents() {
    return [NodeViewEvent::class => 'onNodeView'];
  }
  
  public function onNodeView(NodeViewEvent $event) {
    $node = $event->getNode();
    if ($node->bundle() === 'article') {
      // Sua lógica aqui
    }
  }
}

A camada de template Twig também é completamente diferente de PHPTemplate. Cada tema customizado precisa ser reconstruído.

Timeline realista

Para um site enterprise de tamanho médio (500-5.000 páginas, 10-20 tipos de conteúdo, 5-10 módulos customizados), espere 9-15 meses. Isso inclui descoberta, modelagem de conteúdo, desenvolvimento, migração de conteúdo, QA, e lançamento.

Opção 2: Ir Headless com um Frontend Moderno

É aqui que as coisas ficam interessantes, e francamente, é a abordagem que recomendo mais frequentemente para times enterprise em 2025. Mantenha Drupal como seu backend de conteúdo (atualizado para Drupal 10/11), mas construa o frontend com um framework JavaScript moderno.

Drupal 10/11 tem suporte excelente de JSON:API integrado no núcleo. Você pode expor seu conteúdo como dados estruturados e consumi-los com Next.js, Astro, ou qualquer framework frontend.

Por que essa abordagem funciona bem

  • Seu time editorial mantém a interface admin do Drupal. Eles conhecem. Eles são produtivos nela. Arrancar isso causa dor organizacional.
  • Seu frontend fica dramaticamente mais rápido. Geração estática, cache em edge, otimização moderna de imagens — coisas que são dolorosas para parafusar na camada de renderização do Drupal.
  • Você pode migrar incrementalmente. Coloque o novo frontend junto ao site antigo e migre seções uma de cada vez.

Construímos vários frontends Drupal headless com Next.js e Astro, e as melhorias de performance são substanciais. Um cliente viu seu Largest Contentful Paint cair de 4.2s para 0.8s depois de mudar para um frontend Next.js com ISR (Incremental Static Regeneration).

// Página Next.js buscando da JSON:API do Drupal
export async function getStaticProps({ params }) {
  const res = await fetch(
    `${process.env.DRUPAL_BASE_URL}/jsonapi/node/article?filter[field_slug]=${params.slug}&include=field_image,field_tags`
  );
  const data = await res.json();
  
  return {
    props: {
      article: data.data[0],
      included: data.included,
    },
    revalidate: 60, // ISR: regenerar a cada 60 segundos
  };
}

O pacote next-drupal (mantido pelo Chapter Three) torna isso ainda mais fácil com suporte integrado para modo de preview, autenticação, e mapeamento de tipos de conteúdo.

O catch

Você ainda precisa migrar Drupal 7 para Drupal 10/11 no backend. Você não está evitando esse trabalho. Mas você está desacoplando-o da reconstrução do frontend, o que dá mais flexibilidade na sequência.

Opção 3: Mudar para um CMS Headless Completamente

Às vezes a coisa certa a fazer é sair do Drupal completamente. Se seu time não tem expertise forte em Drupal, se você está lutando para contratar desenvolvedores Drupal (e você está — o pool de talento Drupal encolheu significativamente desde 2020), ou se seu modelo de conteúdo cresceu além do que Drupal faz bem, um CMS headless pode ser a chamada certa.

CMS Preço (2025) Melhor Para Content API Curva de Aprendizado
Contentful $300-$2.500+/mês Times editoriais grandes GraphQL + REST Médio
Sanity $99-$949+/mês (enterprise customizado) Times liderados por desenvolvedor GROQ + GraphQL Baixo-Médio
Storyblok $109-$449+/mês Necessidades de edição visual REST + GraphQL Baixo
Strapi (self-hosted) Gratuito (self-hosted) / $29+/mês (cloud) Times querendo controle REST + GraphQL Médio
Payload CMS Gratuito (self-hosted) / $35+/mês (cloud) Times TypeScript-first REST + GraphQL Médio

Trabalhamos com vários desses através de nossa prática de desenvolvimento headless CMS. A escolha certa depende das habilidades técnicas do seu time, complexidade de conteúdo, e orçamento.

Migração de conteúdo de Drupal 7 para um CMS headless

Isso é realmente mais fácil que migrar para Drupal 10/11 em alguns aspectos. Você não está constrangido pelo framework de migração do Drupal. A abordagem típica:

  1. Exportar conteúdo Drupal 7 via Drush ou queries diretas de banco de dados
  2. Transformar os dados no modelo de conteúdo do seu CMS alvo usando scripts (Python e Node.js ambos funcionam bem)
  3. Importar via API de gerenciamento do CMS
  4. Verificar e corrigir referências, mídia, e relacionamentos
# Simples exportação de conteúdo Drupal 7 via banco de dados
import mysql.connector
import json

db = mysql.connector.connect(
    host="localhost",
    user="drupal",
    password="yourpassword",
    database="drupal7_db"
)

cursor = db.cursor(dictionary=True)
cursor.execute("""
    SELECT n.nid, n.title, n.created, n.changed, n.status,
           fdb.body_value, fdb.body_summary
    FROM node n
    LEFT JOIN field_data_body fdb ON n.nid = fdb.entity_id
    WHERE n.type = 'article' AND n.status = 1
    ORDER BY n.created DESC
""")

articles = cursor.fetchall()

with open('articles_export.json', 'w') as f:
    json.dump(articles, f, default=str, indent=2)

print(f"Exportados {len(articles)} artigos")

A parte difícil não é a exportação. É mapear o modelo de conteúdo do Drupal 7 (com seu sistema de campo, referências de entidade, termos de taxonomia, e Paragraphs) para estruturas de dados de um novo CMS. Planeje para isso levar tempo de análise significativa.

Opção 4: Fornecedores de Suporte Estendido (Comprar Tempo)

Se você genuinamente precisa de mais tempo — e às vezes você precisa, especialmente com ciclos de orçamento e prioridades organizacionais — fornecedores de suporte estendido podem manter seu site Drupal 7 patchado enquanto você planeja.

Principais fornecedores oferecendo suporte estendido Drupal 7

  • Tag1 Consulting — Um dos mais estabelecidos. Eles fazem backport de patches de segurança e fornecem manutenção contínua. Preço varia pela complexidade do site mas espere $30K-$80K/ano.
  • Acquia — Oferece suporte estendido Drupal 7 através de sua plataforma, atualmente até 2026 para clientes enterprise.
  • mySociety / D7 LTS Contributors — Suporte estendido comunitário através do programa Extended Support do Drupal 7.

Isso é uma estratégia de ponte legítima, não uma solução de longo prazo. Eu limitaria a 12-18 meses no máximo. Cada mês que você fica em Drupal 7 aumenta a complexidade da sua migração conforme o gap entre D7 e plataformas modernas se amplia.

Planejamento de Migração: Um Framework Passo a Passo

Aqui está o framework que uso com cada migração enterprise. Não é glamouroso, mas funciona.

Fase 1: Auditoria (2-4 semanas)

  • Auditoria de conteúdo: Quantos tipos de conteúdo? Quantos nós por tipo? Qual é a complexidade do modelo de conteúdo? Você está usando Paragraphs, Field Collections, Entity Reference?
  • Auditoria de módulos: Liste cada módulo contrib e customizado. Categorize como: tem equivalente D10, precisa de substituição customizada, pode ser eliminado. Uso drush pm:list --status=enabled e faz referência cruzada com drupal.org.
  • Auditoria de integração: Com quais sistemas externos o Drupal fala? Gateways de pagamento, CRMs, automação de marketing, provedores de SSO?
  • Baseline de tráfego e performance: Documente métricas de performance atual. Você precisará dessas para comparação.
  • Auditoria de papéis de usuário: Quantos workflows editoriais existem? Que permissões importam?

Fase 2: Decisão de Arquitetura (2-3 semanas)

Com base em sua auditoria, decida qual das quatro opções é certa. Esta é uma decisão arquitetônica genuína que deve envolver liderança de engenharia, stakeholders de conteúdo, e quem quer que controle o orçamento.

Fase 3: Prova de Conceito (3-6 semanas)

Antes de se comprometer com uma migração completa, construa uma prova de conceito que cubra:

  • 2-3 tipos de conteúdo migrados para a nova plataforma
  • O workflow editorial mais complexo reproduzido
  • Uma integração crítica conectada
  • Benchmarks de performance na nova stack

É aqui que você descobrirá as coisas que ninguém mencionou durante a auditoria. Sempre há algo.

Fase 4: Migração Completa (3-12 meses)

Este é o trabalho real. Priorize sem clemência. Nem tudo do Drupal 7 precisa vir junto. Na minha experiência, 20-30% de conteúdo e funcionalidade em um site Drupal 7 enterprise típico pode ser eliminado durante migração.

Fase 5: QA e Lançamento (2-4 semanas)

Redirecionamentos são críticos. Cada URL no seu site Drupal 7 que tem equity de busca precisa de um redirecionamento 301 para o novo site. Use exportações do módulo path_redirect e globalredirect como ponto de partida, então rastreie o site antigo com Screaming Frog para construir um mapa de redirecionamento completo.

Estratégia de Migração de Conteúdo

Migração de conteúdo merece sua própria seção porque é onde a maioria das migrações sai dos trilhos.

O problema do campo body

Campos body do Drupal 7 são tipicamente uma confusão de HTML. Você encontrará estilos inline, caminhos de imagem hardcoded, iframes embutidos, e ocasionalmente PHP bruto (se alguém habilitou o módulo PHP filter — um horror genuíno de segurança). Antes de migrar, você precisa decidir: limpar, ou portar a confusão?

Minha recomendação: limpar. Escreva scripts de transformação que:

  • Retirem estilos inline
  • Convertam tags <img> para referências de mídia apropriadas
  • Corrijam links internos para usar a nova estrutura de URL
  • Convertam qualquer token de embed WYSIWYG para o novo formato

Migração de mídia

Sites Drupal 7 lidam com mídia de formas extremamente diferentes. Alguns usam o módulo Media (1.x ou 2.x), alguns usam campos de arquivo simples, alguns usam tokens de mídia embutidos em campos body. Mapeie todo padrão de tratamento de mídia antes de começar a escrever código de migração.

Se você está migrando para um CMS headless, você também precisará decidir onde arquivos de mídia vivem. A maioria dos CMSs headless tem gerenciamento de ativos integrado, ou você pode usar um DAM como Cloudinary ou imgix.

Conteúdo multilíngue

Se seu site Drupal 7 usa i18n, entity_translation, ou content_translation, a complexidade da migração aproximadamente dobra. O sistema multilíngue do Drupal 7 era... vamos dizer "criativo." As estruturas de dados são inconsistentes e requerem mapeamento cuidadoso.

Estimativas de Custo e Timeline

Vou dar números reais baseados em projetos que estive envolvido ou tenho conhecimento direto.

Complexidade do Site Migração Drupal 10/11 Migração CMS Headless Frontend Headless + Backend Drupal
Pequeno (5-10 tipos de conteúdo, <1K páginas, 2-3 módulos customizados) $80K-$150K, 3-6 meses $60K-$120K, 2-4 meses $100K-$180K, 3-6 meses
Médio (10-20 tipos de conteúdo, 1K-10K páginas, 5-10 módulos customizados) $200K-$500K, 6-12 meses $150K-$350K, 4-8 meses $200K-$450K, 5-10 meses
Grande (20+ tipos de conteúdo, 10K+ páginas, 10+ módulos customizados, multilíngue) $500K-$1.5M+, 12-24 meses $300K-$800K, 6-14 meses $400K-$1M+, 8-18 meses

Estes são custos totalmente carregados incluindo descoberta, desenvolvimento, migração, QA, e gerenciamento de projeto. Sua milhagem variará com base na composição do time (in-house vs. agência), localização geográfica, e quanto cleanup você faz versus portar como está.

Quer obter uma estimativa mais específica para sua situação? Fazemos avaliações de migração que dão a você um quadro claro de escopo e custo.

Erros Comuns que Vi Times Cometendo

Tentar fazer uma recriação 1:1. Seu site Drupal 7 acumulou 10+ anos de sujeira. Não migre tudo. Use a migração como uma oportunidade para simplificar.

Subestimar o esforço de redirecionamento. Trabalhei em uma migração onde o time esqueceu de redirecionamentos até duas semanas antes do lançamento. Eles tinham 45.000 URLs para mapear. Não seja esse time.

Não envolver stakeholders editoriais cedo o suficiente. As pessoas que usam o CMS diariamente terão opiniões fortes sobre o novo sistema. Envolva-as na Fase 1, não na Fase 4.

Escolher uma plataforma baseada em features, não em capacidade do time. O melhor CMS é aquele que seu time realmente consegue manter. Se você não tem expertise em Drupal, migrar para Drupal 10/11 sem contratar para isso é se preparar para uma repetição dessa situação em 5 anos.

Rodar sistemas paralelos por muito tempo. Coloque uma data de cutover firme. Rodar antigo e novo em paralelo é caro e confuso.

Pular o congelamento de conteúdo. Durante o push final de migração, você precisa de um congelamento de conteúdo no site antigo. Planeje para isso. Comunique. Autores de conteúdo odeiam, mas é necessário para garantir que nada seja perdido.

FAQ

O que acontece se eu continuar rodando Drupal 7 após o fim de vida?

Seu site não deixará de funcionar subitamente. Mas você não receberá patches de segurança, o que significa que qualquer vulnerabilidade recém-descoberta permanecerá sem patch indefinidamente. Este é um risco real — sites Drupal são frequentemente alvo de ataques automatizados. Você também enfrentará crescentes problemas de compatibilidade conforme versões de PHP avançam e provedores de hospedagem descontinuam suporte para versões antigas de PHP. Para qualquer organização com requisitos de conformidade (PCI, HIPAA, SOC 2, GDPR), rodar software sem suporte é uma violação direta.

Posso fazer upgrade direto de Drupal 7 para Drupal 11?

Sim, a Migrate API suporta migração direta de Drupal 7 para Drupal 10 ou 11. Você não precisa passar por Drupal 8 e 9. Porém, isso não é um "upgrade" no sentido tradicional — é uma reconstrução de seu site na nova plataforma com conteúdo migrado. Seus temas, módulos customizados, e configurações não carregam diretamente.

Quanto tempo leva uma migração típica de Drupal 7?

Para um site enterprise de tamanho médio, planeje 6-12 meses do kickoff ao lançamento. Sites menores com funcionalidade customizada limitada podem ser feitos em 3-4 meses. Sites grandes e complexos com conteúdo multilíngue, integrações extensivas, e heavy customization podem levar 12-24 meses. A fase de auditoria dará uma estimativa muito mais precisa para sua situação específica.

Vale a pena migrar para Drupal 10/11, ou devo trocar plataforma de CMS?

Depende do seu time e de suas necessidades. Se você tem expertise em Drupal in-house, seu modelo de conteúdo é bem adequado para o sistema de entidades do Drupal, e você precisa das forças do Drupal (permissões complexas, multilíngue, multi-site), então ficar no ecossistema faz sentido. Se você está lutando para contratar desenvolvedores Drupal, seu site é primariamente um site de marketing sem workflows editoriais complexos, ou você quer migrar para uma arquitetura headless, um CMS diferente pode ser o investimento melhor.

Qual é a opção mais barata para migrar para fora do Drupal 7?

Suporte estendido de um fornecedor como Tag1 ($30K-$80K/ano) é a opção mais barata de curto prazo, mas não resolve o problema subjacente. Para migração real, mudar para um CMS headless como Sanity ou Storyblok com um frontend estático tende a ser o caminho mais cost-effective para sites mais simples, começando ao redor de $60K-$120K. Confira nossa página de pricing para mais detalhes sobre como estruturamos projetos de migração.

Meus rankings de SEO serão afetados pela migração?

Podem ser, mas planejamento apropriado minimiza o impacto. Os fatores críticos são: manter estruturas de URL (ou implementar redirecionamentos 301 apropriados para cada URL indexada), preservar meta dados e markup de dados estruturados, garantir que o novo site carregue pelo menos tão rápido quanto o antigo (idealmente mais rápido), e submeter sitemaps atualizados ao Google Search Console. Vi migrações bem executadas resultarem em melhorias de SEO devido a melhor page speed e experiência mobile. Também vi migrações desastrosas derrubarem tráfego 50% porque alguém esqueceu os redirecionamentos.

Posso migrar conteúdo incrementalmente ou tem que ser tudo de uma vez?

Migração incremental é possível e frequentemente preferível para sites grandes. Com uma arquitetura headless, você pode colocar o novo frontend junto ao site antigo e migrar seções uma de cada vez, usando regras de reverse proxy para rotear tráfego para o backend apropriado. Isso reduz risco e deixa você validar cada seção antes de continuar. O trade-off é complexidade operacional aumentada durante o período de migração.

Devo considerar WordPress como alvo de migração?

WordPress é uma opção viável para sites mais simples, mas seria cauteloso para casos de uso enterprise. Se seu site Drupal 7 tem tipos de conteúdo complexos, permissões granulares, ou workflows editoriais sofisticados, WordPress parecerá um downgrade. O modelo de conteúdo do WordPress (posts, pages, e custom post types) é mais simples que o sistema de entidades do Drupal. Para times enterprise, eu olharia mais seriamente para Drupal 10/11 ou um CMS headless apropriado. Dito isso, WordPress com ACF Pro e um frontend headless pode funcionar bem para sites marketing-focused.