El 11 de septiembre de 2026 empieza a aplicarse el artículo 14 del Reglamento (UE) 2024/2847. Desde esa fecha, quien pone en el mercado europeo un producto con elementos digitales tiene 24 horas para el primer aviso de una vulnerabilidad explotada activamente, 72 para la notificación completa y 14 días para el informe final. El reloj corre igual si el fallo está en tu código que si está en un plugin de marketplace que alguien instaló en 2023 y nadie ha vuelto a mirar.

Esa es la discusión real detrás de «CMS o backend a medida». No es velocidad de desarrollo. Es quién decide la fecha del parche.

Lo que un CMS te ahorra, que no es poco

Conviene empezar por lo honesto: October CMS es un producto mantenido y con tracción. La v4.0 saltó a Laravel 12 y elevó el mínimo a PHP 8.2, la v4.1 extrajo su capa AJAX como paquete MIT independiente y la v4.2 migró el panel a Vue 3 y ES Modules nativos. Panel de administración, permisos por rol, gestor de medios, CRUD generado, migraciones. Entre tres y seis meses de trabajo que no facturas a nadie.

Para un sitio corporativo donde cuatro editores no técnicos publican contenido a diario, montar eso desde cero en C# es quemar presupuesto por gusto.

El problema aparece cuando el «sitio» deja de ser un sitio. Cuando aparecen colas, integraciones salientes con SAP o con un ERP sanitario, una API que consumen terceros, retenciones de datos con plazo legal y un auditor que pide evidencias. A partir de ahí ya no usas el CMS: peleas contra él.

El calendario lo firma otro

Dos casillas de esa tabla merecen atención. La primera: PHP 8.2, el mínimo de October 4, sale de soporte el 31 de diciembre de 2026. Cualquier CVE publicado después no tendrá parche oficial para esa rama. La segunda: la licencia de October es perpetua para ejecutar, no para actualizar. Puedes seguir sirviendo el sitio indefinidamente con la licencia caducada. Lo que no puedes es actualizar plataforma ni plugins.

Traducido al lenguaje de un auditor: op.exp.4 del Anexo II del ENS exige mantenimiento y actualizaciones de seguridad con evidencias. Una licencia expirada convierte esa medida en un hallazgo, y el hallazgo no lo arregla el proveedor. Lo arreglas tú, con tarjeta.

Lo que acabas declarando

October publica sus avisos en el GitHub Advisory Database y parchea con rapidez razonable. No es ese el problema. El problema es de quién es el reloj.

Un backend en .NET con veinte paquetes NuGet aprobados tiene veinte líneas de SBOM que puedes justificar en una revisión. Un October medio en producción arrastra el núcleo, los módulos y una cola de plugins de marketplace con mantenedores heterogéneos, algunos activos y otros no. Cuando el CRA te pide notificar en 24 horas, la pregunta operativa no es «¿tengo el parche?», sino «¿sé qué versión de qué componente estoy sirviendo, y existe alguien obligado a publicar el arreglo?».

En un despliegue aislado la asimetría se agranda. Un binario compilado con Native AOT arranca sin runtime instalado y sin JIT, lo que permite entregarlo en entornos donde la compilación dinámica está prohibida. Un October air-gapped exige replicar el gateway de actualizaciones y un mirror de Composer, o quedarse congelado. Congelado es exactamente lo que un ENS de Categoría Alta no perdona.

Dónde paga C#, y dónde no

En rendimiento bruto la diferencia no es opinable. En la prueba Fortunes de la Round 23 de TechEmpower, la que mezcla lectura de base de datos, ordenación y renderizado, ASP.NET Core encabeza la tabla con unas 610.000 peticiones por segundo frente a unas 16.800 de Laravel. Es un banco de pruebas sintético y hay que leerlo como tal, pero el factor está entre 30 y 40. Eso se traduce en máquinas: la misma carga con menos hierro, y menos hierro es menos superficie que endurecer y menos licencias que auditar.

Lo que rinde más a los tres años, sin embargo, es el sistema de tipos. Nullable reference types, records, análisis estático en compilación y un mismo lenguaje para la API, los tests y los jobs. Los errores que en PHP aparecen en producción a las 03:40 aquí aparecen en el build.

Ahora el contrapeso, porque existe. Un backend .NET escrito con desgana por un equipo que lleva ocho años haciendo PHP rinde peor que un October bien mantenido. El coste de arranque es real: semanas hasta el primer CRUD frente a días. Y si el requisito de verdad es que marketing publique landings sin abrir un ticket, la respuesta correcta es un CMS, con .NET detrás solo para lo que sea backend de verdad.

Criterios medibles antes de decidir

• Vida útil esperada del sistema. Por encima de cinco años, un runtime LTS con ventana de tres años pesa más que el ahorro inicial.
• Requisito de despliegue aislado o on-premise. Si existe, la cadena de actualización del CMS es un punto único de fallo.
• Número de integraciones salientes. Más de tres sistemas externos y el CMS pasa de acelerador a intermediario.
• Sujeción a CRA, NIS2 o ENS Categoría Media/Alta. Determina si necesitas SBOM defendible y plazos de parche propios.
• Perfil del equipo que lo mantendrá. No el que lo construye: el que estará de guardia en 2029.
• Quién publica contenido y con qué frecuencia. Si son editores no técnicos y a diario, el CMS gana la discusión.

El Imperativo Estratégico

La decisión de stack no se toma el día del kick-off. Se paga en 2028, cuando alguien pregunta por qué el sistema sigue sobre una rama de PHP sin soporte y la respuesta es que actualizar exige tocar catorce plugins de terceros.

Antes de reescribir nada, conviene medir lo que ya hay: inventario real de dependencias, SBOM, versiones fuera de soporte, plazos de parche comprometidos y qué parte de la cadena de actualización depende de un proveedor externo. En Pumpún Dixital hacemos esa auditoría sobre sistemas en producción y entregamos el resultado como un plan con fechas y coste, no como un informe de riesgos genérico. Si en septiembre te toca notificar en 24 horas, más vale saber hoy qué estás sirviendo exactamente.