Tu instancia multi-site de Drupal 7 ejecuta 23 ubicaciones de franquicia en una infraestructura compartida que no ha recibido un parche de seguridad desde febrero de 2025. Estás mirando una migración de D7 a D10 que en realidad son 23 reconstrucciones separadas: módulos personalizados de cada ubicación, cada anulación de tema, cada tipo de contenido reconstruido manualmente. Los equipos de Drupal 9 enfrentaron exactamente este dolor de reconstrucción al pasar de D7. Ahora D10 a D11 trae otra ola de cambios disruptivos, y tu red multiplica cada fallo de compatibilidad por el número de sitios que administras. Hemos sacado redes multi-site de Drupal y las hemos puesto en Next.js + Supabase en menos de 90 días. La diferencia de arquitectura explica por qué los equipos están haciendo este movimiento permanente, y por qué volver se vuelve impensable una vez que ves el despliegue a escala.

Quiero ser claro desde el principio: Drupal no es software malo. Impulsó —y aún impulsa— algunos de los sitios web más importantes de internet. Pero el multi-site de Drupal en 2026 es una propuesta fundamentalmente diferente a la que era en 2015. El ecosistema ha cambiado, la economía ha cambiado, y el conjunto de talentos de desarrolladores ha migrado a JavaScript. Si eres un equipo de TI o agencia que administra una red multi-site de Drupal para una universidad, sistema hospitalario, agencia gubernamental o negocio multi-ubicación, este artículo es para ti.

Tabla de Contenidos

Drupal Multi-Site Está Muerto: Qué Usan Los Negocios Multi-Ubicación

Por Qué Drupal Multi-Site Se Está Muriendo

Drupal multi-site fue una idea elegante en 2010. Una base de código, un servidor, múltiples sitios compartiendo módulos y temas. Para universidades con 50 sitios de departamentos o sistemas hospitalarios con 30 ubicaciones de clínicas, era la opción lógica. Podías administrar todo desde un panel de administración único, implementar actualizaciones una vez y mantener consistencia en toda la red.

Ese modelo se ha roto bajo el peso de la propia evolución de Drupal.

El problema central no es un solo problema, es el efecto compuesto de cinco presiones simultáneas: costos de actualización, compatibilidad de módulos, escasez de talentos, expectativas de desempeño y economía de hosting. Cada uno por sí solo sería manejable. Juntos, hacen que el multi-site de Drupal sea insostenible para la mayoría de las organizaciones.

El Impuesto de Actualización Que Quiebra Presupuestos

Drupal 7 llegó al fin de vida en enero de 2025. Eso no es una depreciación suave, significa que no hay más parches de seguridad, no hay más soporte de la comunidad y exposición a vulnerabilidades activas para cada sitio en tu red. Si aún estás ejecutando multi-site D7, estás llevando un riesgo real.

Pero aquí está la parte que quema: actualizar de Drupal 7 a Drupal 10 u 11 no es una actualización. Es una reconstrucción. Drupal 8 rescribió toda la arquitectura, moviéndose de un modelo PHP procedural a PHP orientado a objetos basado en Symfony. ¿Tus temas D7? Desaparecidos. ¿Tus módulos personalizados? Rescríbelos. ¿Tus archivos de plantilla? Comienza de nuevo con Twig.

En un sitio único, eso es un proyecto doloroso pero manejable. En una red multi-site de 20 sitios, son 20 reconstrucciones. Incluso si los sitios comparten un tema base, cada ubicación probablemente tiene personalizaciones: tipos de contenido personalizados, configuraciones de Vistas, bloques y diseños de tipo Párrafo que necesitan atención individual.

Los números cuentan la historia:

  • Migración de D7 a D10 para un sitio único: $30,000–$80,000 dependiendo de la complejidad
  • Migración de D7 a D10 para una red de 20 sitios: $200,000–$600,000+ (no es un multiplicador simple debido al código compartido, pero lejos de un costo de sitio único)
  • Actualización de D10 a D11: Menos dramática pero aún implica cambios disruptivos alrededor de componentes de Symfony 7, requisitos de PHP 8.3 y eliminaciones de API deprecadas

Y el ciclo no se detiene. Drupal se ha comprometido a lanzamientos principales anuales, lo que significa cambios disruptivos anuales. Cada versión aumenta la versión mínima de PHP, depreca APIs y requiere que los autores de módulos actualicen su código. Para una red multi-site, esto crea una cinta sin fin de actualizaciones.

He hablado con directores de TI que describen su presupuesto de actualización de Drupal como "el costo de permanecer estático". Están gastando seis cifras solo para mantener la paridad de características, no para agregar nada nuevo.

La Trampa de Compatibilidad de Módulos

El poder de Drupal proviene de su ecosistema de módulos contribuidos. Una instalación multi-site típica podría usar 40-80 módulos contribuidos: Vistas, Párrafos, Webform, Pathauto, Metatag, Media, Layout Builder y muchos más.

Aquí está el problema: en una configuración multi-site, todos los sitios comparten la misma base de código. Eso significa que cada módulo debe ser compatible con cada sitio simultáneamente. Cuando un autor de módulos deja de soportar Drupal 9 (que ya está al fin de vida desde noviembre de 2023) y solo soporta D10/D11, no puedes actualizar módulos selectivamente para un sitio. Actualizas el módulo para todos los sitios o ninguno.

Esto crea un bloqueo de dependencia. Quieres actualizar el Módulo A porque tiene un parche de seguridad crítico, pero la nueva versión del Módulo A requiere Drupal 10.3+, y tu base de código está en 10.1 porque el Módulo B aún no ha lanzado una versión compatible con 10.3. Multiplica esto por 60 módulos y 20 sitios, y estás gastando sprints completos en pruebas de compatibilidad.

El ecosistema de módulos contribuidos también se está encogiendo. Según las estadísticas de Drupal.org, el número de módulos mantenidos activamente ha estado disminuyendo desde 2020. Muchos mantenedores de módulos se han mudado a otras plataformas o simplemente han dejado de actualizar sus módulos. La comunidad de Drupal es más pequeña de lo que era hace cinco años, y esa tendencia se está acelerando.

Drupal Multi-Site Está Muerto: Qué Usan Los Negocios Multi-Ubicación - arquitectura

La Escasez de Talento en Drupal Es Real

Esta es la que los propietarios de agencias y directores de TI sienten más intensamente. Encontrar desarrolladores de Drupal en 2026 es genuinamente difícil.

Drupal requiere un conjunto de habilidades específico: PHP (avanzado), Symfony, plantillas Twig, sistema de entidad/campo de Drupal, la API de plugins, gestión de configuración (basada en YAML) y la tubería de renderizado. No es que estas sean habilidades malas, solo que son cada vez más raras. Los desarrolladores que salen de bootcamps y programas de CS están aprendiendo React, Next.js y TypeScript. No están aprendiendo Drupal.

Las tasas del mercado reflejan esto:

| Rol | Desarrollador Drupal | Desarrollador Next.js | |------|-----------------|-------------------|| | Junior | $80–$120/hr | $60–$90/hr | | Nivel Medio | $120–$170/hr | $80–$130/hr | | Senior | $170–$220/hr | $120–$170/hr | | Conjunto de talentos disponibles | Encogimiento | Crecimiento rápido | | Tiempo promedio de contratación | 6-12 semanas | 2-4 semanas |

Estás pagando más por desarrolladores que son más difíciles de encontrar, trabajando en un ecosistema con menos recursos de la comunidad. Esa no es una posición sostenible para ninguna organización.

Hemos construido nuestra práctica de desarrollo Next.js específicamente porque aquí es donde han convergido el talento y la demanda.

Desempeño: Renderizado PHP vs Entrega en Edge

Drupal sirve páginas a través del renderizado de PHP. Cada solicitud golpea el servidor, inicia Drupal, consulta la base de datos, se ejecuta a través de la tubería de renderizado y devuelve HTML. Incluso con capas de almacenamiento en caché (Varnish, Redis, caché de página interna de Drupal), la arquitectura tiene un techo de desempeño.

Puntuaciones típicas de Lighthouse de Drupal en instalaciones multi-site de producción:

  • Desempeño: 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 (dependiendo del hosting)

Next.js en Vercel con ISR (Regeneración Estática Incremental) o SSG (Generación de Sitio Estático):

  • Desempeño: 90–100
  • LCP: 0.8–1.5 segundos
  • CLS: 0–0.05
  • TTFB: 50–200ms (almacenado en caché en edge)

Esto no es una diferencia marginal. Es una brecha generacional. Los Core Web Vitals de Google son un factor de clasificación, y la diferencia de desempeño entre Drupal y un marco frontend moderno en infraestructura edge es medible en clasificaciones de búsqueda.

Para negocios multi-ubicación, esto importa aún más. Cada página de ubicación es una página de destino de SEO local. Si tu página de la clínica de Dallas carga en 4 segundos mientras tu competidor carga en 1.2 segundos, Google lo nota.

Comparación de Costos: Hosting Drupal vs Stack Moderno

El multi-site de Drupal requiere hosting de Drupal administrado. Necesitas PHP, MySQL/MariaDB, almacenamiento en caché a nivel de servidor e idealmente una plataforma que entienda la estructura de archivos de Drupal y la configuración de multisitio. Las opciones principales:

  • Acquia Cloud: $800–$3,000/mes para multi-site
  • Pantheon: $300–$1,500/mes dependiendo del plan y recuento de sitios
  • Platform.sh: $500–$2,000/mes
  • Autoadministrado en AWS/GCP: $200–$800/mes para infraestructura, más $2,000–$5,000/mes para un sysadmin que lo administre

Nuestro stack moderno recomendado para sitios multi-ubicación:

  • Vercel Pro: $20/mes
  • Supabase Pro: $25/mes
  • Total: $45/mes

Eso es $540/año vs $3,600–$36,000/año. Incluso si agregas un CDN para medios ($20/mes) y una herramienta de monitoreo ($30/mes), estás en $1,140/año. Los ahorros en hosting solo a menudo pagan la migración dentro del primer año.

Para ser justo: el precio de Vercel y Supabase escala con el uso. Un multi-site de alto tráfico podría ver facturas de Vercel de $100–$300/mes y Supabase de $50–$100/mes. Incluso en el extremo superior, estás en $4,800/año, aún una fracción del hosting de Drupal administrado.

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

| Factor | Drupal Multi-Site | Next.js + Supabase | |--------|------------------|--------------------|| | Costo de actualización (por versión principal) | $200K–$600K para 20 sitios | $0–$5K (actualizaciones de dependencias menores) | | Costo anual de hosting | $3,600–$36,000 | $540–$4,800 | | Tarifa horaria del desarrollador | $120–$220/hr | $80–$170/hr | | Tiempo para agregar nueva ubicación | 2–4 semanas | 1–3 días | | Postura de seguridad | Requiere parches constantes, base de código compartida = riesgo compartido | Páginas generadas estáticamente, sin servidor que explotar | | Puntuación de desempeño de Lighthouse | 55–70 | 90–100 | | Soporte i18n | Módulo i18n de Drupal (configuración compleja) | next-intl + columnas locale (directo) | | Edición de contenido | UI de administrador de Drupal | Panel de Supabase, admin personalizado o CMS headless | | Implementación | SSH/Git deploy a servidor único | Git push → auto-deploy de Vercel con URLs de vista previa |

La Ruta de Migración: Drupal a Next.js + Supabase

Aquí está el proceso actual que seguimos al migrar redes multi-site de Drupal. No es un proyecto de fin de semana, pero es bien definido y predecible.

Paso 1: Exportación de Contenido desde Drupal

El enfoque depende de tu versión de Drupal.

Drupal 10/11: Usa el módulo JSON:API (incluido en el núcleo) para exportar contenido programáticamente:

# Exportar todos los nodos de tipo 'location'
curl https://your-drupal-site.com/jsonapi/node/location?page[limit]=50 \
  -H "Authorization: Basic BASE64_CREDENTIALS" \
  > locations.json

Drupal 7: No hay API REST construida. Tendrás que consultar la base de datos directamente. Drupal 7 almacena contenido en múltiples tablas: node, field_data_*, field_revision_* y tablas de taxonomía.

-- Exportar nodos de ubicación D7 con datos 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;

Esto es desordenado: el almacenamiento de campo EAV (Entity-Attribute-Value) de Drupal 7 significa que estás uniendo una tabla separada para cada campo. Pero funciona.

Paso 2: Transformar Datos de Drupal al Esquema de Supabase

El modelo de datos de Drupal no se asigna 1:1 a un esquema relacional limpio. Así es cómo manejamos las conversiones clave:

Tipos de Párrafos → Campos JSONB

Los Párrafos de Drupal almacenan diseños de contenido flexible como entidades referenciadas. En Supabase, usamos columnas JSONB:

CREATE TABLE locations (
  id UUID DEFAULT gen_random_uuid() PRIMARY KEY,
  slug TEXT UNIQUE NOT NULL,
  site_id TEXT NOT NULL, -- identifica qué ubicación/sitio
  title TEXT NOT NULL,
  body TEXT,
  address JSONB, -- {street, city, state, zip, country}
  phone TEXT,
  coordinates GEOGRAPHY(POINT, 4326),
  page_sections JSONB, -- reemplaza tipos de Párrafo
  meta JSONB, -- metadatos SEO
  locale TEXT DEFAULT 'en',
  published BOOLEAN DEFAULT false,
  created_at TIMESTAMPTZ DEFAULT now(),
  updated_at TIMESTAMPTZ DEFAULT now()
);

El campo JSONB page_sections almacena lo que los Párrafos de Drupal solían manejar:

[
  {
    "type": "hero",
    "heading": "Bienvenido a Nuestra Ubicación de Dallas",
    "image": "/images/dallas-hero.webp",
    "cta": {"text": "Reservar Cita", "url": "/dallas/book"}
  },
  {
    "type": "text_block",
    "body": "<p>Nuestra clínica de Dallas ha servido a la comunidad desde 2008...</p>"
  },
  {
    "type": "staff_grid",
    "staff_ids": ["uuid-1", "uuid-2", "uuid-3"]
  }
]

Vistas de Drupal → Consultas de Supabase + Componentes del Servidor

Las Vistas de Drupal es básicamente un generador de consultas visuales. En el nuevo stack, esas se convierten en consultas de Supabase llamadas desde Componentes de Servidor Next.js:

// app/[location]/page.tsx -- reemplaza una Vista de 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>
  )
}

Usuarios de Drupal → Supabase Auth

Si tus sitios de Drupal tienen autenticación de usuarios (portales de pacientes, accesos de estudiantes, etc.), Supabase Auth maneja esto con soporte integrado para contraseña de correo electrónico, enlaces mágicos, proveedores OAuth y Seguridad a Nivel de Fila:

-- Seguridad a Nivel de Fila: los usuarios solo ven sus propios datos
ALTER TABLE patient_records ENABLE ROW LEVEL SECURITY;

CREATE POLICY "Users see own records" ON patient_records
  FOR SELECT USING (auth.uid() = user_id);

i18n de Drupal → next-intl + Columnas Locale

El sistema multilingüe de Drupal es poderoso pero complejo: traducción de contenido, traducción de interfaz, traducción de configuración y detección de idioma todos se ejecutan a través de subsistemas separados. Con next-intl y Supabase, es más simple:

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

Taxonomía → Etiquetas/Categorías en Supabase

Los vocabularios de taxonomía de Drupal se convierten en simples tablas de búsqueda con una tabla de unión para relaciones muchos-a-muchos:

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)
);

Paso 3: Reconstruir Plantillas en Next.js + Tailwind

Aquí es donde ocurre el trabajo real del frontend. Creamos una biblioteca de componentes que renderiza dinámicamente las secciones de página JSONB. Cada plantilla de Drupal se convierte en un componente React. Usamos Tailwind CSS para el estilo, lo que significa que tus diseñadores pueden trabajar con clases de utilidad en lugar de luchar con la capa de tema de Drupal.

Paso 4: Redirigir 301 Cada URL

Esto es crítico. Las URL de Drupal siguen patrones como /node/123, /location/dallas-tx o lo que sea que Pathauto generara. Cada URL individual necesita un redireccionamiento 301 a su equivalente de Next.js. Generamos estos desde la base de datos de Drupal:

// next.config.js
module.exports = {
  async redirects() {
    return [
      // Generado desde la tabla url_alias de Drupal
      { source: '/node/1234', destination: '/locations/dallas', permanent: true },
      { source: '/locations/dallas-tx-clinic', destination: '/locations/dallas', permanent: true },
      // ... cientos más
    ]
  }
}

Paso 5: Implementar y Desmantelar

Implementar a Vercel, verificar todos los redireccionamientos, confirmar que las métricas de SEO son estables (espera 2-4 semanas de fluctuación), luego desmantelar los servidores de Drupal. Mantén una copia de seguridad de la base de datos: nunca la necesitarás, pero dormirás mejor.

Industrias Que Salen de Drupal (Y A Dónde Se Están Mudando)

Universidades

La educación superior fue el reducto de Drupal. Las universidades amaban el multi-site porque cada departamento, colegio y programa podía tener su propio sitio bajo un mismo paraguas. Pero los costos de actualización son brutales para instituciones con 50-200 subsitios. Estamos viendo que las universidades se muden a Next.js con opciones de CMS headless como Sanity o Contentful para la edición de contenido, o a nuestro stack preferido de Next.js + Supabase para instituciones que quieren control total sobre sus datos. Nuestro trabajo de desarrollo de CMS headless cubre exactamente estas migraciones.

Sistemas Hospitalarios

Las organizaciones de salud necesitan cumplimiento con HIPAA, y Drupal en hosting compartido es un dolor de cumplimiento. Los stacks modernos con Supabase (que ofrece cumplimiento con SOC 2 Type II y puede auto-alojarse para requisitos HIPAA) proporcionan una mejor postura de seguridad con menos sobrecarga operacional. Cada página de ubicación de clínica se convierte en una página generada estáticamente sin superficie de ataque del lado del servidor.

Agencias Gubernamentales

Los sitios gubernamentales fueron adoptadores tempranos de Drupal: WhiteHouse.gov famosamente se ejecutó en Drupal. Pero los requisitos de cumplimiento de FedRAMP y el proceso de ATO (Autoridad para Operar) para hosting de Drupal compatible con servidor es caro. Los generadores de sitios estáticos y las arquitecturas JAMstack reducen dramáticamente la superficie de cumplimiento. Varias agencias se han mudado a Next.js con exportación estática o a Astro para sitios informativos ricos en contenido.

Organizaciones de Medios

Los editores necesitan velocidad, tanto en carga de página como en flujo de trabajo editorial. La experiencia editorial de Drupal, aunque mejorada con Layout Builder, no puede igualar las experiencias de edición modernas disponibles con plataformas de CMS headless. Y la diferencia de desempeño entre Drupal renderizando y páginas estáticas entregadas en edge es la diferencia entre lectores que se quedan y rebotan.

Cómo Se Ve la Arquitectura Después de la Migración

El estado final para un negocio multi-ubicación se ve así:

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

¿Agregando una nueva ubicación? Inserta una fila en la tabla locations, agrega el contenido de secciones de página, y el sitio se reconstruye vía ISR. Sin aprovisionamiento de nuevo sitio Drupal, sin configuración de DNS, sin configuración de vhost de Apache. Solo datos.

Si esta arquitectura te interesa, hemos documentado nuestro enfoque y precios para este tipo de migraciones en nuestra página de precios. Para una conversación sobre tu red específica de Drupal, ponte en contacto.

Preguntas Frecuentes

¿Es Drupal 7 aún seguro de usar en 2026? No. Drupal 7 alcanzó fin de vida en enero de 2025. Ya no recibe parches de seguridad del Equipo de Seguridad de Drupal. Hay vendedores de soporte extendido de terceros, pero son costosos ($500–$2,000/mes) y solo cubren el núcleo, no módulos contribuidos. Si aún estás en D7, deberías tratar la migración como urgente, no opcional.

¿Cuánto tiempo tarda una migración de Drupal a Next.js? Para un sitio único, espera 4–8 semanas. Para una red multi-site con 10–20 sitios, planifica 3–6 meses con un enfoque por fases: migra sitios en lotes, comenzando con las ubicaciones de mayor tráfico. La biblioteca de componentes compartidos significa que cada sitio subsecuente migra más rápido que el anterior.

¿Perderé clasificaciones de SEO al migrar de Drupal? Verás una fluctuación temporal, típicamente 2–4 semanas, mientras Google vuelve a rastrear e reindexar tus páginas. Los redireccionamientos 301 adecuados son imprescindibles. Hemos visto que la mayoría de los sitios se recuperan a sus clasificaciones previas a la migración dentro de 30 días, y muchos las superan dentro de 60 días debido a las puntuaciones mejoradas de Core Web Vitals.

¿Qué hay sobre la experiencia de edición de contenido de Drupal? Los editores no técnicos necesitan un CMS. Esta es una preocupación válida. El panel de Supabase funciona para equipos técnicos, pero los editores no técnicos típicamente necesitan una interfaz más amigable. Las opciones incluyen: construir un panel de administración personalizado con Next.js (2–3 semanas de trabajo adicional), usar un CMS headless como Sanity o Contentful como capa de edición con Supabase como almacén de datos, o usar APIs autogenerados de Supabase con una herramienta como Retool o Appsmith para interfaces de administración rápidas.

¿Puede Supabase manejar el cumplimiento con HIPAA para organizaciones de salud? Supabase Cloud es compatible con SOC 2 Type II. Para HIPAA, necesitarás un Acuerdo de Asociado Comercial (BAA) con Supabase (contacta su equipo de ventas) o auto-alojar Supabase en tu propia infraestructura compatible con HIPAA (AWS GovCloud, Azure Government, etc.). El auto-alojamiento de Supabase agrega complejidad operacional pero te da control total sobre la residencia de datos y cumplimiento.

¿Cuál es la diferencia de costo real entre multi-site de Drupal y Next.js + Supabase? Para una red de 20 sitios en Acquia o Pantheon, típicamente estás gastando $12,000–$36,000/año solo en hosting. Next.js en Vercel + Supabase para la misma red ejecuta $540–$4,800/año. Factor en el ciclo de actualización de Drupal ($200K–$600K cada 2–3 años) versus costos de actualización casi nulos con Next.js, y la diferencia de TCO de cinco años es a menudo $500K+.

¿Puedo migrar incrementalmente o tiene que ser todo a la vez? La migración incremental funciona bien. Usa reescrituras de Vercel para proxiar rutas específicas a tu sitio Drupal antiguo mientras sirves páginas migradas desde Next.js. Migra una ubicación a la vez. Este enfoque es más bajo en riesgo y te permite validar el nuevo stack antes de comprometerte completamente. Hemos hecho esto con redes de 30+ sitios donde una migración big-bang no era viable.

¿Qué sucede con mi funcionalidad de módulos contribuidos de Drupal? Cada módulo se asigna a algo en el nuevo stack. Webform se convierte en React Hook Form + inserciones de Supabase. Pathauto se convierte en rutas dinámicas de Next.js. Metatag se convierte en API de Metadatos de Next.js. Vistas se convierte en consultas de Supabase. Search API se convierte en búsqueda de texto completo de Supabase o un servicio como Meilisearch. La funcionalidad no desaparece, solo se mueve a una implementación más mantenible. Hemos escrito mapas de migración para los 50 módulos de Drupal más comunes como parte de nuestra práctica de desarrollo de CMS headless.