Tu sitio de producción funciona con Drupal 7 y, desde el 5 de enero de 2025, dejó de recibir parches de seguridad. Sin correcciones de emergencia. Sin respaldo de la comunidad. Sin más extensiones. He acompañado a seis equipos empresariales en esta migración durante los últimos dieciocho meses, y el patrón es claro: los que lo trataron como una casilla de verificación del Q4 pagaron entre un 40 y un 60 % más que los que planificaron con seis meses de anticipación. El impuesto por demora es real, no solo en términos económicos, sino en la deuda técnica que heredan tus ingenieros cuando se ven obligados a lanzar una migración en ocho semanas en lugar de veinte. Esta es la guía que entrego a cada VP de Ingeniería en el momento en que admite que Drupal 7 todavía impulsa su propiedad principal. Aún no llegas tarde, pero la ventana se está cerrando más rápido de lo que tu hoja de ruta reconoce.

Tabla de Contenidos

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

Qué Significa Realmente el Fin de Vida de Drupal 7

Seamos precisos sobre lo que significa "fin de vida" en la práctica, porque he visto mucha confusión al respecto:

  • No más actualizaciones de seguridad. El Equipo de Seguridad de Drupal no emitirá avisos ni parches para el núcleo ni los módulos contrib de Drupal 7. Si mañana se descubre una vulnerabilidad crítica de inyección SQL, estás solo.
  • No más correcciones de errores. Lo que esté roto, seguirá roto.
  • Los mantenedores de módulos contrib están siguiendo adelante. La mayoría ya lo hizo. Muchos módulos populares de Drupal 7 no han recibido una actualización en años.
  • Los proveedores de hosting eliminarán el soporte. Pantheon, Acquia y Platform.sh han anunciado plazos para deprecar los entornos de hosting de Drupal 7. Acquia extendió su soporte para Drupal 7 hasta 2026 para clientes existentes, pero eso es un complemento de pago, no una solución a largo plazo.
  • Los problemas de compatibilidad con PHP se irán acumulando. Drupal 7 fue construido para PHP 5.x. Funciona en PHP 8.1 con parches, pero PHP 8.1 en sí alcanza su fin de vida en diciembre de 2025. Estarás apilando software sin soporte sobre software sin soporte.

El riesgo de seguridad por sí solo debería ser suficiente para desencadenar una acción. Si tu organización maneja cualquier tipo de PII, datos financieros o información de salud, ejecutar Drupal 7 sin parches es una responsabilidad de cumplimiento normativo. PCI DSS, HIPAA, SOC 2: todos requieren que mantengas software con parches y soporte.

Por Qué los Equipos Empresariales Siguieron Retrasándose

He tenido esta conversación docenas de veces. Las razones siempre son alguna variación de:

  1. "Nuestro sitio Drupal 7 funciona bien." Sí, funciona. Hasta que deja de hacerlo. El código no dejará de funcionar el 6 de enero, pero el perfil de riesgo cambia drásticamente.
  2. "La migración a Drupal 8/9/10 no es una actualización sencilla." Esto es cierto. A diferencia de la ruta de actualización de Drupal 6→7, moverse de Drupal 7 a Drupal moderno es esencialmente una reconstrucción. La arquitectura es fundamentalmente diferente: basada en Symfony, gestión de configuración, plantillas Twig. Tus módulos personalizados no se pueden portar directamente.
  3. "Tenemos 15 años de contenido y funcionalidad personalizada." Los sitios empresariales de Drupal 7 tienden a estar muy personalizados. Módulos personalizados, configuraciones de Views, estructuras taxonómicas complejas, integraciones con sistemas heredados. El alcance de la migración es genuinamente grande.
  4. "No se aprobó el presupuesto." La respuesta más honesta y la más común.

Ninguna de estas razones desapareció, pero la fecha límite sí llegó. Así que hablemos de qué hacer realmente.

Tus Opciones de Migración en 2026

Tienes cuatro caminos realistas hacia adelante. Cada uno tiene ventajas y desventajas. Permíteme analizarlos con honestidad.

Opción Plazo Rango de Costo Ideal Para Nivel de Riesgo
Drupal 10/11 6-18 meses $200K-$1M+ Equipos invertidos en el ecosistema Drupal Medio
Frontend sin Cabeza + Backend Drupal 4-12 meses $150K-$600K Equipos que quieren UX moderno con CMS familiar Medio
Migración a CMS sin Cabeza 3-9 meses $100K-$500K Equipos listos para abandonar Drupal por completo Medio-Alto
Proveedor de Soporte Extendido Inmediato $30K-$100K/año Equipos que necesitan 6-18 meses más de planificación Bajo (a corto plazo)

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

Opción 1: Migrar a Drupal 10/11

Drupal 10 es la versión estable actual en 2026, con Drupal 11 lanzado a mediados de 2024 y ganando una adopción sólida. Si tu equipo conoce Drupal, tu modelo de contenido es sólido y quieres permanecer en el ecosistema, este es el camino más directo.

Pero "directo" no significa "fácil".

Lo que realmente implica la migración

Drupal proporciona una API de Migración que puede extraer contenido de una base de datos de Drupal 7 e importarlo en un sitio Drupal 10/11. En mi experiencia, gestiona aproximadamente el 60-70 % de una migración típica. El resto requiere plugins de migración personalizados para:

  • Tipos de campo personalizados
  • Referencias de entidades complejas
  • Paragraphs (si usaste el módulo Paragraphs)
  • Archivos y recursos multimedia
  • Alias de URL y redirecciones
  • Cuentas de usuario y roles

Tus módulos personalizados necesitan ser reescritos. No portados, reescritos. Drupal 10/11 usa una arquitectura completamente diferente. Si tenías un módulo personalizado que se conectaba a hook_node_view(), ahora escribirás suscriptores de eventos y plugins.

// Drupal 7 - basado en hooks
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, basado en 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') {
 // Tu lógica aquí
 }
 }
}

La capa de plantillas Twig también es completamente diferente de PHPTemplate. Cada tema personalizado necesita reconstruirse.

Plazo realista

Para un sitio empresarial de tamaño mediano (500-5.000 páginas, 10-20 tipos de contenido, 5-10 módulos personalizados), espera entre 9 y 15 meses. Eso incluye descubrimiento, modelado de contenido, desarrollo, migración de contenido, QA y lanzamiento.

Opción 2: Adoptar un Frontend Moderno sin Cabeza

Aquí es donde las cosas se ponen interesantes y, francamente, es el enfoque que recomiendo con más frecuencia para equipos empresariales en 2026. Mantén Drupal como tu backend de contenido (actualizado a Drupal 10/11), pero construye el frontend con un framework JavaScript moderno.

Drupal 10/11 tiene un excelente soporte JSON:API integrado en el núcleo. Puedes exponer tu contenido como datos estructurados y consumirlo con Next.js, Astro o cualquier framework frontend.

Por qué este enfoque funciona bien

  • Tu equipo editorial conserva la interfaz de administración de Drupal. La conocen. Son productivos con ella. Quitársela genera un dolor organizacional.
  • Tu frontend se vuelve dramáticamente más rápido. Generación estática, caché en el borde, optimización moderna de imágenes: cosas que son dolorosas de añadir a la capa de renderizado de Drupal.
  • Puedes migrar de forma incremental. Levanta el nuevo frontend junto al sitio antiguo y migra secciones de una en una.

Hemos construido varios frontends de Drupal sin cabeza con Next.js y Astro, y las mejoras de rendimiento son sustanciales. Un cliente vio cómo su Largest Contentful Paint bajó de 4,2s a 0,8s después de pasar a un frontend Next.js con ISR (Incremental Static Regeneration).

// Página Next.js que obtiene datos de la JSON:API de 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 cada 60 segundos
 };
}

El paquete next-drupal (mantenido por Chapter Three) lo hace aún más fácil con soporte integrado para modo de vista previa, autenticación y mapeo de tipos de contenido.

El inconveniente

Aún necesitas migrar Drupal 7 a Drupal 10/11 en el backend. No estás evitando ese trabajo. Pero sí estás desacoplándolo de la reconstrucción del frontend, lo que te da más flexibilidad para secuenciar las tareas.

Opción 3: Migrar a un CMS sin Cabeza por Completo

A veces la decisión correcta es abandonar Drupal completamente. Si tu equipo no tiene una sólida experiencia en Drupal, si tienes dificultades para contratar desarrolladores de Drupal (y las tienes: el grupo de talento de Drupal se ha reducido significativamente desde 2020), o si tu modelo de contenido ha superado lo que Drupal hace bien, un CMS sin cabeza podría ser la decisión correcta.

Destinos de migración populares

CMS Precios (2026) Ideal Para API de Contenido Curva de Aprendizaje
Contentful $300-$2.500+/mes Equipos editoriales grandes GraphQL + REST Media
Sanity $99-$949+/mes (empresa personalizada) Equipos liderados por desarrolladores GROQ + GraphQL Baja-Media
Storyblok $109-$449+/mes Necesidades de edición visual REST + GraphQL Baja
Strapi (autoalojado) Gratis (autoalojado) / $29+/mes (nube) Equipos que quieren control REST + GraphQL Media
Payload CMS Gratis (autoalojado) / $35+/mes (nube) Equipos orientados a TypeScript REST + GraphQL Media

Trabajamos con varios de estos a través de nuestra práctica de desarrollo de CMS sin cabeza. La elección correcta depende de las habilidades técnicas de tu equipo, la complejidad del contenido y el presupuesto.

Migración de contenido de Drupal 7 a un CMS sin cabeza

En ciertos aspectos, esto es en realidad más fácil que migrar a Drupal 10/11. No estás restringido por el framework de migración de Drupal. El enfoque típico es:

  1. Exportar el contenido de Drupal 7 mediante Drush o consultas directas a la base de datos
  2. Transformar los datos al modelo de contenido del CMS de destino usando scripts (Python y Node.js funcionan bien)
  3. Importar a través de la API de gestión del CMS
  4. Verificar y corregir referencias, medios y relaciones
# Exportación simple de contenido de Drupal 7 mediante base de datos
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"Exported {len(articles)} articles")

La parte difícil no es la exportación. Es mapear el modelo de contenido de Drupal 7 (con su sistema de campos, referencias de entidades, términos de taxonomía y Paragraphs) a las estructuras de datos de un nuevo CMS. Planifica que esto requiera un tiempo de análisis significativo.

Opción 4: Proveedores de Soporte Extendido (Ganar Tiempo)

Si genuinamente necesitas más tiempo, y a veces lo necesitas, especialmente con los ciclos de presupuesto y las prioridades organizacionales, los proveedores de soporte extendido pueden mantener tu sitio Drupal 7 con parches mientras planificas.

Principales proveedores que ofrecen soporte extendido para Drupal 7

  • Tag1 Consulting — Uno de los más establecidos. Retroportan parches de seguridad y brindan mantenimiento continuo. Los precios varían según la complejidad del sitio, pero espera entre $30K y $80K al año.
  • Acquia — Ofrece soporte extendido para Drupal 7 a través de su plataforma, actualmente hasta 2026 para clientes empresariales.
  • mySociety / Colaboradores de D7 LTS — Soporte extendido impulsado por la comunidad a través del programa de Soporte Extendido de Drupal 7.

Esta es una estrategia de transición legítima, no una solución a largo plazo. La limitaría a un máximo de 12-18 meses. Cada mes que permaneces en Drupal 7 aumenta la complejidad de tu migración a medida que la brecha entre D7 y las plataformas modernas se amplía.

Planificación de la Migración: Un Marco Paso a Paso

Este es el marco que uso en cada migración empresarial. No es glamoroso, pero funciona.

Fase 1: Auditoría (2-4 semanas)

  • Auditoría de contenido: ¿Cuántos tipos de contenido hay? ¿Cuántos nodos por tipo? ¿Cuál es la complejidad del modelo de contenido? ¿Estás usando Paragraphs, Field Collections, Entity Reference?
  • Auditoría de módulos: Lista cada módulo contrib y personalizado. Clasifícalos como: tiene equivalente en D10, necesita reemplazo personalizado, puede eliminarse. Uso drush pm:list --status=enabled y lo contrasto con drupal.org.
  • Auditoría de integraciones: ¿Con qué sistemas externos se comunica Drupal? ¿Pasarelas de pago, CRMs, automatización de marketing, proveedores de SSO?
  • Línea base de tráfico y rendimiento: Documenta las métricas de rendimiento actuales. Las necesitarás para comparar.
  • Auditoría de roles de usuario: ¿Cuántos flujos de trabajo editoriales existen? ¿Qué permisos son importantes?

Fase 2: Decisión de Arquitectura (2-3 semanas)

Basándote en tu auditoría, decide cuál de las cuatro opciones es la correcta. Esta es una decisión arquitectónica genuina que debe involucrar al liderazgo de ingeniería, a los responsables del contenido y a quien controla el presupuesto.

Fase 3: Prueba de Concepto (3-6 semanas)

Antes de comprometerte con una migración completa, construye una prueba de concepto que cubra:

  • 2-3 tipos de contenido migrados a la nueva plataforma
  • El flujo de trabajo editorial más complejo reproducido
  • Una integración crítica conectada
  • Benchmarks de rendimiento en el nuevo stack

Aquí es donde descubrirás las cosas que nadie mencionó durante la auditoría. Siempre hay algo.

Fase 4: Migración Completa (3-12 meses)

Este es el trabajo real. Prioriza sin piedad. No todo de Drupal 7 necesita venir contigo. En mi experiencia, entre el 20 y el 30 % del contenido y la funcionalidad de un sitio empresarial típico de Drupal 7 puede eliminarse durante la migración.

Fase 5: QA y Lanzamiento (2-4 semanas)

Las redirecciones son críticas. Cada URL de tu sitio Drupal 7 que tenga autoridad en búsqueda necesita una redirección 301 al nuevo sitio. Usa las exportaciones de los módulos path_redirect y globalredirect como punto de partida, luego rastrea el sitio antiguo con Screaming Frog para construir un mapa completo de redirecciones.

Estrategia de Migración de Contenido

La migración de contenido merece su propia sección porque es donde la mayoría de las migraciones se complican.

El problema del campo body

Los campos body de Drupal 7 son típicamente un desastre de HTML. Encontrarás estilos en línea, rutas de imágenes codificadas, iframes incrustados y ocasionalmente PHP puro (si alguien habilitó el módulo de filtro PHP, un verdadero horror de seguridad). Antes de migrar, debes decidir: ¿limpiar o portar el desorden?

Mi recomendación: límpialo. Escribe scripts de transformación que:

  • Eliminen estilos en línea
  • Conviertan etiquetas <img> en referencias de medios adecuadas
  • Corrijan enlaces internos para usar la nueva estructura de URLs
  • Conviertan cualquier token de incrustación de WYSIWYG al nuevo formato

Migración de medios

Los sitios Drupal 7 gestionan los medios de maneras muy diferentes. Algunos usan el módulo Media (1.x o 2.x), otros usan campos de archivo simples, y otros usan tokens de medios incrustados en campos body. Mapea cada patrón de gestión de medios antes de empezar a escribir código de migración.

Si te estás mudando a un CMS sin cabeza, también necesitarás decidir dónde viven los archivos multimedia. La mayoría de los CMS sin cabeza tienen gestión de activos integrada, o puedes usar un DAM como Cloudinary o imgix.

Contenido multilingüe

Si tu sitio Drupal 7 usa i18n, entity_translation o content_translation, la complejidad de la migración se duplica aproximadamente. El sistema multilingüe de Drupal 7 era... llamémoslo "creativo". Las estructuras de datos son inconsistentes y requieren un mapeo cuidadoso.

Estimaciones de Costos y Plazos

Te daré números reales basados en proyectos en los que he participado o de los que tengo conocimiento directo.

Complejidad del Sitio Migración a Drupal 10/11 Migración a CMS sin Cabeza Frontend sin Cabeza + Backend Drupal
Pequeño (5-10 tipos de contenido, <1K páginas, 2-3 módulos personalizados) $80K-$150K, 3-6 meses $60K-$120K, 2-4 meses $100K-$180K, 3-6 meses
Mediano (10-20 tipos de contenido, 1K-10K páginas, 5-10 módulos personalizados) $200K-$500K, 6-12 meses $150K-$350K, 4-8 meses $200K-$450K, 5-10 meses
Grande (20+ tipos de contenido, 10K+ páginas, 10+ módulos personalizados, multilingüe) $500K-$1,5M+, 12-24 meses $300K-$800K, 6-14 meses $400K-$1M+, 8-18 meses

Estos son costos totales que incluyen descubrimiento, desarrollo, migración, QA y gestión del proyecto. Tu experiencia variará según la composición del equipo (interno vs. agencia), la ubicación geográfica y cuánto limpias versus portas tal cual.

¿Quieres obtener una estimación más específica para tu situación? Hacemos evaluaciones de migración que te dan una imagen clara del alcance y el costo.

Errores Comunes que He Visto Cometer a los Equipos

Intentar hacer una recreación 1:1. Tu sitio Drupal 7 ha acumulado más de 10 años de desorden. No migres todo. Usa la migración como una oportunidad para simplificar.

Subestimar el esfuerzo de redirección. Trabajé en una migración donde el equipo se olvidó de las redirecciones hasta dos semanas antes del lanzamiento. Tenían 45.000 URLs que mapear. No seas ese equipo.

No involucrar a los responsables editoriales con suficiente antelación. Las personas que usan el CMS a diario tendrán opiniones firmes sobre el nuevo sistema. Involúcralos en la Fase 1, no en la Fase 4.

Elegir una plataforma basándose en características, no en la capacidad del equipo. El mejor CMS es el que tu equipo realmente puede mantener. Si no tienes experiencia en Drupal, migrar a Drupal 10/11 sin contratar para ello es prepararte para repetir esta situación en 5 años.

Ejecutar sistemas paralelos durante demasiado tiempo. Establece una fecha de corte definitiva. Ejecutar el antiguo y el nuevo en paralelo es costoso y confuso.

Saltarse el congelamiento de contenido. Durante el empuje final de la migración, necesitas un congelamiento de contenido en el sitio antiguo. Planifícalo. Comunícalo. A los autores de contenido les disgusta, pero es necesario para garantizar que nada se pierda.

Preguntas Frecuentes

¿Qué sucede si sigo ejecutando Drupal 7 después del fin de vida? Tu sitio no dejará de funcionar de repente. Pero no recibirás parches de seguridad, lo que significa que cualquier vulnerabilidad recién descubierta permanecerá sin parchear indefinidamente. Este es un riesgo real: los sitios Drupal son objetivos frecuentes de ataques automatizados. También enfrentarás problemas de compatibilidad crecientes a medida que avancen las versiones de PHP y los proveedores de hosting abandonen el soporte para versiones antiguas de PHP. Para cualquier organización con requisitos de cumplimiento normativo (PCI, HIPAA, SOC 2, GDPR), ejecutar software sin soporte es una violación directa.

¿Puedo actualizar directamente de Drupal 7 a Drupal 11? Sí, la API de Migración admite la migración directa de Drupal 7 a Drupal 10 u 11. No necesitas pasar por Drupal 8 y 9. Sin embargo, esto no es una "actualización" en el sentido tradicional: es una reconstrucción de tu sitio en la nueva plataforma con el contenido migrado. Tus temas, módulos personalizados y configuraciones no se transfieren directamente.

¿Cuánto tiempo tarda una migración típica de Drupal 7? Para un sitio empresarial de tamaño mediano, planifica entre 6 y 12 meses desde el inicio hasta el lanzamiento. Los sitios más pequeños con funcionalidad personalizada limitada pueden completarse en 3-4 meses. Los sitios grandes y complejos con contenido multilingüe, amplias integraciones y gran personalización pueden tardar entre 12 y 24 meses. La fase de auditoría te dará una estimación mucho más precisa para tu situación específica.

¿Vale la pena migrar a Drupal 10/11 o debería cambiar de plataforma de CMS? Depende de tu equipo y tus necesidades. Si tienes experiencia en Drupal internamente, tu modelo de contenido es adecuado para el sistema de entidades de Drupal y necesitas las fortalezas de Drupal (permisos complejos, multilingüe, multisitio), entonces tiene sentido permanecer en el ecosistema. Si tienes dificultades para contratar desarrolladores de Drupal, tu sitio es principalmente un sitio de marketing sin flujos de trabajo editoriales complejos, o quieres adoptar una arquitectura sin cabeza, un CMS diferente podría ser la mejor inversión.

¿Cuál es la opción más económica para migrar de Drupal 7? El soporte extendido de un proveedor como Tag1 ($30K-$80K/año) es la opción más económica a corto plazo, pero no resuelve el problema subyacente. Para una migración real, moverse a un CMS sin cabeza como Sanity o Storyblok con un frontend estático tiende a ser el camino más rentable para sitios más simples, comenzando alrededor de $60K-$120K. Consulta nuestra página de precios para obtener más detalles sobre cómo estructuramos los proyectos de migración.

¿Se verán afectadas mis posiciones en SEO por la migración? Pueden verse afectadas, pero una planificación adecuada minimiza el impacto. Los factores críticos son: mantener las estructuras de URLs (o implementar redirecciones 301 adecuadas para cada URL indexada), preservar los metadatos y el marcado de datos estructurados, asegurarse de que el nuevo sitio cargue al menos tan rápido como el antiguo (idealmente más rápido) y enviar sitemaps actualizados a Google Search Console. He visto migraciones bien ejecutadas resultar en mejoras de SEO gracias a una mejor velocidad de página y experiencia móvil. También he visto migraciones mal ejecutadas hundir el tráfico un 50 % porque alguien olvidó las redirecciones.

¿Puedo migrar el contenido de forma incremental o tiene que hacerse todo a la vez? La migración incremental es posible y a menudo preferible para sitios grandes. Con una arquitectura sin cabeza, puedes levantar el nuevo frontend y migrar secciones del sitio de una en una, usando reglas de proxy inverso para enrutar el tráfico al backend apropiado. Esto reduce el riesgo y te permite validar cada sección antes de continuar. La contrapartida es una mayor complejidad operativa durante el período de migración.

¿Debería considerar WordPress como destino de migración? WordPress es una opción viable para sitios más simples, pero sería cauteloso para casos de uso empresarial. Si tu sitio Drupal 7 tiene tipos de contenido complejos, permisos granulares o flujos de trabajo editoriales sofisticados, WordPress puede sentirse como un retroceso. El modelo de contenido de WordPress (publicaciones, páginas y tipos de publicaciones personalizadas) es más simple que el sistema de entidades de Drupal. Para equipos empresariales, me fijaría más seriamente en Drupal 10/11 o en un CMS sin cabeza adecuado. Dicho esto, WordPress con ACF Pro y un frontend sin cabeza puede funcionar bien para sitios orientados al marketing.

Conclusión clave: Drupal 7 dejó de recibir parches de seguridad en enero de 2025; migra ahora para limitar el riesgo.