En este artículo
Una plataforma institucional en Drupal 7 no se vuelve riesgosa únicamente por su antigüedad. El riesgo aparece cuando ya no es posible actualizarla con seguridad, sus módulos dependen de código sin soporte, los flujos editoriales se sostienen con procedimientos manuales y cualquier cambio afecta servicios que siguen operando. Por eso, migrar Drupal 7 a 11 debe tratarse como una iniciativa de modernización tecnológica, no como una actualización de versión.
Drupal 7 finalizó oficialmente su soporte comunitario en enero de 2025. Para una entidad pública, una universidad o una empresa con canales digitales críticos, mantenerlo implica asumir una exposición creciente frente a vulnerabilidades, incompatibilidades de infraestructura y mayores costos de operación. Drupal 11 ofrece una base actualizada para evolucionar, pero llegar allí exige tomar decisiones de arquitectura, datos, experiencia y gobierno de la plataforma.
Migrar Drupal 7 a 11 no es una actualización directa
Entre Drupal 7 y Drupal 11 hay cambios estructurales en la forma de modelar contenido, extender funcionalidades, administrar configuraciones y construir interfaces. Los módulos de Drupal 7 no se trasladan automáticamente, ni es recomendable copiar una base de datos antigua esperando que funcione en la nueva versión.
La migración aprovecha la información de Drupal 7 como fuente, pero construye un destino nuevo con reglas explícitas. Contenidos, usuarios, archivos, taxonomías, menús, redirecciones y metadatos se extraen, transforman y cargan según el modelo definido para Drupal 11. El resultado puede preservar la información institucional y, al mismo tiempo, eliminar estructuras que ya no responden a las necesidades del canal.
Esta diferencia es relevante para los equipos directivos. El alcance no se mide solo por el número de páginas a trasladar, sino por la cantidad de reglas de negocio, integraciones, perfiles de usuario, tipos de contenido y procesos editoriales que dependen de la plataforma actual. Un sitio con 2.000 páginas puede ser menos complejo que uno con 300 contenidos conectados a autenticación corporativa, sistemas documentales, formularios transaccionales y servicios de datos abiertos.
El diagnóstico define el riesgo real de la migración
Antes de construir el nuevo portal, conviene realizar un inventario técnico y funcional. Esta etapa permite distinguir qué debe migrarse, qué debe rediseñarse y qué puede retirarse sin afectar la operación. También evita reproducir en Drupal 11 decisiones que fueron temporales, pero se volvieron permanentes con el tiempo.
El diagnóstico debe revisar el modelo de contenidos, campos personalizados, vocabularios, roles, permisos, flujos de publicación, archivos y dependencias entre módulos. En paralelo, se deben identificar integraciones con directorios corporativos, CRM, ERP, pasarelas de pago, sistemas académicos, analítica, plataformas de atención al ciudadano o repositorios documentales.
No todas las funcionalidades tienen el mismo tratamiento. Algunas pueden resolverse con capacidades nativas de Drupal 11 o módulos mantenidos por la comunidad. Otras requieren componentes a medida, especialmente cuando hay reglas particulares de negocio, consumo de APIs internas o requisitos de auditoría. Las funcionalidades que no aportan valor vigente deben retirarse. Migrar también es una oportunidad para reducir deuda técnica y simplificar la administración.
En entornos institucionales, este análisis debe incluir accesibilidad, seguridad y cumplimiento. Para entidades sujetas a lineamientos GOV.CO, no basta con replicar la navegación existente. Es necesario revisar la arquitectura de información, componentes de interfaz, gestión de contenidos, documentos publicados y mecanismos de interacción para responder a obligaciones actuales y a necesidades reales de la ciudadanía.
Diseñar el destino antes de mover los datos
Un error frecuente consiste en iniciar la carga de contenidos sin definir cómo funcionará el portal nuevo. La secuencia correcta parte de la arquitectura objetivo: tipos de contenido, relaciones entre entidades, permisos, configuración editorial, componentes visuales y contratos de integración. Solo después se establecen los mapas de migración.
En Drupal 11, el diseño de contenido debe favorecer la reutilización y la administración descentralizada con controles claros. Una noticia, una convocatoria, un perfil de investigador o una página de servicio no deberían depender de plantillas rígidas ni de intervenciones técnicas para cambios rutinarios. Los componentes deben responder a patrones de diseño consistentes, con campos suficientes para conservar calidad editorial sin convertir el formulario de edición en una barrera para los equipos de comunicaciones.
También es el momento de decidir si la plataforma necesita una arquitectura desacoplada. Drupal puede operar como gestor de contenido tradicional o como fuente de datos para aplicaciones web y móviles. La opción headless tiene sentido cuando existen varios canales de consumo, requerimientos de experiencia muy específicos o equipos frontend con capacidades maduras. Para un portal institucional con operación editorial centralizada, una arquitectura desacoplada puede añadir complejidad innecesaria. La decisión depende de la estrategia de canales, el presupuesto de operación y la capacidad para sostener la solución en el tiempo.
La calidad de los datos determina la calidad del portal nuevo
Las migraciones suelen revelar problemas acumulados: contenidos duplicados, enlaces rotos, archivos sin contexto, taxonomías inconsistentes, autores inactivos y páginas que nadie reconoce como vigentes. Trasladar todo sin criterios puede convertir Drupal 11 en una copia más moderna del mismo desorden.
Por esta razón, cada conjunto de datos necesita reglas de transformación. Puede ser necesario unificar categorías, convertir formatos de fecha, reasignar autores, depurar archivos, normalizar etiquetas o excluir contenido obsoleto. Las URL históricas merecen especial atención: una estrategia de redirecciones protege el posicionamiento orgánico, evita páginas no encontradas y mantiene el acceso a documentos que usuarios externos aún consultan.
La migración de usuarios también debe evaluarse con criterio. No siempre conviene trasladar todas las cuentas de Drupal 7, especialmente si existen perfiles inactivos o si la organización adoptará autenticación mediante un directorio corporativo. En plataformas críticas, los roles y permisos deben reconstruirse bajo el principio de mínimo privilegio: cada persona accede solo a las acciones necesarias para su función.
Pruebas: el punto donde se valida la continuidad operativa
Una migración confiable no se valida al revisar que el sitio cargue. Debe comprobarse que los contenidos llegaron completos, que las relaciones entre entidades se conservaron, que los permisos funcionan, que los formularios envían información correctamente y que las integraciones responden como se espera.
Las pruebas deben combinar validaciones automáticas y revisión funcional con usuarios del negocio. Los equipos editoriales pueden detectar si un flujo de aprobación perdió una condición relevante; comunicaciones puede identificar una pérdida de jerarquía visual; tecnología puede verificar rendimiento, monitoreo, respaldos y comportamiento bajo carga. En proyectos públicos, las pruebas de accesibilidad deben formar parte del ciclo de calidad, no ser una revisión posterior al lanzamiento.
Es útil establecer criterios de aceptación medibles: porcentaje de contenidos migrados, registros con errores, enlaces redirigidos, tiempos de respuesta, cumplimiento de componentes accesibles y resultados de pruebas de seguridad. Estas evidencias permiten tomar decisiones de salida basadas en información, no en percepciones.
El lanzamiento requiere una estrategia de transición
La puesta en producción puede hacerse en un único corte o por etapas. Un corte total reduce el tiempo de coexistencia entre plataformas, pero requiere alta preparación y una ventana de cambio controlada. Una transición gradual puede ser más conveniente cuando hay múltiples subsitios, servicios independientes o integraciones que deben habilitarse progresivamente.
En ambos casos, debe definirse qué ocurre con el contenido creado durante los últimos días en Drupal 7. Dependiendo del volumen editorial, puede requerirse una migración delta antes del cambio final, una ventana de congelamiento de publicaciones o un procedimiento controlado para registrar novedades. El plan debe incluir reversión, respaldos verificables, responsables de decisión y monitoreo reforzado durante las primeras horas de operación.
La continuidad no termina al publicar Drupal 11. La plataforma requiere actualizaciones de seguridad, observabilidad, administración de configuraciones, revisión de respaldos y atención a incidentes. También necesita una ruta de evolución para nuevas integraciones, componentes y requerimientos institucionales.
Coresis aborda este tipo de iniciativas desde tecnología aplicada con criterio de arquitectura y continuidad: la meta no es solo retirar una versión sin soporte, sino dejar una plataforma administrable, auditable y preparada para responder a lo que la organización necesitará después.
Migrar con éxito significa que el día posterior al lanzamiento los usuarios encuentran información confiable, los equipos pueden operar sin depender de soluciones improvisadas y tecnología cuenta con una base sostenible para evolucionar. Esa es la medida más útil de una modernización bien ejecutada.