Um Drupal 6 em produção não é apenas “um site antigo”. Depois de quinze anos, ele costuma ser também manual de operações, catálogo de exceções, ponto de integração e memória do negócio. Há código que merece aposentadoria, sem dúvida; mas há conhecimento valioso escondido justamente nas partes que parecem mais estranhas.
Por isso, modernizar não começa com um tema novo nem com uma lista de módulos equivalentes. Começa separando três coisas que o legado misturou: o que o negócio ainda precisa, o que existe por limitação técnica e o que ninguém mais sabe por que existe. Pular essa etapa é a maneira mais rápida de reconstruir os mesmos problemas com PHP mais novo.
Primeiro, entender o sistema real
O inventário precisa ir além de tipos de conteúdo e tabelas. Nós levantamos usuários e papéis, permissões efetivas, rotinas editoriais, cron, integrações, relatórios, arquivos privados, redirects e tarefas executadas “por fora” do sistema. Depois confrontamos essa fotografia técnica com quem usa a plataforma diariamente.
É nessa conversa que aparecem fatos decisivos: um campo aparentemente duplicado alimenta o financeiro; uma taxonomia controla uma campanha; determinado relatório só fecha porque alguém corrige o CSV à mão. Nada disso obriga a preservar uma solução ruim. Obriga apenas a substituir sua função conscientemente.
Transformar surpresas em decisões
Classificamos cada parte como preservar, redesenhar, consolidar ou remover. Em paralelo, marcamos riscos: dados difíceis de reconstruir, integrações sem contrato, permissões sensíveis, picos de tráfego e jornadas que não podem parar. O resultado não é um inventário ornamental, mas uma ordem de trabalho.
Também definimos critérios de aceite antes de migrar. Quantos registros devem chegar? Quais relações precisam continuar intactas? Que URLs não podem mudar? Quem valida o conteúdo? Sem respostas objetivas, “a migração terminou” vira uma opinião.
Migrações repetíveis, não scripts heroicos
No Drupal moderno, a transformação deve ficar versionada e poder ser executada várias vezes:
id: legacy_article
source:
plugin: d7_node
node_type: article
process:
title: title
body/value: body
body/format:
plugin: default_value
default_value: basic_html
destination:
plugin: entity:node
default_bundle: articleO exemplo é pequeno; projetos reais incluem lookup de entidades, arquivos, traduções, redirects e regras específicas. O princípio permanece: importar, medir, corrigir o mapeamento e importar outra vez. Alterar dados manualmente no destino cria um sucesso impossível de reproduzir.
Coexistência reduz o tamanho do risco
Nem sempre é necessário desligar o legado para começar a entregar valor. Uma nova camada pode entrar em operação por seção, público ou funcionalidade, desde que a origem dos dados e as responsabilidades estejam claras. APIs ajudam quando há fronteiras reais; desacoplar tudo por reflexo apenas multiplica deploys, caches e pontos de falha.
A arquitetura correta é a que a equipe consegue operar. Às vezes será Drupal renderizando páginas e componentes interativos pontuais. Em outros casos, Drupal ficará responsável por conteúdo e governança enquanto aplicações distintas consomem APIs. O desenho nasce do fluxo, não da moda.
A virada é o último ensaio
Antes do corte, executamos a migração com volume próximo do real, medimos duração, validamos amostras e jornadas críticas, ensaiamos redirects e documentamos rollback. Congelamento editorial, delta de conteúdo e comunicação precisam de responsáveis e horários definidos. “Se algo der errado, restauramos o backup” não é plano até alguém ter testado a restauração.
Preservar valor, não velhice
Há situações em que reconstruir é a escolha honesta: o negócio mudou, os dados perderam valor ou manter compatibilidade custa mais do que entrega. Mesmo aí, a descoberta continua indispensável. O objetivo não é conservar o passado inteiro; é evitar que conhecimento útil seja descartado junto com a tecnologia vencida.
Na Mindcore, tratamos modernização como evolução controlada: entender, escolher, migrar, verificar e só então desligar. É menos cinematográfico do que um “big bang”. Também é muito mais provável que funcione na segunda-feira de manhã.
