Sua instância Drupal 7 multi-site executa 23 localizações de franquias em infraestrutura compartilhada que não recebe patch de segurança desde fevereiro de 2025. Você está enfrentando uma migração D7-para-D10 que é na verdade 23 reconstruções separadas — cada módulo personalizado de localização, cada sobrescrita de tema, cada tipo de conteúdo reconstruído manualmente. Times do Drupal 9 enfrentaram exatamente essa dor de reconstrução ao migrar de D7. Agora D10-para-D11 traz outra onda de mudanças quebradas, e sua rede multiplica cada falha de compatibilidade pelo número de sites que você gerencia. Tiramos redes multi-site do Drupal e colocamos em Next.js + Supabase em menos de 90 dias. A diferença de arquitetura explica por que times estão fazendo esse movimento permanente — e por que voltar se torna impensável uma vez que você vê implementação em escala.

Quero ser claro desde o início: Drupal não é software ruim. Alimentou — e ainda alimenta — alguns dos sites mais importantes da internet. Mas Drupal multi-site em 2026 é uma proposição fundamentalmente diferente do que era em 2015. O ecossistema mudou, a economia mudou, e o pool de talento de desenvolvedores migrou para JavaScript. Se você é um time de TI ou agência gerenciando uma rede Drupal multi-site para uma universidade, sistema hospitalar, agência governamental ou negócio com múltiplas localizações, este artigo é para você.

Índice

Drupal Multi-Site Está Morto: O Que Negócios Multi-Localização Usam Agora

Por Que Drupal Multi-Site Está Morrendo

Drupal multi-site era uma ideia elegante em 2010. Uma base de código, um servidor, múltiplos sites compartilhando módulos e temas. Para universidades com 50 sites de departamentos ou sistemas hospitalares com 30 clínicas, era a escolha lógica. Você poderia gerenciar tudo a partir de um painel admin único, fazer push de atualizações uma vez, e manter consistência pela rede.

Esse modelo rachou sob o peso da própria evolução do Drupal.

O problema central não é nenhuma questão única — é o efeito composto de cinco pressões simultâneas: custos de atualização, compatibilidade de módulos, escassez de talento, expectativas de performance e economia de hospedagem. Cada um sozinho seria gerenciável. Juntos, tornam Drupal multi-site insustentável para a maioria das organizações.

O Imposto de Atualização Que Quebra Orçamentos

Drupal 7 alcançou fim de vida em janeiro de 2025. Isso não é uma depreciação suave — significa sem mais patches de segurança, sem mais suporte da comunidade, e exposição a vulnerabilidades ativas para cada site em sua rede. Se você ainda está rodando D7 multi-site, está carregando risco real.

Mas aqui está a parte que dói: atualizar de Drupal 7 para Drupal 10 ou 11 não é uma atualização. É uma reconstrução. Drupal 8 rescreveu toda a arquitetura, mudando de um modelo PHP procedural para PHP orientado a objetos baseado em Symfony. Seus temas D7? Desaparecidos. Seus módulos personalizados? Reescreva-os. Seus arquivos de template? Comece novamente com Twig.

Em um site único, isso é um projeto doloroso mas gerenciável. Em uma rede multi-site com 20 sites, são 20 reconstruções. Mesmo se sites compartilham um tema base, cada localização provavelmente tem customizações — tipos de conteúdo personalizados, configurações de Views, blocos e layouts de tipo Paragraph que precisam de atenção individual.

Os números contam a história:

  • Migração D7 para D10 para um site único: $30.000–$80.000 dependendo da complexidade
  • Migração D7 para D10 para uma rede com 20 sites: $200.000–$600.000+ (não é um simples multiplicador devido ao código compartilhado, mas longe do custo de um site único)
  • Atualização D10 para D11: Menos dramática mas ainda envolve mudanças quebradas em torno de componentes Symfony 7, requisitos PHP 8.3 e remoções de API depreciadas

E o ciclo não para. Drupal se comprometeu com lançamentos principais anuais, o que significa mudanças quebradas anuais. Cada versão aumenta a versão mínima de PHP, deprecia APIs, e requer que autores de módulos atualizem seu código. Para uma rede multi-site, isso cria uma esteira perpétua de atualização.

Tenho falado com diretores de TI que descrevem seu orçamento de atualização Drupal como "o custo de manter-se parado". Estão gastando seis dígitos apenas para manter paridade de funcionalidades — não para adicionar nada novo.

A Armadilha de Compatibilidade de Módulos

O poder do Drupal vem de seu ecossistema de módulos contribuídos. Uma instalação multi-site típica pode usar 40-80 módulos contribuídos — Views, Paragraphs, Webform, Pathauto, Metatag, Media, Layout Builder, e dezenas mais.

Aqui está o porém: em uma configuração multi-site, todos os sites compartilham a mesma base de código. Isso significa que cada módulo deve ser compatível com cada site simultaneamente. Quando um autor de módulo descontinua o suporte para Drupal 9 (que já está fim de vida desde novembro de 2023) e apenas suporta D10/D11, você não pode atualizar seletivamente módulos para um site. Você atualiza o módulo para todos os sites, ou nenhum.

Isso cria um bloqueio de dependência. Você quer atualizar o Módulo A porque tem um patch de segurança crítico, mas a nova versão do Módulo A requer Drupal 10.3+, e sua base de código está em 10.1 porque o Módulo B ainda não lançou uma versão 10.3-compatível. Multiplique isso por 60 módulos e 20 sites, e você está gastando sprints inteiros em testes de compatibilidade.

O ecossistema de módulos contribuídos também está encolhendo. De acordo com estatísticas de Drupal.org, o número de módulos ativamente mantidos tem declinado desde 2020. Muitos mantenedores de módulos migraram para outras plataformas ou simplesmente pararam de atualizar seus módulos. A comunidade Drupal é menor que era cinco anos atrás, e essa tendência está acelerando.

Drupal Multi-Site Está Morto: O Que Negócios Multi-Localização Usam Agora - arquitetura

A Escassez de Talento Drupal É Real

Este é o que proprietários de agências e diretores de TI sentem mais intensamente. Encontrar desenvolvedores Drupal em 2026 é genuinamente difícil.

Drupal requer um conjunto de habilidades específico: PHP (avançado), Symfony, templating Twig, sistema de entidade/campo do Drupal, API de plugin, gerenciamento de configuração (baseado em YAML), e o pipeline de renderização. Não é que essas sejam habilidades ruins — é que estão cada vez mais raras. Desenvolvedores saindo de bootcamps e programas de CS estão aprendendo React, Next.js, e TypeScript. Não estão aprendendo Drupal.

As taxas de mercado refletem isso:

Função Desenvolvedor Drupal Desenvolvedor Next.js
Júnior $80–$120/h $60–$90/h
Mid-level $120–$170/h $80–$130/h
Sênior $170–$220/h $120–$170/h
Pool de talento disponível Encolhendo Crescendo rapidamente
Tempo médio para contratar 6-12 semanas 2-4 semanas

Você está pagando mais por desenvolvedores que são mais difíceis de encontrar, trabalhando em um ecossistema com menos recursos da comunidade. Essa não é uma posição sustentável para nenhuma organização.

Construímos nossa prática de desenvolvimento Next.js especificamente porque é aqui que o talento e a demanda convergiram.

Performance: Renderização PHP vs. Entrega em Edge

Drupal serve páginas através de renderização PHP. Cada requisição atinge o servidor, inicializa Drupal, consulta o banco de dados, corre pelo pipeline de renderização, e retorna HTML. Mesmo com camadas de cache (Varnish, Redis, cache de página interno do Drupal), a arquitetura tem um teto de performance.

Scores típicos de Lighthouse do Drupal em instalações multi-site de produção:

  • Performance: 55–70
  • LCP (Largest Contentful Paint): 2.5–4.5 segundos
  • CLS (Cumulative Layout Shift): 0.1–0.3
  • TTFB (Time to First Byte): 800ms–2.5s (dependendo da hospedagem)

Next.js em Vercel com ISR (Incremental Static Regeneration) ou SSG (Static Site Generation):

  • Performance: 90–100
  • LCP: 0.8–1.5 segundos
  • CLS: 0–0.05
  • TTFB: 50–200ms (edge-cached)

Essa não é uma diferença marginal. É um gap de geração. Core Web Vitals do Google são um fator de ranking, e o delta de performance entre Drupal e um framework frontend moderno em infraestrutura edge é mensurável em rankings de busca.

Para negócios multi-localização, isso importa ainda mais. Cada página de localização é uma página de landing de SEO local. Se sua página de clínica Dallas carrega em 4 segundos enquanto a do seu concorrente carrega em 1.2 segundos, Google nota.

Comparação de Custos: Hospedagem Drupal vs. Stack Moderno

Drupal multi-site requer hospedagem Drupal gerenciada. Você precisa de PHP, MySQL/MariaDB, cache em nível de servidor, e idealmente uma plataforma que entenda a estrutura de arquivo e configuração multisite do Drupal. As principais opções:

  • Acquia Cloud: $800–$3.000/mês para multi-site
  • Pantheon: $300–$1.500/mês dependendo do plano e contagem de sites
  • Platform.sh: $500–$2.000/mês
  • Auto-gerenciado em AWS/GCP: $200–$800/mês para infraestrutura, mais $2.000–$5.000/mês para um sysadmin gerenciar

Nosso stack moderno recomendado para sites multi-localização:

  • Vercel Pro: $20/mês
  • Supabase Pro: $25/mês
  • Total: $45/mês

Isso é $540/ano vs. $3.600–$36.000/ano. Mesmo se você adicionar um CDN para mídia ($20/mês) e uma ferramenta de monitoramento ($30/mês), você está em $1.140/ano. As economias de hospedagem sozinhas frequentemente pagam pela migração no primeiro ano.

Por ser justo: preços Vercel e Supabase escalam com uso. Um multi-site de alto tráfego pode ver contas Vercel de $100–$300/mês e Supabase em $50–$100/mês. Mesmo no topo, você está em $4.800/ano — ainda uma fração da hospedagem Drupal gerenciada.

Frente a Frente: Drupal Multi-Site vs. Next.js + Supabase

Fator Drupal Multi-Site Next.js + Supabase
Custo de atualização (por versão principal) $200K–$600K para 20 sites $0–$5K (atualizações menores de dependência)
Custo de hospedagem anual $3.600–$36.000 $540–$4.800
Taxa horária de desenvolvedor $120–$220/h $80–$170/h
Tempo para adicionar nova localização 2–4 semanas 1–3 dias
Postura de segurança Requer patching constante, base de código compartilhada = risco compartilhado Páginas estaticamente geradas, sem servidor para explorar
Score de performance Lighthouse 55–70 90–100
Suporte a i18n Módulo i18n do Drupal (configuração complexa) next-intl + colunas de locale (direto)
Edição de conteúdo UI admin do Drupal Dashboard Supabase, admin personalizado, ou CMS headless
Deployment SSH/Git deploy para servidor único Git push → Vercel auto-deploy com URLs de preview

O Caminho da Migração: Drupal para Next.js + Supabase

Aqui está o processo real que seguimos ao migrar redes Drupal multi-site. Não é um projeto de fim de semana, mas é bem-definido e previsível.

Passo 1: Exportar Conteúdo do Drupal

A abordagem depende de sua versão Drupal.

Drupal 10/11: Use o módulo JSON:API (incluído no core) para exportar conteúdo programaticamente:

# Exportar todos os nós do tipo 'location'
curl https://seu-site-drupal.com/jsonapi/node/location?page[limit]=50 \
  -H "Authorization: Basic CREDENCIAIS_BASE64" \
  > locations.json

Drupal 7: Não há API REST construída. Você precisará consultar o banco de dados diretamente. Drupal 7 armazena conteúdo em múltiplas tabelas — node, field_data_*, field_revision_*, e tabelas de taxonomia.

-- Exportar nós de localização D7 com dados de campo
SELECT 
  n.nid,
  n.title,
  n.created,
  n.changed,
  fdb.body_value AS body,
  fda.field_address_value AS address,
  fdp.field_phone_value AS phone,
  fdl.field_latitude_value AS latitude,
  fdl.field_longitude_value AS longitude
FROM node n
LEFT JOIN field_data_body fdb ON n.nid = fdb.entity_id
LEFT JOIN field_data_field_address fda ON n.nid = fda.entity_id
LEFT JOIN field_data_field_phone fdp ON n.nid = fdp.entity_id
LEFT JOIN field_data_field_location fdl ON n.nid = fdl.entity_id
WHERE n.type = 'location'
AND n.status = 1;

Isso é bagunçado — o armazenamento de campo EAV (Entity-Attribute-Value) do Drupal 7 significa que você está fazendo join em uma tabela separada para cada campo. Mas funciona.

Passo 2: Transformar Dados Drupal para Schema Supabase

O modelo de dados do Drupal não mapeia 1:1 para um schema relacional limpo. Aqui está como lidamos com as conversões principais:

Tipos de Paragraph → Campos JSONB

Drupal Paragraphs armazena layouts de conteúdo flexível como entidades referenciadas. Em Supabase, usamos colunas JSONB:

CREATE TABLE locations (
  id UUID DEFAULT gen_random_uuid() PRIMARY KEY,
  slug TEXT UNIQUE NOT NULL,
  site_id TEXT NOT NULL, -- identifica qual localização/site
  title TEXT NOT NULL,
  body TEXT,
  address JSONB, -- {street, city, state, zip, country}
  phone TEXT,
  coordinates GEOGRAPHY(POINT, 4326),
  page_sections JSONB, -- substitui tipos de Paragraph
  meta JSONB, -- metadados SEO
  locale TEXT DEFAULT 'en',
  published BOOLEAN DEFAULT false,
  created_at TIMESTAMPTZ DEFAULT now(),
  updated_at TIMESTAMPTZ DEFAULT now()
);

O campo page_sections JSONB armazena o que Drupal Paragraphs costumava lidar:

[
  {
    "type": "hero",
    "heading": "Bem-vindo à Nossa Localização Dallas",
    "image": "/images/dallas-hero.webp",
    "cta": {"text": "Agendar Consulta", "url": "/dallas/book"}
  },
  {
    "type": "text_block",
    "body": "<p>Nossa clínica Dallas tem servido a comunidade desde 2008...</p>"
  },
  {
    "type": "staff_grid",
    "staff_ids": ["uuid-1", "uuid-2", "uuid-3"]
  }
]

Drupal Views → Queries Supabase + Server Components

Drupal Views é basicamente um construtor visual de queries. Na nova stack, esses se tornam queries Supabase chamadas de Next.js Server Components:

// app/[location]/page.tsx -- substitui uma View do Drupal
import { createClient } from '@/lib/supabase/server'

export default async function LocationPage({ 
  params 
}: { 
  params: { location: string } 
}) {
  const supabase = await createClient()
  
  const { data: location } = await supabase
    .from('locations')
    .select('*')
    .eq('slug', params.location)
    .eq('published', true)
    .single()

  if (!location) notFound()

  const { data: nearbyLocations } = await supabase
    .rpc('nearby_locations', {
      lat: location.coordinates.coordinates[1],
      lng: location.coordinates.coordinates[0],
      limit_count: 3
    })

  return (
    <main>
      <LocationHero location={location} />
      <SectionRenderer sections={location.page_sections} />
      <NearbyLocations locations={nearbyLocations} />
    </main>
  )
}

Usuários Drupal → Supabase Auth

Se seus sites Drupal têm autenticação de usuário (portais de pacientes, logins de estudantes, etc.), Supabase Auth lida com isso com suporte integrado para email/password, magic links, provedores OAuth, e Row Level Security:

-- Row Level Security: usuários podem ver apenas seus dados
ALTER TABLE patient_records ENABLE ROW LEVEL SECURITY;

CREATE POLICY "Usuários veem seus próprios registros" ON patient_records
  FOR SELECT USING (auth.uid() = user_id);

Drupal i18n → next-intl + Colunas de Locale

O sistema multilíngue do Drupal é poderoso mas complexo — tradução de conteúdo, tradução de interface, tradução de configuração, e detecção de idioma todos executam através de subsistemas separados. Com next-intl e Supabase, é mais simples:

// Consultar conteúdo localizado
const { data } = await supabase
  .from('locations')
  .select('*')
  .eq('slug', params.location)
  .eq('locale', params.locale)
  .single()

Taxonomia Drupal → Tags/Categorias em Supabase

Vocabulários de taxonomia do Drupal se tornam simples tabelas de lookup com uma tabela de junção para relacionamentos muitos-para-muitos:

CREATE TABLE categories (
  id UUID DEFAULT gen_random_uuid() PRIMARY KEY,
  vocabulary TEXT NOT NULL, -- 'service_type', 'specialty', etc.
  name TEXT NOT NULL,
  slug TEXT NOT NULL
);

CREATE TABLE location_categories (
  location_id UUID REFERENCES locations(id),
  category_id UUID REFERENCES categories(id),
  PRIMARY KEY (location_id, category_id)
);

Passo 3: Reconstruir Templates em Next.js + Tailwind

Aqui é onde o trabalho de frontend real acontece. Criamos uma biblioteca de componentes que renderiza as seções de página JSONB dinamicamente. Cada template Drupal se torna um componente React. Usamos Tailwind CSS para styling, o que significa que seus designers podem trabalhar com classes utilitárias em vez de lutar com a camada de tema do Drupal.

Passo 4: Redirecionar Cada URL com 301

Isso é crítico. URLs do Drupal seguem padrões como /node/123, /location/dallas-tx, ou qualquer coisa que Pathauto gerou. Cada URL único precisa de um redirecionamento 301 para seu equivalente em Next.js novo. Geramos esses do banco de dados Drupal:

// next.config.js
module.exports = {
  async redirects() {
    return [
      // Gerado da tabela url_alias do Drupal
      { source: '/node/1234', destination: '/locations/dallas', permanent: true },
      { source: '/locations/dallas-tx-clinic', destination: '/locations/dallas', permanent: true },
      // ... centenas mais
    ]
  }
}

Passo 5: Deploy e Descomissionar

Faça deploy em Vercel, verifique todos os redirecionamentos, confirme que métricas de SEO estão estáveis (espere 2-4 semanas de flutuação), então descomissione os servidores Drupal. Mantenha um backup de banco de dados — você nunca precisará, mas dormirá melhor.

Indústrias Deixando Drupal (E Para Onde Estão Migrando)

Universidades

Educação superior foi o ponto forte do Drupal. Universidades amavam multi-site porque cada departamento, faculdade e programa poderia ter seu próprio site sob um guarda-chuva. Mas os custos de atualização são brutais para instituições com 50-200 subsites. Estamos vendo universidades migrarem para Next.js com opções headless CMS como Sanity ou Contentful para edição de conteúdo, ou para nosso stack preferido de Next.js + Supabase para instituições que querem controle total sobre seus dados. Nosso trabalho em desenvolvimento de CMS headless cobre essas migrações exatas.

Sistemas Hospitalares

Organizações de saúde precisam de conformidade HIPAA, e Drupal em hospedagem compartilhada é uma dor de conformidade. Stacks modernos com Supabase (que oferece conformidade SOC 2 Type II e pode ser auto-hospedado para requisitos HIPAA) proporcionam melhor postura de segurança com menos overhead operacional. Cada página de clínica se torna uma página estaticamente gerada sem superfície de ataque no lado do servidor.

Agências Governamentais

Sites governamentais eram adotantes iniciais do Drupal — WhiteHouse.gov famosamente rodava em Drupal. Mas os requisitos de conformidade FedRAMP e o processo de ATO (Authority to Operate) para hospedagem Drupal com servidor é caro. Geradores de sites estáticos e arquiteturas JAMstack reduzem a superfície de conformidade dramaticamente. Várias agências migraram para Next.js com export estático ou para Astro para sites informativos ricos em conteúdo.

Organizações de Mídia

Editores precisam de velocidade — tanto em carregamento de página quanto em fluxo editorial. A experiência editorial do Drupal, embora melhorada com Layout Builder, não consegue acompanhar as experiências de edição modernas disponíveis com plataformas CMS headless. E a diferença de performance entre Drupal renderizando e páginas estáticas entregues em edge é a diferença entre leitores ficando e saindo.

Como Fica a Arquitetura Pós-Migração

O estado final para um negócio multi-localização se parece assim:

┌─────────────────────────────────────────────┐
│                  Vercel                       │
│  ┌──────────┐ ┌──────────┐ ┌──────────┐    │
│  │ /dallas  │ │ /austin  │ │ /houston │    │
│  │ (SSG)    │ │ (SSG)    │ │ (SSG)    │    │
│  └────┬─────┘ └────┬─────┘ └────┬─────┘    │
│       └─────────────┼─────────────┘          │
│                     │                        │
│            Next.js App Router                │
│            (componentes compartilhados)      │
└─────────────────────┬───────────────────────┘
                      │
              ┌───────┴───────┐
              │   Supabase    │
              │  ┌──────────┐ │
              │  │locations │ │
              │  │staff     │ │
              │  │services  │ │
              │  │reviews   │ │
              │  │media     │ │
              │  └──────────┘ │
              │  + Auth       │
              │  + Storage    │
              │  + Edge Funcs │
              └───────────────┘

Adicionando uma nova localização? Insira uma linha na tabela locations, adicione o conteúdo de seções da página, e o site reconstrói via ISR. Sem novo provisionamento de site Drupal, sem configuração de DNS, sem setup de vhost Apache. Apenas dados.

Se essa arquitetura o interessa, documentamos nossa abordagem e preços para esses tipos de migrações em nossa página de preços. Para uma conversa sobre sua rede Drupal específica, entre em contato.

FAQ

Drupal 7 ainda é seguro usar em 2026?

Não. Drupal 7 alcançou fim de vida em janeiro de 2025. Não recebe mais patches de segurança do Time de Segurança Drupal. Há vendedores de suporte estendido de terceiros, mas são caros ($500–$2.000/mês) e cobrem apenas core — não módulos contribuídos. Se ainda está em D7, deve tratar migração como urgente, não opcional.

Quanto tempo leva uma migração Drupal para Next.js?

Para um site único, espere 4–8 semanas. Para uma rede multi-site com 10–20 sites, planeje 3–6 meses com uma abordagem faseada — migre sites em lotes, começando pelas localizações de mais alto tráfego. A biblioteca de componentes compartilhados significa que cada site subsequente migra mais rápido que o anterior.

Perderei rankings de SEO ao migrar de Drupal?

Verá uma flutuação temporária — tipicamente 2–4 semanas — enquanto Google faz recrawl e reindexação de suas páginas. Redirecionamentos 301 apropriados são inegociáveis. Vimos a maioria dos sites recuperar para seus rankings pré-migração dentro de 30 dias, e muitos os superarem dentro de 60 dias devido a scores de Core Web Vitals melhorados.

E quanto à experiência de edição de conteúdo Drupal? Editores não-técnicos precisam de um CMS.

Esta é uma preocupação válida. O dashboard Supabase funciona para times técnicos, mas editores não-técnicos tipicamente precisam de uma interface amigável. As opções incluem: construir um painel admin personalizado com Next.js (2–3 semanas de trabalho adicional), usar um CMS headless como Sanity ou Contentful como a camada de edição com Supabase como armazenamento de dados, ou usar APIs auto-geradas Supabase com uma ferramenta como Retool ou Appsmith para interfaces admin rápidas.

Supabase consegue lidar com conformidade HIPAA para organizações de saúde?

Supabase Cloud é compatível com SOC 2 Type II. Para HIPAA, você precisará de um Business Associate Agreement (BAA) com Supabase — entre em contato com seu time de vendas — ou auto-hospede Supabase em sua própria infraestrutura compatível com HIPAA (AWS GovCloud, Azure Government, etc.). Auto-hospedagem de Supabase adiciona complexidade operacional mas lhe dá controle total sobre residência de dados e conformidade.

Qual é a diferença real de custo entre Drupal multi-site e Next.js + Supabase?

Para uma rede com 20 sites em Acquia ou Pantheon, tipicamente está gastando $12.000–$36.000/ano apenas em hospedagem. Next.js em Vercel + Supabase para a mesma rede custa $540–$4.800/ano. Fator no ciclo de atualização Drupal ($200K–$600K a cada 2–3 anos) versus custos de atualização próximos a zero com Next.js, e a diferença de TCO de cinco anos é frequentemente $500K+.

Posso migrar incrementalmente, ou tem que ser tudo de uma vez?

Migração incremental funciona bem. Use rewrites do Vercel para fazer proxy de rotas específicas para seu site Drupal antigo enquanto serve páginas migradas de Next.js. Migre uma localização por vez. Essa abordagem é mais baixo risco e deixa você validar a nova stack antes de se comprometer totalmente. Fizemos isso com redes de 30+ sites onde uma migração big-bang não era viável.

O que acontece com a funcionalidade de meu módulo Drupal contribuído?

Cada módulo mapeia para algo na nova stack. Webform se torna React Hook Form + inserts Supabase. Pathauto se torna rotas dinâmicas Next.js. Metatag se torna API de Metadata Next.js. Views se torna queries Supabase. Search API se torna busca full-text Supabase ou um serviço como Meilisearch. A funcionalidade não desaparece — apenas se move para uma implementação mais sustentável. Escrevemos mapas de migração para os 50 módulos Drupal mais comuns como parte de nossa prática de migração de CMS headless.