El sistema de pedidos salió a producción a comienzos de 2024. Está hecho en .NET 8, con un frontend en Angular, y funciona bien: nadie reclama y la última factura del proveedor fue la del cierre de la garantía. El 10 de noviembre de 2026, .NET 8 dejó de recibir parches de seguridad de Microsoft. En la empresa nadie se enteró, porque no era tarea de nadie enterarse.
El desarrollo de software a medida no termina el día de la entrega. Ese día empieza otra etapa, más larga y bastante menos visible, en la que el sistema necesita correcciones, ajustes a lo que cambia en el negocio, actualizaciones de sus componentes y alguien que lo vigile. De eso trata este artículo: los tipos de mantenimiento de software, lo que vence aunque nadie toque el código y cómo presupuestar el soporte de software a medida año a año. Lo que cuesta construirlo ya lo vimos en qué explica el costo de una aplicación a medida. Acá partimos desde la puesta en producción.
La garantía no es mantenimiento
Casi todos los contratos de desarrollo incluyen un período de garantía después de la entrega. Durante ese plazo el proveedor corrige sin costo los defectos, entendidos como lo que no funciona según los criterios de aceptación acordados.
Lo que la garantía normalmente no cubre:
- Funcionalidades nuevas o cambios en las reglas de negocio.
- Subir de versión el framework, las librerías o el runtime.
- Fallas provocadas por cambios en sistemas externos, como el ERP o la API de un banco.
- La operación: hosting, respaldos, monitoreo, renovación de certificados.
Mira en tu contrato cuándo vence la garantía y qué pasa al día siguiente. Si no dice nada, lo habitual es que cada solicitud posterior se cotice por separado, y eso termina siendo más lento y más caro que un acuerdo anual. Lo que deberías haber recibido al cierre del proyecto (código fuente, documentación, accesos) está en etapas y entregables del desarrollo de software. Sin eso, mantener el sistema se vuelve difícil para cualquiera, incluido el proveedor original.
Cuatro tipos de mantenimiento de software
No todo el mantenimiento es "arreglar lo que se cae". Conviene separarlo en cuatro tipos, porque cada uno se presupuesta distinto.
| Tipo | Qué es | Ejemplo | Cómo se presupuesta |
|---|---|---|---|
| Correctivo | Arreglar errores que aparecen en producción | Un informe que suma mal cuando hay notas de crédito | Bolsa de horas con tiempos de respuesta acordados |
| Adaptativo | Ajustar el sistema a cambios del entorno | El banco cambia el formato del archivo de pagos | Bolsa de horas; difícil de prever |
| Evolutivo | Funcionalidades nuevas que pide el negocio | Agregar un flujo de aprobación de descuentos | Backlog priorizado con presupuesto anual |
| Preventivo | Actualizar dependencias y pagar deuda técnica | Migrar de .NET 8 a .NET 10 | Plan anual fijo |
El preventivo es el que más se posterga, porque no se ve. Pero es el que evita que los otros tres se encarezcan: un sistema al día se corrige y se modifica más rápido que uno con tres versiones de atraso.
Lo que vence aunque nadie toque el código
Los frameworks y runtimes sobre los que está construido tu sistema tienen calendario propio. Algunos ejemplos, con las fechas publicadas por cada proyecto:
- .NET. Según la política de soporte de Microsoft, las versiones LTS tienen soporte por al menos tres años y las STS por 24 meses. .NET 8 y .NET 9 dejaron de tener soporte el 10 de noviembre de 2026; .NET 10 lo tiene hasta noviembre de 2028. Los parches salen mensualmente y los de seguridad, el segundo martes de cada mes.
- Angular. Desde la versión 22 publica una versión mayor cada 12 meses (antes eran seis). Cada una tiene 24 meses de soporte: 12 activos y 12 de LTS, en los que solo recibe correcciones críticas y de seguridad. Angular 20 sale de LTS el 28 de noviembre de 2026. Ojo con un detalle:
ng updatesube una versión mayor a la vez, así que si te saltaste tres, son tres migraciones. - Node.js. El proyecto recomienda usar en producción solo versiones LTS, que reciben correcciones críticas por unos 30 meses en total. Node.js 20 ya está en fin de vida desde marzo de 2026.
A eso súmale las librerías de npm o NuGet, las imágenes base de Docker, los certificados TLS y las APIs de terceros que el sistema consume. Cada una cambia a su ritmo.
Un sistema fuera de soporte sigue funcionando al día siguiente. El problema llega cuando se publica una vulnerabilidad y nadie saca un parche para tu versión. Ahí, una actualización que habría tomado una tarde se convierte en un proyecto con cotización, plazo y pruebas de regresión.
Operación: hosting, monitoreo y respaldos
Además del código, alguien tiene que hacerse cargo de que el sistema esté arriba. Estas son las preguntas que conviene tener respondidas por escrito:
- ¿A nombre de quién está la suscripción de hosting y quién tiene acceso de administrador? Lo ideal es que sea tu empresa, con el proveedor como usuario invitado.
- ¿Quién recibe las alertas si el sistema se cae un domingo, y en cuánto tiempo responde?
- ¿Con qué frecuencia se respalda, cuánto tiempo se guardan los respaldos y cuándo fue la última vez que alguien probó restaurar uno? Un respaldo que nunca se restauró es una suposición.
- ¿Quién entra a producción y queda registro de lo que hace?
- ¿Dónde está el repositorio del código? Si está en la cuenta del proveedor, cámbialo.
Si el sistema trata datos personales de clientes o trabajadores, esto también es un tema legal. La Ley 21.719 incluye el deber de adoptar medidas de seguridad y de reportar vulneraciones. Su entrada en vigencia sigue fijada para el 1 de diciembre de 2026. El 28 de octubre el Senado aprobó un proyecto que la mueve al 15 de octubre de 2027, y a comienzos de noviembre la Comisión de Constitución de la Cámara lo aprobó en general y lo envió a Hacienda. Mientras no se publique, la fecha no cambia. Con una u otra fecha, un sistema sin parches es difícil de defender como "medida de seguridad".
Cómo presupuestar el soporte de software a medida
Hay quien usa un porcentaje del costo de desarrollo como regla rápida. Sirve para abrir la conversación, pero el número real depende de cuántos componentes tiene el sistema, cuántas integraciones y cuánto quieres que siga cambiando. Un orden que funciona:
- Haz un inventario de componentes con su versión y fecha de fin de soporte. Una planilla basta.
- Arma un calendario de actualizaciones a partir de esas fechas. Por ejemplo: Angular una vez al año, .NET al salir cada LTS.
- Separa los costos fijos (hosting, monitoreo, horas de mantenimiento preventivo) de los variables (correctivo y adaptativo).
- Para lo variable, acuerda una bolsa mensual de horas con tiempos de respuesta por severidad. Define qué pasa con las horas que no se usan.
- Deja el evolutivo en un presupuesto aparte, como backlog priorizado. Si se mezcla con el correctivo, las urgencias se comen las mejoras.
- Una vez al año, revisa horas consumidas, incidentes y deuda técnica, y ajusta.
Un contrato de soporte que sirva debería dejar claro el alcance, los tiempos de respuesta, la ventana de mantenimiento, si las actualizaciones de versión están incluidas y a quién pertenecen el código y las cuentas.
Preguntas frecuentes
¿Cuánto dura la garantía de un software a medida?
No hay un plazo estándar; depende de lo que firmes. Más que la duración, revisa qué cubre (defectos contra los criterios de aceptación) y qué pasa cuando vence.
¿Puedo dejar el sistema sin actualizar si funciona bien?
Puedes, pero corre sin parches de seguridad, y cada año que pasa la actualización sale más cara. En Angular, por ejemplo, hay que subir una versión mayor a la vez.
¿El mantenimiento tiene que hacerlo quien desarrolló el sistema?
No. Con el código, la documentación y los accesos, otro equipo puede tomarlo. Quien lo construyó suele conocerlo mejor, pero lo importante es que el código y las cuentas estén a nombre de tu empresa.
Piensa en el después antes de partir
En Disrupsoft diseñamos y desarrollamos aplicaciones web y móviles a medida con Angular, Node.js, Azure y Power Platform, y trabajamos en comunicación constante con tu equipo durante todo el proyecto. Si estás por arrancar un desarrollo y quieres dejar resuelto desde el primer día cómo se va a mantener, conversemos sobre tu proyecto de desarrollo de software a medida.
