Fin de vida de Drupal 10, Umbraco 13 y Kentico Xperience 13: qué hacer antes de diciembre de 2026

Tres versiones de gestores de contenidos muy extendidas se quedan sin soporte con unas tres semanas de diferencia:

• Drupal 10: fin de vida el 9 de diciembre de 2026.
• Umbraco 13: fin de vida el 14 de diciembre de 2026.
• Kentico Xperience 13: todo el soporte, correcciones de seguridad incluidas, se acaba a partir del 1 de enero de 2027.

En esas fechas no se apaga nada. El 10 de diciembre, un sitio en Drupal 10 sirve páginas exactamente igual que el 8 de diciembre, y los editores siguen publicando. Lo que se acaba es el suministro de correcciones de seguridad. A partir de entonces, una vulnerabilidad descubierta en tu versión se queda abierta salvo que alguien la cierre por ti.

Al escribir esto, el 3 de octubre de 2026, quedan unas diez semanas para las dos primeras fechas. Basta para un sitio en Drupal o Umbraco bien mantenido. No basta para reconstruir un Kentico 13.

A quién va dirigido realmente

El trabajo pesa más en los sitios con código a medida: módulos y temas propios de Drupal, editores de propiedades y paneles propios de Umbraco, widgets e integraciones de Kentico, y todo lo que construyó una agencia que ya no está.

Si tu sitio en Drupal está cerca de una instalación estándar con módulos contribuidos populares, la actualización es sobre todo mecánica, y puede que tu proveedor de alojamiento ya la tenga programada. Pregúntale la fecha.

Si usas Umbraco 13 y contratas el soporte extendido (ver más abajo), diciembre no es un precipicio para ti. Es un corte de parches que has pagado por aplazar.

Drupal 10: termina el 9 de diciembre de 2026

Qué se acaba

La declaración del propio proyecto es breve: «Drupal 10 llegará al final de su vida el 9 de diciembre de 2026». Drupal 10.6 es la última versión menor, y el calendario de versiones dice que después de esa fecha no se publicará ninguna versión nueva de Drupal 10.

En la semana del 20 de septiembre de 2026, las estadísticas de uso de drupal.org contaban 221.417 sitios en ramas de Drupal 10 frente a 210.728 en Drupal 11, de un total de 524.579 que envían datos. Unos cuatro de cada diez sitios Drupal que envían datos tienen diez semanas por delante en su versión actual. De ellos, 21.148 siguen en Drupal 10.0, 10.1 o 10.2, lo que supone dar antes un paso adicional.

Qué implica la actualización

La guía oficial de actualización de Drupal 10 a 11 se reduce a unos cuantos trabajos:

1. Primero, el alojamiento. Drupal 11 necesita PHP 8.3.0 o superior. Drupal 10 funcionaba sin problemas con PHP 8.1 y 8.2. PHP 8.1 ya no tiene soporte, y el soporte de seguridad de PHP 8.2 termina el 31 de diciembre de 2026. Si tu servidor usa cualquiera de los dos, cambia antes de PHP, como un trabajo independiente y probado.
2. Llegar a Drupal 10.3.0 o superior. Las actualizaciones del núcleo anteriores a la 10.3.0 se han eliminado en Drupal 11, así que un sitio en la 10.2 no puede saltar directamente.
3. Resolver los módulos del núcleo eliminados. Actions UI, Activity Tracker, Book, Forum, Statistics y Tour ya no están en el núcleo de Drupal 11. Si usas alguno, deja de usarlo o pasa a su versión contribuida mientras sigues en Drupal 10.3 o superior, antes de actualizar el código.
4. Portar el código a medida. El módulo Upgrade Status muestra dónde tu código y tus módulos contribuidos no están preparados. Drupal Rector reescribe automáticamente muchas llamadas a API obsoletas; el resto se hace a mano. En un sitio con años de módulos a medida, aquí es donde se van las horas.
5. Revisar cada módulo contribuido. Cada uno necesita una versión compatible con Drupal 11. Donde no exista, la guía remite a los parches de la cola de incidencias del módulo o al endpoint Lenient Composer. Cada módulo que se arrastra así es mantenimiento que pasa a ser tuyo.
6. Herramientas. Necesitas acceso por línea de comandos con Composer y Drush, y un registro de los ficheros de scaffold personalizados para que sobrevivan a la actualización.

¿Conviene esperar a Drupal 12?

No. Drupal 12.0.0 está previsto para la semana del 7 de diciembre de 2026, la misma semana en que termina el soporte de seguridad de Drupal 10. Una versión .0 en la semana en que caduca tu versión actual no es un plan. Drupal 11.4 sigue recibiendo correcciones de seguridad después de esa semana, y la 11.5 se publica junto con la 12.0. Pasa ya a la 11 y mira la 12 el año que viene.

Umbraco 13: termina el 14 de diciembre de 2026

Qué se acaba

Umbraco 13 es una versión de soporte a largo plazo. Según la página del ciclo de vida del soporte de Umbraco, está en su fase de seguridad (solo correcciones de seguridad) desde el 14 de diciembre de 2025, y llega al fin de su vida el 14 de diciembre de 2026, tras lo cual Umbraco dice que «ya no se recomienda».

Por debajo hay una segunda fecha. Umbraco 13 funciona sobre .NET 8, y Microsoft termina el soporte de .NET 8 el 10 de noviembre de 2026. El entorno de ejecución del que depende tu sitio se queda sin soporte un mes antes que el CMS.

Qué implica la actualización

La regla de Umbraco es pasar a la versión de soporte a largo plazo más cercana antes que a la última. Umbraco 13 es a su vez una versión LTS, así que el destino es Umbraco 17, la siguiente LTS. Se publicó el 27 de noviembre de 2025, entra en su fase de seguridad el 27 de noviembre de 2027 y llega al fin de su vida el 27 de noviembre de 2028. Funciona sobre .NET 10.

El paso difícil está en medio. Umbraco 14 sustituyó por completo la interfaz de edición, y las notas de actualización específicas de cada versión lo resumen en una línea: «Se elimina AngularJS: un nuevo backoffice construido con Web Components y Lit, e impulsado por la Umbraco UI Library».

En la práctica, eso significa:

• Toda personalización del backoffice se reescribe. Los editores de propiedades a medida, los paneles, las secciones propias y las partes de interfaz de los paquetes eran AngularJS en Umbraco 13. Nada de eso se conserva; se reconstruye como web components.
• Los editores de propiedades se dividen en dos, una parte de servidor y una parte de cliente, lo que cambia cómo se estructuran los que son a medida.
• Algunos editores desaparecen. Nested Content, el diseño Grid y el antiguo Media Picker se han eliminado. Umbraco recomienda Block List o Block Grid en su lugar. Esto es un trabajo de contenidos además de un trabajo de código: las páginas construidas con esos editores necesitan que se convierta el contenido que tienen guardado.
• Se eliminan las macros. Umbraco remite a vistas parciales o a bloques en el editor de texto enriquecido.
• Se elimina XPath, con Dynamic Roots entre sus sustitutos.
• Los paquetes necesitan una versión para Umbraco 17. Un paquete abandonado significa un sustituto o una reescritura.

La recomendación de Umbraco es actualizar sin conexión, probar a fondo y después ejecutar la actualización en cada entorno. Mete pronto a tus editores en las pruebas: el backoffice que usan a diario tendrá otro aspecto y se comportará de otra manera.

Las plantillas públicas suelen cambiar menos que el backoffice, salvo donde muestran Nested Content, Grid o macros. Buscar esos tres elementos en tus vistas es una primera medida rápida del trabajo.

Ganar tiempo: XLTS

Umbraco vende soporte a largo plazo extendido (XLTS) para las versiones LTS a partir de Umbraco 10, la 13 incluida. Eliges 6, 12 o 24 meses, y la cobertura empieza el día siguiente al fin de vida. Cubre solo parches de seguridad, con un conjunto de funcionalidades congelado. Se compra a Umbraco (los partners lo gestionan a través de su partner manager), y la página no publica ningún precio.

XLTS tiene sentido cuando la reescritura de los editores a medida no puede terminarse bien antes del 14 de diciembre. Tiene menos sentido como forma de aplazar la decisión, porque la reescritura cuesta lo mismo el año que viene. Y parchea Umbraco, no el entorno de ejecución: el soporte de .NET 8 termina igualmente.

Kentico Xperience 13: termina el 1 de enero de 2027

Qué se acaba

Kentico 13 ya está en soporte reducido. A lo largo de 2026, Kentico publica versiones «solo en forma de hotfixes de seguridad». Después, según el ciclo de vida del soporte de Kentico: «A partir del 1 de enero de 2027, cesaremos todo soporte, mantenimiento, actualización, versión, hotfix, parche, reparación (incluidas las reparaciones de seguridad) y cualquier otro servicio relacionado con Kentico Xperience 13».

No figura ninguna prórroga. El sucesor es Xperience by Kentico, que Kentico ofrece «en condiciones acordadas mutuamente». Es una nueva conversación sobre licencias, no un cambio de versión.

Qué implica el traslado

Xperience by Kentico es un producto distinto, y la Kentico Migration Tool es sincera sobre sus límites: «La herramienta migra solo los modelos de datos y los contenidos. La migración de código no está soportada».

Lo que traslada, según su documentación:

• Los tipos de página pasan a ser tipos de contenido. Las páginas pasan a ser páginas de canal web o elementos de contenido reutilizables.
• Las categorías pasan a ser taxonomías.
• Las bibliotecas multimedia y sus ficheros, el contenido de Page Builder y las plantillas de página a medida (desde Kentico 13).
• Los usuarios y roles de edición, los contactos y las actividades, y los consentimientos.
• Las clases de módulos a medida con sus datos, y las tablas a medida (como clases de módulo o elementos de contenido).

Lo que no traslada:

• El código y las personalizaciones. Controladores, vistas, código de widgets, integraciones y tareas programadas. El código que recupera las páginas tiene que reescribirse para los elementos de contenido.
• Las respuestas automáticas y los correos de notificación de los formularios. Se copian a mano.
• La automatización de marketing y los grupos de contactos estáticos.
• Las macros, que no funcionarán después de la migración, y los permisos de página.
• Los ficheros multimedia guardados en Azure Blob Storage o Amazon S3. La herramienta solo lee los ficheros multimedia del sistema de ficheros local.

Dos apuntes prácticos. El origen tiene que estar en Kentico 13 Refresh 5 (hotfix 13.0.64) o posterior, así que compruébalo primero. Y la migración puede ejecutarse varias veces, con transformaciones de datos integradas y a medida, así que puedes ensayarla y afinar el mapeo antes del paso definitivo.

Dicho claramente: el contenido sobrevive, y el sitio web que lo rodea se reconstruye. Es un proyecto de meses, y el 3 de octubre quedan trece semanas hasta el 1 de enero. La mayoría de los sitios en Kentico 13 funcionarán sin parches durante un tiempo. Mejor planificar ese periodo que descubrirlo.

Como el código se reconstruye en cualquier caso, es razonable preguntarse si encaja mejor Xperience by Kentico u otra plataforma. Quedarse tiene una ventaja clara: una herramienta de migración pensada para tu modelo de contenidos. Que sea una decisión, no una inercia.

Qué significa realmente funcionar sin parches

El sitio sigue funcionando. El riesgo cambia de forma:

• La próxima vulnerabilidad se queda abierta. Las correcciones se siguen publicando para las versiones con soporte, y sus avisos son públicos. Cuando un fallo corregido en una versión más reciente también existe en la tuya, el aviso les indica a los atacantes dónde mirar.
• La pila envejece alrededor del CMS. PHP 8.2 pierde el soporte de seguridad el 31 de diciembre de 2026. .NET 8 pierde el soporte el 10 de noviembre de 2026. Es probable que los módulos contribuidos y los paquetes dejen de probarse contra versiones que nadie soporta.
• Cambia la respuesta en las auditorías. Si tu política de seguridad, un cuestionario de un ciberseguro o un contrato con el sector público pregunta si tu software tiene soporte, la respuesta honesta pasa a ser no.

Si tienes que funcionar sin parches durante un tiempo, reduce la exposición: pon la interfaz de administración detrás de una VPN o de una lista de IP permitidas, elimina los módulos que no se usan, añade un cortafuegos de aplicaciones web, prueba tus copias de seguridad y lee los avisos del fabricante sobre la versión más reciente. Estas medidas reducen el riesgo. No sustituyen a los parches.

Cómo decidir

• Drupal 10, sobre todo con módulos contribuidos: actualiza a Drupal 11. Diez semanas bastan si empiezas este mes.
• Drupal 10 con mucho código a medida o un alojamiento con PHP antiguo: arregla primero el alojamiento y después porta el código. Si te vas a pasar de fecha, planifica una ventana corta sin parches con el refuerzo de seguridad descrito arriba.
• Umbraco 13 con pocas personalizaciones del backoffice: actualiza a Umbraco 17.
• Umbraco 13 con editores a medida, Nested Content o Grid: contrata XLTS para 6 o 12 meses y haz bien la reescritura.
• Kentico 13: empieza ya el proyecto de migración, refuerza la seguridad del sitio actual para enero y decide el destino por sus méritos.
• Ya tocaba un rediseño: deja que el fin de vida sea el detonante, y no portes código que vas a tirar. Si se van a reconstruir las plantillas, es también el momento más barato para arreglar la accesibilidad; nuestra guía del Acta Europea de Accesibilidad explica qué significa para un sitio web.

Un calendario desde hoy

Antes de mediados de octubre. Haz el inventario de cada sitio: versión exacta del CMS, versión de PHP o de .NET, módulos, editores y widgets a medida, y compatibilidad de cada módulo contribuido o paquete. En Drupal, ejecuta Upgrade Status. En Kentico, confirma que estás en el hotfix 13.0.64 o posterior.

Antes de que acabe octubre. Decide por sitio: actualizar, ganar tiempo o reconstruir. Si necesitas XLTS, empieza la compra, porque la cobertura arranca el día siguiente al fin de vida.

Noviembre. Drupal: pasa el alojamiento a PHP 8.3, actualiza en preproducción y prueba. Umbraco: pasa a .NET 10, actualiza una copia, reescribe los editores a medida y convierte el contenido de Nested Content y Grid. Kentico: aplica las medidas de refuerzo y haz un primer ensayo de migración.

De finales de noviembre a principios de diciembre. Actualizaciones en producción, con margen antes del 9 y del 14 de diciembre. Si tu organización congela los cambios antes de las fiestas, planifica teniéndolo en cuenta.

Enero de 2027. Los sitios en Kentico funcionan con la seguridad reforzada mientras continúa la migración.

Dónde conseguir ayuda

Hacemos este tipo de trabajo: auditar qué hay a medida en un sitio heredado, portar módulos de Drupal, reescribir extensiones del backoffice de Umbraco como web components y reconstruir el código que deja atrás una herramienta de migración. Ese trabajo se enmarca en nuestro servicio de mantenimiento de sistemas heredados; si hay una reconstrucción sobre la mesa, nuestro servicio de corrección de accesibilidad web cubre esa parte.

Si una de estas fechas es la tuya y no tienes claro qué hay bajo el capó, escribe a office@c9group.dev.