Si todavía estás ejecutando Drupal 7 en producción, no voy a endulzar las cosas: estás en tiempo prestado. Drupal 7 llegó a su fin de vida oficial el 5 de enero de 2025, después de múltiples extensiones que se remontan al plazo original de noviembre de 2021. Eso significa no más parches de seguridad, no más soporte comunitario, y no más pretender que la migración puede esperar hasta el próximo trimestre. He ayudado a múltiples equipos empresariales a través de esta situación exacta en los últimos años, y los que esperaron hasta el último momento siempre pagaron más — en dinero, en estrés, y en deuda técnica. Esta guía es todo lo que desearía poder entregar a cada VP de Ingeniería que todavía ejecuta Drupal 7.

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 "fin de vida" significa en la práctica, porque he visto mucha confusión aquí:

  • No más actualizaciones de seguridad. El equipo de seguridad de Drupal no emitirá avisos ni parches para el núcleo de Drupal 7 o módulos contrib. Si se descubre una vulnerabilidad crítica de inyección SQL mañana, estás por tu cuenta.
  • No más correcciones de errores. Cualquier cosa rota se queda rota.
  • Los mantenedores de módulos contrib se están yendo. La mayoría ya lo han hecho. Muchos módulos populares de Drupal 7 no han visto una actualización en años.
  • Los proveedores de alojamiento dejarán de dar soporte. Pantheon, Acquia y Platform.sh han anunciado cronogramas para deprecar los entornos de alojamiento de Drupal 7. Acquia extendió su soporte de Drupal 7 hasta 2026 para clientes existentes, pero es un complemento pago, no una solución a largo plazo.
  • Los problemas de compatibilidad con PHP se acumularán. Drupal 7 fue construido para PHP 5.x. Se ejecuta en PHP 8.1 con parches, pero PHP 8.1 en sí alcanza el fin de vida en diciembre de 2025. Estarás apilando software no soportado sobre software no soportado.

El riesgo de seguridad por sí solo debería ser suficiente para desencadenar acciones. Si tu organización maneja cualquier forma de PII, datos financieros o información de salud, ejecutar Drupal 7 sin parches es un pasivo de cumplimiento. PCI DSS, HIPAA, SOC 2 — todos requieren que mantengas software parchado y soportado.

Por qué los equipos empresariales seguían retrasando

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

  1. "Nuestro sitio Drupal 7 funciona bien." Lo hace. Hasta que no lo hace. El código no dejará de funcionar el 6 de enero, pero el perfil de riesgo cambia dramáticamente.
  2. "La migración de Drupal 8/9/10 no es una actualización simple." Esto es realmente cierto. A diferencia de la ruta de actualización de Drupal 6→7, pasar 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 portarán.
  3. "Tenemos 15 años de contenido y funcionalidad personalizada." Los sitios empresariales de Drupal 7 tienden a estar altamente personalizados. Módulos personalizados, configuraciones de Views, estructuras de taxonomía complejas, integraciones con sistemas heredados. El alcance de la migración es genuinamente grande.
  4. "El presupuesto no fue aprobado." La respuesta más honesta, y la más común.

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

Tus opciones de migración en 2025

Tienes cuatro caminos realistas hacia adelante. Cada uno tiene compensaciones. Déjame desglosarlos honestamente.

Opción Cronograma Rango de costo Mejor para Nivel de riesgo
Drupal 10/11 6-18 meses $200K-$1M+ Equipos invertidos en el ecosistema Drupal Medio
Frontend sin cabecera + Backend Drupal 4-12 meses $150K-$600K Equipos que quieren UX moderna con CMS familiar Medio
Migración CMS sin cabecera 3-9 meses $100K-$500K Equipos listos para dejar Drupal completamente Medio-Alto
Proveedor de soporte extendido Inmediato $30K-$100K/año Equipos que necesitan 6-18 meses más de tiempo de planificación Bajo (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 a partir de 2025, con Drupal 11 lanzado a mediados de 2024 y ganando adopción. 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 la migración realmente implica

Drupal proporciona una API de migración que puede extraer contenido de una base de datos de Drupal 7 a un sitio Drupal 10/11. En mi experiencia, maneja aproximadamente el 60-70% de una migración típica. El resto son complementos de migración personalizados para:

  • Tipos de campo personalizados
  • Referencias de entidades complejas
  • Párrafos (si usaste el módulo Paragraphs)
  • Activos de archivos e imágenes
  • 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 enganchaba hook_node_view(), ahora estás escribiendo suscriptores de eventos y complementos.

// 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 ser reconstruido.

Cronograma realista

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

Opción 2: Ir sin cabecera con un frontend moderno

Aquí es donde las cosas se ponen interesantes, y francamente, es el enfoque que recomiendo más a menudo para equipos empresariales en 2025. 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 de 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 mantiene la interfaz de administrador de Drupal. La conocen. Son productivos en ella. Quitarla causa dolor organizacional.
  • Tu frontend se vuelve dramáticamente más rápido. Generación estática, almacenamiento en caché en el borde, optimización moderna de imágenes — cosas que son dolorosas de agregar a la capa de renderizado de Drupal.
  • Puedes migrar incrementalmente. Pon en funcionamiento el nuevo frontend al lado del sitio antiguo y migra secciones de una en una.

Hemos construido varios frontends de Drupal sin cabecera con Next.js y Astro, y las mejoras de rendimiento son sustanciales. Un cliente vio su Largest Contentful Paint caer de 4.2s a 0.8s después de pasar a un frontend Next.js con ISR (Incremental Static Regeneration).

// Página Next.js obteniendo 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) hace esto aún más fácil con soporte incorporado para modo de vista previa, autenticación y mapeo de tipos de contenido.

El problema

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

Opción 3: Pasar a un CMS sin cabecera completamente

A veces lo correcto es dejar Drupal completamente. Si tu equipo no tiene experiencia sólida en Drupal, si estás teniendo problemas para contratar desarrolladores de Drupal (y lo estás — 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 cabecera podría ser lo indicado.

Objetivos populares de migración

CMS Precios (2025) Mejor para API de contenido Curva de aprendizaje
Contentful $300-$2,500+/mes Grandes equipos editoriales GraphQL + REST Medio
Sanity $99-$949+/mes (empresa personalizada) Equipos dirigidos por desarrolladores GROQ + GraphQL Bajo-Medio
Storyblok $109-$449+/mes Necesidades de edición visual REST + GraphQL Bajo
Strapi (auto-hospedado) Gratis (auto-hospedado) / $29+/mes (nube) Equipos que quieren control REST + GraphQL Medio
Payload CMS Gratis (auto-hospedado) / $35+/mes (nube) Equipos de TypeScript-first REST + GraphQL Medio

Trabajamos con varios de estos a través de nuestra práctica de desarrollo de CMS sin cabecera. La opció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 cabecera

Esto es en realidad más fácil que migrar a Drupal 10/11 en algunos aspectos. No estás limitado por el marco de migración de Drupal. El enfoque típico:

  1. Exporta contenido de Drupal 7 vía Drush o consultas directas a base de datos
  2. Transforma los datos al modelo de contenido de tu CMS objetivo usando scripts (Python y Node.js funcionan bien)
  3. Importa vía la API de gestión del CMS
  4. Verifica y corrige referencias, medios y relaciones
# Exportación simple de contenido de Drupal 7 vía base de datos
import mysql.connector
import json

db = mysql.connector.connect(
    host="localhost",
    user="drupal",
    password="tucontraseña",
    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 Párrafos) 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 (Comprar tiempo)

Si genuinamente necesitas más tiempo — y a veces lo haces, especialmente con ciclos presupuestarios y prioridades organizacionales — proveedores de soporte extendido pueden mantener tu sitio Drupal 7 parcheado mientras planificas.

Proveedores clave que ofrecen soporte extendido de Drupal 7

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

Esta es una estrategia de puente legítima, no una solución a largo plazo. Yo 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 plataformas modernas se amplía.

Planificación de migración: un marco paso a paso

Aquí está el marco que uso con 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? ¿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. Categoriza como: tiene equivalente D10, necesita reemplazo personalizado, puede ser eliminado. Uso drush pm:list --status=enabled y referencias cruzadas con drupal.org.
  • Auditoría de integración: ¿Con qué sistemas externos habla Drupal? Pasarelas de pago, CRMs, automatización de marketing, proveedores de SSO?
  • Línea base de tráfico y rendimiento: Documenta métricas de rendimiento actual. Las necesitarás para comparación.
  • Auditoría de roles de usuario: ¿Cuántos flujos de trabajo editoriales existen? ¿Qué permisos importan?

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 verdadera decisión arquitectónica que debería involucrar liderazgo de ingeniería, partes interesadas de contenido, y quienquiera que controle el presupuesto.

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

Antes de comprometerse 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
  • Puntos de referencia de rendimiento en la nueva pila

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 despiadadamente. No todo de Drupal 7 necesita venir. En mi experiencia, el 20-30% del contenido y la funcionalidad en un sitio empresarial típico de Drupal 7 puede ser eliminado durante la migración.

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

Las redirecciones son críticas. Cada URL en tu sitio Drupal 7 que tiene equidad de búsqueda necesita una redirección 301 a la nueva ubicación. Usa exportaciones del módulo path_redirect y globalredirect como punto de partida, luego rastrea el sitio antiguo con Screaming Frog para construir un mapa de redirección completo.

Estrategia de migración de contenido

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

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 imagen codificadas, iframes incrustados, y ocasionalmente PHP raw (si alguien habilitó el módulo de filtro PHP — un auténtico horror de seguridad). Antes de migrar, necesitas decidir: ¿limpiarla, o portar el desorden?

Mi recomendación: limpiarla. Escribe scripts de transformación que:

  • Eliminen estilos en línea
  • Conviertan etiquetas <img> a referencias de medios propias
  • Arreglen enlaces internos para usar la nueva estructura de URL
  • Conviertan cualquier token de inserción de WYSIWYG al nuevo formato

Migración de medios

Los sitios de Drupal 7 manejan medios de maneras salvajemente diferentes. Algunos usan el módulo Media (1.x o 2.x), algunos usan campos de archivo simples, algunos usan tokens de medios incrustados en campos body. Mapea cada patrón de manejo de medios antes de comenzar a escribir código de migración.

Si te estás moviendo a un CMS sin cabecera, también necesitarás decidir dónde viven los archivos de medios. La mayoría de CMSs sin cabecera tienen gestión de activos incorporada, 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... digamos que "creativo". Las estructuras de datos son inconsistentes y requieren mapeo cuidadoso.

Estimaciones de costos y cronogramas

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

Complejidad del sitio Migración Drupal 10/11 Migración CMS sin cabecera Frontend sin cabecera + 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
Medio (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 completamente cargados incluyendo descubrimiento, desarrollo, migración, QA y gestión de proyectos. Tu experiencia puede variar según la composición del equipo (en casa vs. agencia), ubicación geográfica, y cuánta limpieza hagas versus portar tal como está.

¿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 una recreación 1:1. Tu sitio Drupal 7 ha acumulado 10+ años de cruft. 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 olvidó las redirecciones hasta dos semanas antes del lanzamiento. Tenían 45,000 URLs para mapear. No seas ese equipo.

No involucrar a las partes interesadas editoriales lo suficientemente temprano. Las personas que usan el CMS diariamente tendrán opiniones fuertes sobre el nuevo sistema. Involúcralas en la Fase 1, no en la Fase 4.

Elegir una plataforma basada en características, no en capacidad del equipo. El mejor CMS es aquello que tu equipo puede realmente mantener. Si no tienes experiencia en Drupal, migrar a Drupal 10/11 sin contratar para ello es configurarse para una repetición de esta situación en 5 años.

Ejecutar sistemas paralelos demasiado tiempo. Establece una fecha de corte dura. Ejecutar lo viejo y lo nuevo en paralelo es caro y confuso.

Saltarse la congelación de contenido. Durante el impulso de migración final, necesitas una congelación de contenido en el sitio antiguo. Planifica para ello. Comunícalo. Los autores de contenido lo odian, pero es necesario para asegurar que nada se pierda.

Preguntas frecuentes

¿Qué pasa 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 parchar indefinidamente. Este es un riesgo real — los sitios de Drupal son objetivos frecuentes para ataques automatizados. También enfrentarás problemas de compatibilidad cada vez mayores a medida que avanzan las versiones de PHP y los proveedores de alojamiento dejan de soportar versiones antiguas de PHP. Para cualquier organización con requisitos de cumplimiento (PCI, HIPAA, SOC 2, GDPR), ejecutar software no soportado es una violación directa.

¿Puedo actualizar directamente de Drupal 7 a Drupal 11? Sí, la API de migración soporta migración directa de Drupal 7 a Drupal 10 o 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 contenido migrado. Tus temas, módulos personalizados y configuraciones no se transfieren directamente.

¿Cuánto tiempo toma una migración típica de Drupal 7? Para un sitio empresarial de tamaño medio, planifica 6-12 meses desde el inicio hasta el lanzamiento. Los sitios más pequeños con funcionalidad personalizada limitada pueden hacerse en 3-4 meses. Los sitios grandes y complejos con contenido multilingüe, integraciones extensas y personalización pesada pueden tomar 12-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 CMS? Depende de tu equipo y tus necesidades. Si tienes experiencia en Drupal en casa, tu modelo de contenido se adapta bien al sistema de entidades de Drupal, y necesitas las fortalezas de Drupal (permisos complejos, multilingüe, multisitio), entonces permanecer en el ecosistema tiene sentido. Si estás teniendo problemas para contratar desarrolladores de Drupal, tu sitio es principalmente un sitio de marketing sin flujos de trabajo editoriales complejos, o quieres moverte a una arquitectura sin cabecera, un CMS diferente podría ser la mejor inversión.

¿Cuál es la opción más barata para migrar de Drupal 7? El soporte extendido de un proveedor como Tag1 ($30K-$80K/año) es la opción más barata a corto plazo, pero no resuelve el problema subyacente. Para migración real, pasar a un CMS sin cabecera 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 más detalles sobre cómo estructuramos proyectos de migración.

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

¿Puedo migrar contenido incrementalmente o tiene que ser todo de una vez? La migración incremental es posible y a menudo preferible para sitios grandes. Con una arquitectura sin cabecera, puedes poner en funcionamiento el nuevo frontend y migrar secciones del sitio de una en una, usando reglas de proxy inverso para enrutar tráfico al backend apropiado. Esto reduce el riesgo y te permite validar cada sección antes de continuar. El comercio es una complejidad operacional aumentada durante el período de migración.

¿Debería considerar WordPress como objetivo de migración? WordPress es una opción viable para sitios más simples, pero tengo cuidado para casos de uso empresariales. Si tu sitio Drupal 7 tiene tipos de contenido complejos, permisos granulares, o flujos de trabajo editoriales sofisticados, WordPress se sentirá como un paso atrás. El modelo de contenido de WordPress (posts, páginas y tipos de post personalizados) es más simple que el sistema de entidades de Drupal. Para equipos empresariales, miraría más seriamente a Drupal 10/11 o un CMS sin cabecera apropiado. Dicho esto, WordPress con ACF Pro y un frontend sin cabecera puede funcionar bien para sitios centrados en marketing.