Contrato de mantenimiento de software: qué debe incluir

Todo el mundo firma un contrato de mantenimiento de software con la misma expectativa vaga: «que si se rompe algo, alguien lo arregle». Y casi todos los conflictos entre cliente y proveedor nacen exactamente ahí, en ese «algo» sin definir. El cliente cree haber comprado tranquilidad ilimitada; el proveedor cree haber vendido un número acotado de horas. Los dos tienen razón, porque el papel que firmaron no decidía nada.

Un contrato de mantenimiento bien escrito no es un trámite legal: es el documento técnico que decide cuánto tarda en volver a funcionar tu plataforma un martes a las nueve de la mañana, quién paga la actualización de PHP del año que viene y qué pasa con tus credenciales el día que decidas cambiar de proveedor. Es, en la práctica, la política de continuidad de tu negocio digital escrita en lenguaje contractual.

En Keliam llevamos años entrando en plataformas mantenidas por terceros —y heredando las consecuencias de contratos redactados a ojo—. Este artículo recoge lo que hemos visto que funciona: qué cláusulas importan de verdad, cómo se define un alcance que no explota al tercer mes, cómo se escriben unos niveles de servicio que se puedan cumplir y medir, qué modelos de precio existen y en qué casos conviene cada uno. Sirve tanto si vas a firmar como cliente como si estás preparando tu propia propuesta de mantenimiento.

1. Qué es (y qué no es) el mantenimiento de software

La primera confusión es de vocabulario. Para mucha gente «mantenimiento» significa corregir errores, y punto. La norma ISO/IEC 14764 —la referencia clásica en mantenimiento de software— lleva décadas diciendo otra cosa: el mantenimiento es todo el trabajo que se hace sobre un sistema después de su puesta en producción, y se divide en cuatro tipos bien distintos.

1.1 Los cuatro tipos de mantenimiento

Correctivo. Arreglar lo que está mal: bugs, errores de cálculo, procesos que fallan. Es el único que la mayoría de la gente tiene en la cabeza al firmar, y suele ser la menor parte del esfuerzo real.

Adaptativo. Cambiar el software porque ha cambiado su entorno, no porque estuviera roto. Una nueva versión de PHP, un cambio en la API de la pasarela de pago, un navegador que retira el soporte de una función, una normativa nueva. Nadie lo pide y nadie lo ve, pero si no se hace, el sistema se muere lentamente.

Perfectivo. Mejoras sobre algo que ya funciona: rendimiento, usabilidad, nuevas funciones pequeñas. Aquí es donde más discusiones hay, porque la frontera con «proyecto nuevo» es difusa y conviene dibujarla en el contrato.

Preventivo. Trabajo hecho hoy para que no haya incidencia mañana: parcheo, actualización de dependencias, pruebas de restauración de copias, limpieza de deuda técnica acumulada, revisión de logs. Es la partida que más se recorta al negociar y la que más caro sale haber recortado.

1.2 Por qué importa la distinción

Porque el reparto entre los cuatro tipos determina el precio y el conflicto. Un contrato que solo cubre correctivo es barato y deja al cliente pagando aparte cada actualización obligatoria. Un contrato que lo cubre todo sin límites es imposible de sostener para el proveedor, que acabará estirando plazos para sobrevivir. El contrato útil es el que dice, de forma explícita, qué porcentaje del esfuerzo mensual se dedica a cada cosa —o al menos qué entra y qué se presupuesta aparte—.

Esta lógica no cambia por tipo de plataforma: es la misma para un ERP a medida, una aplicación interna o una tienda online, aunque el mantenimiento de módulos de ecommerce tenga su propio catálogo de riesgos por la cantidad de código de terceros implicado.

2. El alcance: la cláusula que decide si el contrato funciona

Si solo pudieras negociar una cláusula, negocia esta. El alcance mal definido es la causa raíz de prácticamente todas las relaciones de mantenimiento que acaban mal.

2.1 Inventario de lo que se mantiene

No vale «la web» ni «el sistema». El contrato debe llevar un anexo con el inventario concreto: repositorios y ramas, aplicaciones, servidores y entornos, bases de datos, servicios de terceros integrados, dominios y certificados, trabajos programados. Cada elemento con su versión actual.

Ese anexo tiene una segunda función más valiosa que la contractual: obliga a las dos partes a mirar de frente lo que hay. En más de una ocasión el inventario ha destapado un servidor que nadie recordaba, o una integración crítica que corría en la máquina de un empleado que ya no estaba en la empresa.

2.2 Qué queda fuera, y cómo se pide

Tan importante como la lista de lo incluido es la de lo excluido, y sobre todo el procedimiento para pedir lo que está fuera. Un buen contrato define: quién puede solicitar trabajo adicional, cómo se estima, en cuánto tiempo se responde con presupuesto y quién lo aprueba. Sin ese circuito, cada petición se convierte en una negociación desde cero y el equipo técnico acaba haciendo de comercial.

Exclusiones típicas que conviene nombrar: desarrollos nuevos por encima de cierto umbral de horas, migraciones de plataforma o de versión mayor, rediseños, recuperación de datos por errores del cliente, soporte a usuarios finales (distinto de soporte técnico), y trabajo sobre código que el cliente o un tercero modifique por su cuenta.

2.3 Entornos, accesos y forma de trabajo

El contrato debe decir si existe un entorno de pruebas y quién lo paga, si se despliega con revisión previa, qué ventana de despliegue se respeta y qué pasa con los cambios urgentes fuera de proceso. Un proveedor que solo tiene acceso a producción no puede hacer mantenimiento serio, puede hacer parches. Si tu contrato no contempla un entorno de staging, estás pagando por un nivel de riesgo que probablemente no has decidido asumir conscientemente.

3. Niveles de servicio (SLA): lo que de verdad se compromete

El acuerdo de nivel de servicio es la parte del contrato que más se copia y pega, y por eso la que más suele mentir. Un SLA sirve si define tres cosas con precisión: cómo se clasifica una incidencia, qué se promete para cada clase y cómo se mide.

3.1 Severidades definidas por impacto, no por opinión

La clasificación debe apoyarse en el impacto de negocio, no en el nerviosismo de quien reporta. «Crítico» no es «me corre prisa»: es el servicio caído, la imposibilidad de cobrar, la pérdida o exposición de datos. Si no se define por escrito, todo entra como crítico y el SLA deja de significar nada.

3.2 Tiempo de respuesta no es tiempo de resolución

Esta es la confusión más cara del sector. El tiempo de respuesta es lo que tarda alguien en hacerse cargo del aviso; el de resolución, lo que tarda el problema en desaparecer. Muchos contratos comprometen solo el primero —que es fácil de cumplir— y dejan el segundo en «mayor diligencia posible». Si el objetivo es proteger el negocio, hace falta comprometer también un tiempo de resolución objetivo por severidad, aunque sea con excepciones razonadas (dependencias de terceros, fallos de infraestructura del proveedor de hosting).

3.3 Horario de cobertura y guardias

Un SLA sin horario es papel mojado. Hay que fijar la ventana de cobertura ordinaria (por ejemplo, laborables de 9:00 a 18:00), si existe guardia fuera de ese horario, cómo se activa y cuánto cuesta. Una guardia 24×7 real es cara porque implica personas de turno; si el presupuesto no da, es más honesto contratar cobertura extendida los días críticos —campañas, cierres de mes, Black Friday— que fingir un 24×7 que en la práctica es «alguien mirará el móvil si lo ve».

3.4 La letra pequeña de la disponibilidad

Un 99,9% mensual son unos 43 minutos de caída al mes; un 99,5%, casi cuatro horas. La cifra importa menos que las tres preguntas que la acompañan: qué se excluye del cómputo (ventanas de mantenimiento planificadas, causas de fuerza mayor, fallos del proveedor de infraestructura), con qué herramienta se mide —y quién la controla— y qué pasa si no se cumple. Un compromiso de disponibilidad medido por el propio proveedor, sin consecuencia asociada, es una declaración de intenciones.

4. Mantenimiento preventivo: la parte que nadie reclama y todo el mundo necesita

El preventivo es la diferencia entre un contrato de mantenimiento y un contrato de reparación. Es también la primera partida que se recorta cuando hay que ajustar precio, y la razón por la que dos años después la plataforma exige una migración de urgencia.

4.1 Actualizaciones y parches

El contrato debe decir con qué frecuencia se revisan y aplican actualizaciones de sistema operativo, runtime, framework, CMS y dependencias; y qué se hace con un parche de seguridad crítico fuera de ciclo. Lo razonable es distinguir entre parches de seguridad —que se aplican en cuanto se validan, con un plazo comprometido— y actualizaciones funcionales, que entran en ventanas planificadas. Este trabajo es, literalmente, el que evita la mayoría de incidentes: mantener servidores y aplicaciones al día es la medida de seguridad más rentable que existe.

4.2 Copias de seguridad y pruebas de restauración

Que haya backups no significa nada; lo que cuenta es haber restaurado alguno. El contrato debe fijar la frecuencia de copia, la retención, dónde se guardan las copias y —el punto que casi siempre falta— cada cuánto se hace una prueba de restauración real y quién entrega el informe. Además conviene fijar los objetivos: cuántos datos se puede permitir perder el negocio y en cuánto tiempo debe estar de vuelta el servicio.

4.3 Monitorización y umbrales

Sin monitorización, el proveedor se entera de las caídas porque llama el cliente, y entonces el tiempo de respuesta ya se ha consumido entero. El contrato debe especificar qué se monitoriza (disponibilidad, errores de aplicación, espacio, certificados, rendimiento), con qué umbrales se generan avisos y a quién llegan. Medir el rendimiento de forma continua y no solo cuando alguien se queja es lo que convierte el mantenimiento en algo proactivo.

4.4 El informe periódico

Un buen contrato entrega, cada mes o cada trimestre, un informe con: incidencias abiertas y cerradas por severidad, cumplimiento de los tiempos comprometidos, horas consumidas frente a las contratadas, actualizaciones aplicadas, riesgos detectados y recomendaciones. Ese documento es lo que permite a dirección entender qué está comprando. Sin él, el mantenimiento es una factura mensual sin relato, y las facturas sin relato son las primeras que se cuestionan en un recorte.

5. Modelos de precio: quién asume el riesgo

No hay un modelo correcto. Hay un reparto de riesgo, y conviene elegirlo a conciencia en lugar de heredar el que propone la primera oferta que llega.

5.1 Bolsa de horas

El cliente compra un paquete de horas y se consumen según parte de trabajo. Es flexible y transparente, y encaja bien cuando la carga es irregular. Sus dos problemas: no compromete disponibilidad —si el proveedor está ocupado, tus horas esperan— y suele llevar caducidad. Si firmas este modelo, negocia el arrastre de horas no consumidas y pide que el parte detalle tarea y tiempo, no solo el total.

5.2 Cuota fija

Un importe mensual cerrado por un alcance definido, normalmente con SLA y preventivo incluidos. Es el modelo que de verdad compra tranquilidad, porque alinea al proveedor con la estabilidad: cuanto mejor mantenido esté el sistema, menos incidencias y mejor margen. Su riesgo es el espejo del anterior: si el alcance está mal escrito, cada petición acabará siendo «fuera de contrato» y la relación se envenena.

5.3 Híbrido

Cuota base que cubre preventivo, monitorización y soporte con SLA, más una bolsa separada para evolutivos. En nuestra experiencia es el que mejor funciona para producto vivo: garantiza que el trabajo invisible se hace sí o sí, y da un cauce ordenado a las mejoras sin renegociar cada mes. Exige disciplina para clasificar bien cada tarea, y esa clasificación conviene que la pueda revisar el cliente.

5.4 Lo que hay que mirar más allá de la cifra

Revisión anual de precios y a qué índice se ata; tarifa de hora extraordinaria y de trabajo fuera de horario; si las horas de reunión y gestión consumen bolsa; qué pasa con el tiempo dedicado a diagnosticar una incidencia que resulta no ser del proveedor. Y una comparación honesta: el coste del contrato frente al de tener el perfil en plantilla, una decisión que tiene más aristas de las que parece y que ya analizamos al comparar equipos dedicados frente a freelancers.

6. Las cláusulas que evitan sorpresas

6.1 Propiedad del código y licencias

Debe quedar escrito que el código desarrollado durante el mantenimiento es del cliente, y qué licencias de terceros están en juego (módulos de pago, librerías con licencia restrictiva, plantillas). Es frecuente descubrir en una migración que media plataforma depende de licencias a nombre del proveedor saliente.

6.2 Accesos, credenciales y trazabilidad

El cliente debe conservar siempre las cuentas propietarias de dominios, hosting y repositorios; el proveedor trabaja con cuentas nominales y permisos acotados, nunca con credenciales compartidas. El contrato debe exigir gestión de secretos, registro de accesos y revocación inmediata al finalizar. Es exactamente lo que piden los controles técnicos de ISO 27001, y no hace falta estar certificado para aplicarlos.

6.3 Protección de datos

Si el proveedor accede a datos personales —y en un mantenimiento con acceso a base de datos, accede—, hace falta contrato de encargado del tratamiento con las finalidades, las medidas de seguridad, el régimen de subencargados y el destino de los datos al terminar. No es burocracia: es la diferencia entre una brecha gestionada y una brecha con sanción.

6.4 Estado de partida y deuda técnica heredada

Un proveedor no puede comprometer SLA sobre un sistema que no conoce. La salida razonable es una fase de evaluación inicial que documente el estado real y liste los riesgos, dejando por escrito qué queda excluido del compromiso hasta que se remedie. Una auditoría de código previa cuesta una fracción del contrato anual y evita discusiones durante toda su vida; en operaciones de compra o inversión, esa misma foto se formaliza como due diligence técnica.

6.5 Duración, preaviso y plan de salida

La cláusula que nadie lee al firmar y todos necesitan al final. Debe fijar duración y renovación, plazo de preaviso por ambas partes y, sobre todo, un plan de traspaso: entrega de documentación actualizada, inventario de accesos, traspaso de repositorios y credenciales, y un número de horas de acompañamiento al proveedor entrante. Un contrato sin salida ordenada convierte el cambio de proveedor en un proyecto de rescate.

6.6 Penalizaciones: úsalas con cabeza

Las penalizaciones por incumplimiento de SLA tienen sentido cuando son proporcionadas y automáticas —un descuento sobre la cuota del periodo—. Cuando son desproporcionadas, el efecto es el contrario al buscado: el proveedor infla el precio para cubrir el riesgo, o clasifica las incidencias a la baja para no incumplir. El objetivo de una penalización no es cobrar, es alinear incentivos.

7. Los primeros 30 días: el onboarding que decide el resto

Un contrato firmado no es un servicio en marcha. El primer mes debería producir entregables concretos: inventario verificado, accesos creados y probados, monitorización desplegada con sus alertas, copia de seguridad verificada con una restauración real, canal de soporte operativo con su flujo de escalado, y un informe inicial de riesgos con las tres o cuatro cosas que hay que arreglar cuanto antes.

Si al cabo de un mes no existe ninguno de esos entregables, el contrato está vivo solo en la factura. Es el momento de decirlo, no seis meses después, durante la primera caída seria.

8. Señales de un mal contrato de mantenimiento

Con el tiempo se aprende a detectarlos casi de un vistazo. Estas son las señales más fiables:

• El alcance se describe en una frase genérica y no hay anexo de inventario.
• Se comprometen tiempos de respuesta pero ningún tiempo de resolución.
• No se distingue entre severidades, o las define quien reporta.
• No aparecen las palabras copia de seguridad, restauración, monitorización ni actualización.
• No hay informe periódico ni reunión de seguimiento prevista.
• Las credenciales maestras están a nombre del proveedor.
• No existe cláusula de salida ni horas de traspaso.
• El precio es notablemente inferior al mercado: alguien está asumiendo que no vas a reclamar nada.

La última merece un matiz. Un mantenimiento barato no es un problema por el precio, sino porque obliga al proveedor a trabajar en modo reactivo permanente: solo se toca lo que arde. Y en modo reactivo permanente nadie aplica parches, nadie prueba restauraciones y nadie revisa logs, que es justo el trabajo por el que se firma un mantenimiento.

9. Checklist para revisar tu contrato

Si ya tienes uno firmado, este repaso lleva quince minutos y suele dar sorpresas:

• ¿Existe un anexo con el inventario concreto de lo que se mantiene y sus versiones?
• ¿Están escritos los cuatro tipos de mantenimiento y cuáles entran en la cuota?
• ¿Hay severidades definidas por impacto de negocio?
• ¿Hay tiempo de respuesta y de resolución por severidad?
• ¿Qué horario cubre y qué cuesta salirse de él?
• ¿Quién mide la disponibilidad y qué se excluye del cómputo?
• ¿Con qué frecuencia se aplican parches de seguridad?
• ¿Cuándo fue la última prueba de restauración documentada?
• ¿Recibes informe periódico con horas, incidencias y riesgos?
• ¿A nombre de quién están dominio, hosting y repositorio?
• ¿Hay contrato de encargado del tratamiento?
• ¿Qué preaviso hay y cuántas horas de traspaso están comprometidas?

Si fallan más de tres, no hace falta cambiar de proveedor: hace falta sentarse a reescribir el anexo. La mayoría de las relaciones de mantenimiento que van mal se arreglan con dos horas de conversación honesta sobre el alcance, no con un burofax.

10. Preguntas frecuentes

¿Cuánto cuesta un contrato de mantenimiento de software?

Depende del alcance, del SLA y de la criticidad, y desconfía de quien te dé una cifra sin haber visto el sistema. Como referencia de mercado, un mantenimiento con cobertura en horario laboral, preventivo e informes se mueve habitualmente en una franja anual equivalente a un porcentaje de un dígito medio sobre el coste de desarrollo original. Lo importante no es el porcentaje, sino que la cifra esté atada a un alcance escrito.

¿Es mejor cuota fija o bolsa de horas?

Cuota fija si necesitas disponibilidad comprometida y el sistema es crítico; bolsa de horas si la carga es esporádica y puedes esperar. Si el software sigue evolucionando, el híbrido suele ser el que menos fricción genera.

¿El mantenimiento incluye desarrollar funciones nuevas?

Normalmente no, o solo hasta un umbral pequeño. Lo sano es que el contrato fije ese umbral en horas y defina el circuito de presupuesto para lo que lo supere, en lugar de dejarlo a la interpretación de cada mes.

¿Qué pasa si quiero cambiar de proveedor?

Si el contrato tiene plan de salida, es un proceso de semanas: traspaso de accesos, documentación y acompañamiento. Si no lo tiene, conviene empezar por un inventario y una auditoría antes de mover nada, para no descubrir a mitad de camino que falta una licencia o una credencial.

¿Necesito mantenimiento si mi software «funciona bien»?

Funcionar bien hoy no dice nada del mes que viene: el entorno cambia aunque tu código no. Sin mantenimiento adaptativo y preventivo, la factura no desaparece, solo se aplaza y crece. Esa es exactamente la dinámica de la deuda técnica, y suele acabar en una migración de urgencia con el negocio parado.

Conclusión

Un contrato de mantenimiento de software no se juzga por su extensión ni por lo tranquilizador que suene, sino por cuántas preguntas incómodas responde antes de que ocurran: qué se mantiene exactamente, qué pasa cuando algo cae un viernes por la tarde, quién paga la actualización obligatoria del año que viene, quién tiene las llaves y cómo se recuperan el día que la relación termine.

Escribir esas respuestas cuesta una tarde. No escribirlas cuesta, tarde o temprano, una migración de urgencia, una brecha mal gestionada o un cambio de proveedor a ciegas. Si estás a punto de firmar —o de proponer— un mantenimiento, empieza por el anexo de alcance y la matriz de severidades; el resto del contrato se escribe solo a partir de ahí.

Y si lo que tienes delante es un sistema heredado del que nadie sabe muy bien qué esperar, la secuencia sensata es conocerlo primero y comprometer después: una foto técnica honesta permite firmar unos niveles de servicio que se puedan cumplir, que es la única clase de SLA que sirve para algo. En proyectos jóvenes, esa conversación suele ir de la mano de la figura del CTO externo, que es quien traduce el contrato a decisiones técnicas sostenibles.