Como sair do Drupal multisite: escolher um caminho depois do Drupal 7 e migrar os sites em ordem

Um guia prático para equipes que mantêm muitos sites no Drupal multisite: as três opções reais após o fim do Drupal 7, como auditar tipos de conteúdo, views e módulos por site, uma planilha de pontuação para saber quais sites justificam o Drupal e um plano de migração que preserva URLs e registros.

O Drupal multisite costuma viver em universidades, órgãos públicos e grandes associações, onde foi montado por uma equipe competente para servir dezenas de sites de departamentos a partir de um único código-base. Desde então a equipe mudou, os sites se multiplicaram, e muitas redes ainda estão no Drupal 7, cujo suporte de segurança da comunidade terminou em 5 de janeiro de 2025. Seja qual for o motivo que trouxe você aqui, a pergunta é a mesma: quais desses sites realmente precisam do Drupal, e qual é a forma menos arriscada de migrar o resto? Este guia percorre essa decisão e depois a migração em si.

Como o Drupal multisite é montado

A documentação do Drupal descreve o multisite como a execução de sites separados e independentes a partir de um único código-base, cada um com seu próprio banco de dados, configuração, arquivos e domínio. No disco, cada site tem a sua própria pasta dentro do diretório sites, guardando pelo menos os arquivos e às vezes os próprios módulos e temas. Duas consequências moldam qualquer migração:

Código compartilhado, dados separados. Uma atualização do core ou de um módulo chega a todos os sites ao mesmo tempo, o que era o atrativo original e é o principal risco. Um módulo do qual um site depende não pode ser removido sem verificar todos os outros.
Cada site é uma migração própria. Como cada site tem seu banco de dados e sua configuração, não existe uma "exportação da rede" única. Você planeja, migra e testa site por site.

Suas três opções, comparadas com honestidade

Opção	O que envolve	Melhor para	Principal custo
Ir para o Drupal atual	Criar sites novos no Drupal atual e trazer o conteúdo com a Migrate API do Drupal. A partir do Drupal 7, isso é uma reconstrução com migração, não uma atualização no lugar.	Sites com modelos de conteúdo complexos, uso intenso de Views, módulos customizados, integrações ou uma equipe que conhece bem o Drupal	Tempo de desenvolvimento por site e manutenção contínua do Drupal
Suporte estendido pago para o Drupal 7	Continuar no Drupal 7 com correções de segurança de um fornecedor do Extended Security Support Provider Program da Drupal Association (atualmente HeroDevs e Tag1 Consulting)	Ganhar tempo enquanto a migração é planejada e financiada	Uma taxa recorrente, e a migração continua pela frente
Ir para outra plataforma	Reconstruir os sites em outro CMS ou criador de sites	Sites institucionais, informativos, de eventos e de departamentos com conteúdo simples	Reconstruir cada site; perder recursos específicos do Drupal que vocês de fato usavam

A maioria das redes grandes acaba com uma combinação: alguns sites complexos ficam no Drupal, a cauda longa vai para algo mais simples e alguns são desativados. O trabalho é decidir qual site vai para onde.

Audite o modelo de conteúdo de cada site

Sites em Drupal diferem entre si muito mais do que sites em WordPress costumam diferir, porque tipos de conteúdo, campos e views são criados por site. Antes de pontuar qualquer coisa, registre o que cada site realmente usa. Um desenvolvedor Drupal consegue tirar a maior parte disso das telas de administração ou com o Drush; o objetivo é reunir tudo em uma planilha.

Item	O que registrar	Por que importa
Tipos de conteúdo	Cada tipo, número de itens, último item criado	Muitos tipos com poucos itens sugerem excesso de construção; um tipo com 5,000 itens precisa de uma migração por script
Campos	Campos de referência, field collections ou paragraphs, campos de arquivo	Relações estruturadas são o mais difícil de levar para uma plataforma mais simples
Taxonomias	Vocabulários e como eles orientam a navegação ou os filtros	Listagens filtradas precisam de um equivalente na nova plataforma
Views	Cada view, onde aparece, se é exposta aos usuários com filtros	Filtros expostos (um diretório de funcionários, um buscador de cursos) muitas vezes são a razão de o site existir
Formulários	Webforms, os envios deles, necessidades de retenção	Os envios podem ser registros que você é obrigado a guardar
Usuários e papéis	Editores, membros, qualquer conta pública	Em geral, senhas não podem ser levadas para outra plataforma
Módulos customizados e contribuídos	O que cada um faz para este site	Cada um é um recurso a reconstruir ou uma dependência a abandonar
Integrações	Login único, sistemas de alunos ou membros, pagamento, busca	Normalmente são elas que decidem se um site pode sair do Drupal
Tráfego e links	Visitas em 12 meses, principais páginas de entrada, páginas com links externos	Define o trabalho de redirecionamento

Pontue quais sites justificam o Drupal

Dê a cada site um ponto para cada "sim" abaixo. O ponto de corte é você quem define, mas na prática sites com três pontos ou mais costumam pertencer ao Drupal atual ou a outro CMS completo, e sites com zero ou um ponto são bons candidatos a um criador de sites mais simples.

Tem conteúdo estruturado consultado por outras páginas (um diretório, um catálogo, um buscador de cursos ou de funcionários).
Tem filtros ou busca para o usuário além da busca básica do site.
Depende de um módulo customizado que faz trabalho de verdade.
Integra com um sistema interno de registro.
Tem usuários logados além dos editores.
Tem uma equipe editorial que precisa de vários papéis e revisão em etapas.
Tem mais do que algumas centenas de páginas mantidas ativamente.

Pontue os sites com os responsáveis na sala. Eles muitas vezes sabem que a view elaborada da página inicial não é olhada há anos, e com a mesma frequência sabem de uma dependência de que ninguém mais se lembra.

Migrando os sites que saem

Conteúdo

Para sites simples, o caminho mais rápido costuma ser uma cópia estruturada: rastreie o site no ar para obter todas as páginas e suas URLs e depois reconstrua página por página, reescrevendo no caminho. Para sites com centenas de itens do mesmo tipo (notícias, eventos), exporte-os como CSV ou JSON, com a ajuda de um desenvolvedor ou pelo Views data export, e importe-os onde a nova plataforma permitir, ou decida que só os dois últimos anos migram e o resto vai para o arquivo.

Arquivos

Copie a pasta de arquivos de cada site. Verifique se há arquivos privados (o Drupal pode servir arquivos fora da pasta pública), que muitas vezes guardam documentos que devem continuar restritos; eles exigem uma decisão deliberada, não um envio em massa para um site público.

Registros

Órgãos públicos e universidades costumam ter obrigações de retenção de registros para conteúdo web e envios de formulários. Antes de desligar qualquer coisa, exporte o que precisa guardar, armazene no seu sistema de registros e anote para onde foi. Uma cópia estática de arquivo do site antigo, guardada offline, é um seguro barato.

Endereços

Monte um mapa de redirecionamentos por site: caminho antigo, endereço novo, redirecionamento permanente. Sites em Drupal muitas vezes têm um caminho de sistema (node/123) e um alias; inclua os dois nas páginas que recebem tráfego. Se os sites mudarem de domínio, mantenha os domínios antigos e os redirecionamentos funcionando por muitos meses.

Uma ordem de migração que limita os danos

Fase	Sites	Objetivo
1. Desativar	Sem responsável, sem tráfego	Arquivar, redirecionar, remover. Reduz a rede e a superfície de ataque imediatamente.
2. Piloto	Dois ou três sites simples com responsáveis engajados	Provar o processo, os templates e o método de redirecionamento.
3. Cauda longa	Os demais sites com pontuação baixa, em ondas por responsável	Migrar o grosso enquanto o processo está fresco.
4. Complexos	Sites com pontuação alta	Migrar para o Drupal atual ou outro CMS completo, com tempo de desenvolvimento adequado.
5. Desligar	A instalação antiga	Só quando nada depender dela, incluindo os redirecionamentos.

Desativar primeiro parece invertido, mas funciona: cada site removido da rede antiga é um site a menos exposto enquanto você trabalha no resto.

Governança para a nova estrutura

A rede antiga provavelmente tinha um único guardião técnico. A nova estrutura não deve recriar esse gargalo, mas também não deve entregar a cada departamento um botão de publicar sem revisão. Antes de o primeiro site migrar, decida quem é responsável por cada site, quem pode publicar, quais sites precisam de aprovação antes de ir ao ar e quem pode adicionar recursos como formulários ou loja. Nosso modelo de política de governança de sites e o guia de fluxo de aprovação de conteúdo tratam disso.

Onde a We.Inc se encaixa, e onde não

A We.Inc é um criador de sites white-label para organizações que administram muitos sites sob uma única marca. Ela serve para os sites com pontuação baixa na sua planilha, não para os de pontuação alta. Não tem importador de Drupal, nem equivalente às Views com filtros expostos, nem tipos de conteúdo customizados; os sites são reconstruídos com IA a partir de templates ou de uma descrição e depois conferidos pela sua equipe. O que ela oferece para a cauda longa:

Uma marca (logo, cores, fontes) aplicada a todos os sites, com cada departamento como cliente dessa marca.
Padrões da marca para o que os sites podem fazer, ajustáveis por site, incluindo aprovação em uma etapa antes de um site ir ao ar.
Domínio próprio por site e regras de redirecionamento nas configurações de SEO de cada site.
Download do código como ZIP ou exportação para o GitHub, para que o conteúdo que você migra nunca fique preso.

A marca é definida uma vez e aplicada a todos os sites de departamentos, em vez de ser imposta por um tema compartilhado.

Chaves padrão da marca com o título O que seus clientes podem fazer, acima de uma lista da equipe — Os padrões definem o que cada site novo pode fazer, substituindo a ativação módulo por módulo.

Lista Aguardando sua aprovação com um site e botões para aprovar e publicar ou pedir alterações — Aprovação em uma etapa antes de um site ir ao ar, para departamentos que precisam de uma verificação. A solicitação pendente nesta marca de demonstração foi montada para a captura de tela.

Janela Export Project com as abas GitHub, ZIP, Vercel e Domain e uma opção de repositório privado — Cada site pode ser exportado para um repositório no GitHub ou baixado como ZIP.

A acessibilidade não é automática: páginas criadas com IA ainda precisam ser testadas pela sua equipe antes do lançamento, especialmente em órgãos públicos sujeitos ao ADA Title II (veja nosso guia sobre o prazo do Title II). Se a sua planilha de auditoria mostra uma cauda longa de sites simples, agende uma demonstração e traga a planilha. Para a comparação mais ampla, leia criador white-label versus CMS corporativo; se parte do seu parque está em WordPress, veja como sair do WordPress multisite.

Fontes

Última verificação em 2026-10-25.

Drupal.org, Drupal 7 End of Life (fim do suporte de segurança, Extended Security Support Provider Program).
Drupal.org, Multisite Drupal.
Drupal.org, Multisite folder structure in Drupal.
Drupal.org, Upgrading Drupal (Migrate API).

Perguntas frequentes

Quando o Drupal 7 chegou ao fim da vida útil?

O Drupal.org informa que o suporte de segurança do Drupal 7 terminou em 5 de janeiro de 2025. Há suporte de segurança estendido pago com fornecedores do Extended Security Support Provider Program da Drupal Association.

Dá para atualizar o Drupal 7 multisite no lugar?

Não no sentido comum. Passar do Drupal 7 para uma versão atual significa criar sites novos e migrar o conteúdo, normalmente com a Migrate API do Drupal, site por site, porque cada site tem seu próprio banco de dados.

Quais sites em Drupal devem continuar no Drupal?

Sites com conteúdo estruturado consultado por outras páginas, filtros para o usuário, módulos customizados que fazem trabalho de verdade, integrações com sistemas internos, usuários logados, equipes editoriais com vários papéis ou um grande número de páginas mantidas ativamente. Sites informativos simples são bons candidatos a migrar para uma plataforma mais simples.

Em que ordem os sites devem ser migrados?

Primeiro desative os sites sem responsável ou tráfego, depois faça um piloto com dois ou três sites simples, migre a cauda longa em ondas, migre os sites complexos com tempo de desenvolvimento adequado e só desligue a instalação antiga quando nada depender dela.

A We.Inc importa sites em Drupal?

Não. Não há importador de Drupal, e a We.Inc não tem tipos de conteúdo customizados nem listagens filtradas no estilo das Views. Ela serve para sites simples de departamentos e informativos, reconstruídos a partir de templates e revisados pela sua equipe.