Mantenimiento de software

Mantenimiento de software para el sistema que ya operas.

El software en producción no se mantiene sano solo. Las dependencias envejecen, llegan parches de seguridad, aparecen errores y las pequeñas peticiones se acumulan. Acordamos qué mantenemos, cómo nos llegan las solicitudes y con qué rapidez respondemos, y después hacemos el trabajo con un registro que puedes comprobar.

Definir el contrato de mantenimiento →

RESPUESTA DIRECTA

El mantenimiento de software es el cuidado continuo del software en producción: actualizaciones, parches de dependencias y de seguridad, corrección de errores, pequeñas mejoras y una monitorización útil. Alcance, horario y tiempos de respuesta se acuerdan por contrato; no incluye cobertura 24/7 ni un SLA de disponibilidad.

Adecuado para

  • Un sistema en producción que se puede compilar y publicar, y necesita un mantenimiento fiable
  • Equipos cuyos desarrolladores están en trabajo nuevo y quieren delegar el cuidado rutinario

Cuándo elegir otro servicio

  • Un cambio de proveedor que primero exige recuperar accesos y conocimiento
  • Guardias 24/7 o una garantía contractual de disponibilidad

Empieza con un sistema que se pueda mantener

El mantenimiento presupone que podemos compilar, probar y publicar el sistema. Si el problema son los accesos, la documentación o el proveedor anterior, primero va un traspaso de software; sus ofertas de transferencia, recuperación y actualización de dependencias mantienen su propio alcance y condiciones. Si la revisión inicial muestra que el sistema no se puede publicar con seguridad, lo decimos antes de acordar un alcance de mantenimiento. Los cambios estructurales, como sustituir un framework o dividir un monolito, son modernización de sistemas heredados.

Qué incluye el cuidado rutinario

El contrato enumera los sistemas y entornos cubiertos. El trabajo fuera de esa lista se presupuesta antes de empezar.

Actualizaciones y parches de seguridad

Mantener entornos de ejecución, frameworks y librerías en versiones con soporte. Los avisos de seguridad se evalúan y se aplican en el orden de prioridad acordado.

Corrección de errores

Reproducir, corregir, probar y publicar defectos que reporta tu equipo o que aparecen en logs y en el seguimiento de errores.

Pequeñas mejoras

Cambios menores dentro de un presupuesto mensual acordado. Todo lo que sea mayor se presupuesta aparte antes de empezar.

Monitorización útil

Mantener útiles el seguimiento de errores, los logs, los certificados y las alertas. Las alertas llegan a una persona concreta dentro del horario acordado.

Los tiempos de respuesta se acuerdan, no se suponen

El contrato indica los sistemas cubiertos, el canal de solicitudes, el horario, cómo se clasifica la gravedad y los objetivos de respuesta para cada nivel. Esos objetivos se aplican dentro del horario acordado. No ofrecemos guardias 24/7 ni un SLA de disponibilidad, y un contrato de mantenimiento no los crea. Reforzar el entorno en ejecución es Cloud Security; los controles del proceso de compilación y entrega son DevSecOps. El Trust Center explica nuestros límites generales de soporte.

Registro ilustrativo: un mes de mantenimiento

Un informe mensual ilustrativo enumera las actualizaciones de dependencias aplicadas y aplazadas (con su motivo), los avisos de seguridad revisados, los errores corregidos con el release que contiene cada corrección, los pequeños cambios entregados frente al presupuesto acordado, los puntos abiertos y las decisiones que te corresponden. Es un formato de ejemplo, no un resultado de cliente ni un compromiso de nivel de servicio.

Incorporar, mantener, revisar

La revisión inicial tiene su propio alcance y presupuesto. El contrato de mantenimiento se basa en lo que encuentra.

  1. Revisión inicial

    Compilamos, probamos y publicamos el sistema una vez en un entorno acordado. Recibes un inventario de versiones, los riesgos conocidos y una propuesta de alcance de mantenimiento.

  2. Mantenimiento continuo

    Un acuerdo mensual que cubre los sistemas, el horario, el canal de solicitudes y los objetivos de respuesta acordados por contrato.

  3. Revisión periódica

    Repasar qué se hizo, qué envejeció y qué sigue fallando. Un problema estructural recurrente pasa a ser una decisión aparte de modernización o seguridad.

Trae accesos, la lista de versiones y a quienes reportan problemas

Necesitamos acceso al repositorio, a la CI y al alojamiento, la lista actual de versiones, los problemas conocidos, el seguimiento de errores, las personas que reportan incidencias y alguien que pueda aprobar releases. Las funcionalidades grandes corresponden a desarrollo de software. Para presupuestar, la guía de costes de mantenimiento explica los factores de coste habituales; su modelo no es un presupuesto ni un compromiso de soporte.
// pruebas

Cuidado continuo en trabajos de ingeniería existentes

IKB: Wavect trabajó dentro del proyecto Smart City de IKB en infraestructura y dispositivos, transfirió la plataforma por completo al equipo interno de IKB y siguió como apoyo externo para nuevas integraciones de dispositivos, el stack de Grafana, la conectividad de campo y las llamadas con fabricantes. MyMerch documenta una colaboración de varios años mejorando un negocio Shopify que ya funcionaba, en pasos concretos y sin reescribirlo. Polity documenta una responsabilidad de QA prolongada con reducción de pruebas inestables y triaje de errores en varios servicios. Ninguno de estos casos documenta cobertura 24/7 ni un compromiso de disponibilidad.

IKB

En Vivo
Completo Traspaso de la Plataforma

IoT Smart City para Innsbruck: ampliamos y escalamos la infraestructura LoRaWAN, evaluamos e integramos dispositivos …

Kubernetes LoRaWAN Docker
ENTERPRISE

MyMerch

En Vivo
~50% Mejora de eficiencia para el equipo de MyMerch

El equipo de MyMerch sitúa la mejora de eficiencia en torno al 50%. Menos errores de entrega, mayor conversión en Shopify, sin …

Shopify Shopify Liquid JavaScript
ENTERPRISE 2023-2026

Polity

En Vivo
7 servicios Pruebas Unificadas

1,5 años de propiedad de QA en siete servicios y múltiples proveedores. La calidad se mantuvo entregable a través de cada …

React Java/Kotlin Go
ENTERPRISE 2026

Estos son proyectos seleccionados, no nuestro portfolio completo. Hemos entregado más de 100 productos desde 2018.

Preguntas antes de empezar

No. No ofrecemos guardias 24/7 ni un SLA de disponibilidad. El horario, los niveles de gravedad y los objetivos de respuesta se acuerdan en el contrato y se aplican dentro de ese horario.
Los que figuran en el contrato. Dependen del nivel de gravedad y del horario acordado, y los fijamos después de la revisión inicial, cuando ya conocemos el sistema.
Sí, si se puede compilar y publicar. La revisión inicial lo demuestra. Si el proveedor anterior se va y primero hay que recuperar accesos o conocimiento, eso es un traspaso de software.
Las pequeñas mejoras caben en el presupuesto mensual acordado. Las funcionalidades más grandes se presupuestan aparte o se gestionan como un encargo de desarrollo de software, para que el cuidado rutinario no se convierta sin aviso en un proyecto abierto.
Como un acuerdo mensual para el alcance acordado. El trabajo fuera de ese alcance se presupuesta antes de empezar. No damos un precio antes de la revisión inicial, porque el coste depende del sistema.

Elige el siguiente paso

Definir el contrato de mantenimiento

Describe el sistema, su stack, quién lo mantiene hoy y qué se queda siempre pendiente. No incluyas credenciales ni datos confidenciales en la primera consulta.

Definir el contrato de mantenimiento →