Virgencita, virgencita, que me quede como estoy: la partida que falta en tu presupuesto 2027

Escrito por
Julio PrietoCEO
Publicado
11 min de lectura
Etiquetas
Estrategia

Mantener una web no es un gasto prescindible, es el precio de seguir teniendo la web que ya pagaste. Estas son las partidas que deberían estar en tu presupuesto de 2027, las que suelen salir como «no hacer nada» y que salga el sol por Antequera.

Una persona pequeña, vista de espaldas, mira el motor de un coche suspendido de una grúa en una gran nave luminosa; el coche, con la carrocería intacta y el capó abierto, está debajo, y al fondo se ve una ciudad tras una barrera bajada.
Mantener una web es como mantener un coche: revisiones, de vez en cuando un motor nuevo y unas normas de circulación que cambian. Ilustración generada con IA

Estas semanas se cierran muchos presupuestos digitales para 2027, y en casi todos falta la misma partida. No aparece en ninguna hoja de cálculo y, aun así, muchas organizaciones la van a pagar. Se llama «no hacer nada» con la web. Nadie te va a facturar por dejar la web como está. Lo pagas más tarde, de golpe, y casi siempre cuando peor te viene. Así que un presupuesto que mete el mantenimiento como línea opcional, de esas que caen en la segunda ronda de recortes, no ha ahorrado nada: ha decidido pagar después y sin elegir cuándo hacerlo.

Para aquellos que nos leéis sin perfil técnico, lo que mejor funciona para explicarlo es lo que pasa con tu coche. Tienes uno que va bien, con el que estás a gusto, con la carrocería impecable. Nadie te discute que es un buen coche. La cuestión es cómo está el motor, qué le pasa en las revisiones y qué pasa con las normas de la ciudad por la que circula. Esas tres cosas son las que generalmente afectan a nuestro presupuesto, y ninguna depende de que el coche «funcione».

Las revisiones del mecánico, o lo que cuesta que no haya ninguna sorpresa

Lo primero es quitarse de la cabeza la revisión anual. En software no existe. Los avisos de seguridad de los módulos del CMS Drupal salen cada miércoles, y los del núcleo tienen su ventana el tercer miércoles de cada mes; cualquier plataforma seria lleva una cadencia parecida. Mantener una web es leer esos avisos, decidir cuáles te afectan, aplicar el parche, comprobar que no se ha roto nada y tener una copia de seguridad de la que de verdad se pueda restaurar, no una que existe en teoría y nadie ha probado. Es un ritmo. Como el cambio de aceite, la revisión de los frenos y de los neumáticos: cuesta poco cada vez (por regla general, si no hay un gran desgaste) y no se nota cuando se hace bien.

Y ahí está la trampa, claro. Justo porque no se nota es la primera candidata al recorte. Dejar de hacerla tampoco se nota. Hasta que se nota.

Un presupuesto que mete el mantenimiento como línea opcional, de esas que caen en la segunda ronda de recortes, no ha ahorrado nada: ha decidido pagar después y sin elegir cuándo hacerlo.

El fabricante deja de reparar el motor (y además, publica los defectos)

Aquí la analogía se queda corta, y vale la pena saber exactamente dónde. Un motor viejo se desgasta: hace ruidos, consume más, un día te deja tirado en la Ronda o en la M-30 o donde quiera que pases tus momentos memorables de atasco matutino. El software no se desgasta. Drupal 10 llega a su fin de vida el 9 de diciembre de 2026, la misma semana en que sale Drupal 12, y una web en Drupal 10 funcionará el 10 de diciembre exactamente igual que el 8. PHP 8.2, el lenguaje sobre el que corren Drupal y buena parte de la web, deja de recibir parches de seguridad el 31 de diciembre. El 1 de enero tampoco notarás nada, seguirá funcionando.

Lo que cambia es otra cosa. A partir de esas fechas, cada fallo de seguridad que aparezca se corrige en las versiones nuevas y se publica. Los avisos de seguridad son públicos por diseño: cuando el equipo de seguridad de Drupal publica una corrección para Drupal 11, cualquiera puede leerla y deducir que una web en Drupal 10 tiene el mismo fallo sin corregir. Y así cada miércoles. Llevado al coche: el fabricante no ha dejado de fabricar tu motor; ha dejado de enviarte la pieza que impide arrancarlo sin llave, y cada semana publica la lista de las diferentes maneras de hacerlo. Ups.

Por eso el coste de no hacer nada no crece en línea recta. Durante meses no pasa nada y parece gratis. Luego cada aviso se suma al anterior, y al anterior, hasta que un incidente, una auditoría o un requerimiento obligan a hacer en tres semanas, con prisa y sin margen para negociar, lo que se podía haber planificado en seis o en doce meses. La factura final suma la actualización que se aplazó, el incidente que la precipitó y las horas de todo el que tuvo que dejar lo suyo para apagar el fuego. Esa es la partida que no estaba en la hoja de cálculo.

Cambiar el motor sin cambiar el coche (seguimos hablando de webs)

La buena noticia es que nadie te obliga a cambiar de coche. Pasar de Drupal 10 a Drupal 11 es cambiar el motor y conservar todo lo demás: diseño, contenidos, estructura, integraciones y el trabajo de los editores. El coche sigue siendo el tuyo.

Lo que sí hay que presupuestar son las adaptaciones, porque el motor nuevo trae piezas que el coche viejo no conocía. Módulos que necesitan su versión compatible, código propio que usaba funciones ya retiradas, una versión de PHP más reciente, alguna pieza del front que hay que ajustar. Eso es lo que cuesta que un motor de 2026 encaje en una carrocería de 2022, y el taller no se lo ha inventado. A cambio, hay una ventaja que casi nadie pone en la balanza cuando elige plataforma: Drupal publica una versión mayor cada dos años y una menor cada seis meses, con fechas conocidas con años de antelación, y cada versión mayor vive de media unos cuatro años. Drupal 10 salió en diciembre de 2022 y se retira en diciembre de 2026: durante todo ese tiempo el motor se revisa, no se cambia. Un calendario predecible es lo que permite presupuestar en vez de reaccionar.

Si tu web está en Drupal 10, esto te toca antes del 9 de diciembre. Cambiar de versión no es rehacer la web, pero tampoco es un clic: cuenta con una revisión de módulos y de código propio, una ventana de pruebas y un despliegue con vuelta atrás preparada. Si te lo venden como un rediseño, te están vendiendo un coche que no necesitas. Si te lo venden como una tarde de trabajo, no han abierto el capó.

Adonde vamos sí hacen falta carreteras (sí, todavía va de webs)

La segunda razón por la que el coche se queda corto es que pone todo el peso en la mecánica, y la mitad de la factura de 2027 no viene del motor sino del entorno. Quien vive en Barcelona o en Madrid lo entiende sin explicación: un coche puede ir perfectamente, pasar la ITV y lucir una carrocería impecable y, si no tiene etiqueta ambiental, no puede entrar en la Zona de Bajas Emisiones de lunes a viernes de 7 a 20 horas. No se ha estropeado nada. Han cambiado las normas sobre dónde puede circular, y las normas no las decidió el taller.

Con la web pasa lo mismo, y el calendario viene cargado. La ley europea de accesibilidad se aplica desde el 28 de junio de 2025, y lo que exige no se cumple una vez: cada versión nueva de la web puede romper lo que la anterior hacía bien, así que la accesibilidad hay que revisarla en cada entrega. El Reglamento de Ciberresiliencia obliga desde el 11 de septiembre de 2026 a notificar en 24 horas las vulnerabilidades explotadas de los productos con elementos digitales, con lo que «quién se entera y quién avisa» pasa a ser una pregunta con respuesta obligatoria. La directiva NIS2 sigue sin transponerse en España, hasta el punto de que la Comisión Europea llevó al país ante el Tribunal de Justicia de la UE el 8 de julio de 2026; la responsabilidad ante un incidente, en cambio, existe aunque la ley nacional no exista. Y el 12 de enero de 2027 el Reglamento de Datos prohíbe a los proveedores de nube cobrar por cambiar de proveedor. Una línea que baja, para variar, y que vale la pena anotar antes de renovar un contrato de hosting a tres años.

Ninguna de esas fechas pregunta si tu web funciona. Preguntan por dónde puede circular.

Cuándo compensa cambiar de coche (exacto, ¡de web!)

Y ahora lo que una agencia que gestiona mantenimientos tiene la obligación de decir, porque mantener no siempre es la respuesta. Suele haber tres señales de que rehacer sale más barato que seguir:

  • La primera es que el chasis no admite el motor nuevo: la web está en una versión sin ruta de actualización, como las que todavía siguen en Drupal 7 casi dos años después de su fin de vida, y cada parche es artesanía.
  • La segunda es que ya llevas tres motores cambiados. Cada actualización ha costado más que la anterior porque la deuda acumulada (código propio sin documentar, módulos abandonados, parches encima de parches) convierte cualquier cambio en una excavación.
  • La tercera no es técnica: la organización ha cambiado y lo que la web tiene que hacer ya no es lo que hace.

En los tres casos, seguir manteniendo es pagar por conservar algo que ya no sirve, y la decisión correcta es la que menos gusta a quien cobra el mantenimiento. Nosotros incluidos.

El modelo en seis líneas (por tus webs)

Si tienes que defender el presupuesto digital de 2027 delante de quien firma, estas son las líneas que deberían aparecer, cada una con su pregunta de control.

Las seis líneas de una web que no puede fallar

Cada línea tiene un coste conocido; la que falta es la que se paga sin elegir.

01Revisiones

Parches de seguridad, dependencias, pruebas y copias restaurables, a ritmo semanal o mensual. ¿Quién lee los avisos y en cuánto tiempo se aplican?

02Actualizaciones mayores

Una cada cuatro años en Drupal si se hace al poco de salir la versión nueva, con fecha conocida. ¿Cuándo toca la siguiente y qué adaptaciones arrastra?

03Deuda

Lo que cada actualización encarece porque la anterior no se hizo bien. ¿Qué parte del código propio está documentada y qué módulos están abandonados?

04Cumplimiento por entrega

Accesibilidad verificada en cada versión, registro de cambios, quién notifica un incidente y en cuánto tiempo. ¿Qué norma nueva nos afecta en 2027 y en qué fecha?

05Fin de vida

Las fechas en que el fabricante deja de corregir: plataforma, lenguaje, base de datos, servidor. ¿Cuál es la más cercana y qué plan hay para ella?

06Salida

Lo que cuesta cambiar de proveedor, de hosting o de plataforma si hace falta. ¿Tenemos el código, los datos, los accesos y la documentación para irnos mañana?

Si las seis líneas llevan una cifra y un nombre al lado, tienes un presupuesto adulto. Si alguna está en blanco, la partida de «no hacer nada» ya está dentro y, bueno, manda webs.

Fuentes

  • Drupal Association, Drupal core release schedule, drupal.org, 2026 — Drupal 10.0.0 publicado el 15 de diciembre de 2022 y fin de vida el 9 de diciembre de 2026, Drupal 12 la semana del 7 de diciembre, cadencia de versiones y ventanas de seguridad.
  • The PHP Group, Supported versions, php.net, 2026 — fin del soporte de seguridad de PHP 8.2 el 31 de diciembre de 2026.
  • Unión Europea, Directiva (UE) 2019/882 (Ley Europea de Accesibilidad), 2019 — aplicable desde el 28 de junio de 2025.
  • Unión Europea, Reglamento (UE) 2024/2847 (Reglamento de Ciberresiliencia), 2024 — obligaciones de notificación del artículo 14 desde el 11 de septiembre de 2026.
  • Comisión Europea, remisión de España al Tribunal de Justicia de la UE por la no transposición de la directiva NIS2, 8 de julio de 2026.
  • Unión Europea, Reglamento (UE) 2023/2854 (Reglamento de Datos), artículo 29 — prohibición de los costes de cambio de proveedor de nube desde el 12 de enero de 2027.
  • Ajuntament de Barcelona, normativa de la Zona de Bajas Emisiones Rondes de Barcelona — restricción a vehículos sin etiqueta ambiental de lunes a viernes de 7 a 20 horas, vigente desde 2020.

¿Hablamos de tu contenido?

Hablemos

En Digital Bakers escribimos así: con criterio humano delante y la tecnología detrás, empujando.