Encargaste un sistema a medida. Quedó funcionando, tu equipo lo usa todos los días y el problema que lo motivó quedó resuelto. Tres meses después, un sábado por la mañana, nadie puede entrar. El disco del servidor se llenó, el certificado de seguridad venció o la base de datos dejó de responder. En ese momento aparece la pregunta que nadie hizo en la reunión de arranque: quién mantiene vivo el servidor.
Desarrollar no es mantener
El desarrollo tiene un final claro. Un día el sistema queda funcionando, se entrega y se cobra. El mantenimiento no tiene final: es la rutina de que ese sistema siga en pie. Son dos trabajos distintos, con dos precios distintos y muchas veces con dos responsables distintos.
Cuando contratas un sistema a medida no compras un archivo que se guarda en una carpeta. Compras un programa que vive en un servidor, que es una computadora encendida todo el día en algún centro de datos. Esa computadora tiene un sistema operativo, una base de datos, un certificado de seguridad, un dominio y varios programas que se comunican entre sí. Cualquiera de esas piezas puede fallar por su cuenta.
Cuando alguien dice “mantener el servidor”, habla de todo esto:
- El servidor: la máquina donde corre el sistema.
- La base de datos: donde están tus clientes, pedidos, inventario y facturas.
- Los respaldos: copias que se hacen solas y que algún día hay que probar.
- El dominio y el DNS: la dirección por la que llegan tus clientes.
- El certificado SSL: el candado que evita que el navegador marque tu sitio como inseguro.
- El correo transaccional: las confirmaciones y avisos que el sistema envía.
- Las actualizaciones de seguridad: los parches del sistema operativo y de las librerías que usa tu aplicación.
- El monitoreo: lo que avisa cuando algo se cayó.
Ninguna de esas piezas avisa antes de romperse. El servidor no manda una carta.
Qué se rompe cuando nadie mira
| Pieza | Qué pasa si nadie la atiende | Lo que siente tu negocio |
|---|---|---|
| Certificado SSL | Vence sin aviso | El navegador marca el sitio como no seguro y el cliente duda antes de entrar |
| Disco del servidor | Se llena con registros y archivos temporales | El sistema deja de guardar y los pedidos no entran |
| Respaldos | Se generan, pero nadie probó restaurarlos | Cuando necesitas volver atrás, el respaldo está incompleto |
| Sistema operativo y librerías | Quedan sin parches | Una vulnerabilidad pública y conocida queda abierta |
| Dominio | Vence el pago anual | El sistema sigue existiendo, pero nadie lo encuentra |
| Correo transaccional | Cambia una clave o falla el proveedor | Los clientes dejan de recibir confirmaciones |
Por qué es un problema de negocio y no solo técnico
Un sistema caído no es una molestia de programadores. Es una ferretería que no puede facturar, una clínica que no puede agendar, una inmobiliaria que no puede cargar una propiedad nueva un domingo. Cada hora que el sistema está abajo, alguien de tu equipo improvisa con papel, WhatsApp o Excel, y el trabajo se hace dos veces.
El problema real casi nunca es la caída. El problema es no saber a quién escribir cuando pasa. Si no hay un nombre, un correo y un teléfono en un acuerdo, la caída se convierte en una discusión sobre de quién era la responsabilidad.
Los cuatro modelos de mantenimiento
| Modelo | Quién responde | Cuándo tiene sentido |
|---|---|---|
| Lo mantienes tú | Tú o alguien de tu equipo | Si tienes personal técnico propio y quieres control total |
| El estudio que lo construyó | El mismo proveedor, con un plan mensual | Es lo más simple: conoce el sistema y ya tiene los accesos |
| Un tercero | Otra empresa o un freelancer | Sirve si el proveedor original ya no está disponible |
| Plataforma gestionada | El proveedor de la nube mantiene la infraestructura, alguien mantiene tu aplicación | Reduce las piezas que hay que cuidar, pero no elimina la necesidad de un responsable |
En los cuatro casos hay un elemento que no se puede saltar: alguien con nombre y apellido, por escrito, que responde.
Si tu sistema no es un desarrollo propio sino una licencia mensual de un proveedor externo, el problema cambia de forma. Ese caso lo cubrimos en qué pasa con tus datos si dejas de pagar la licencia.
Los accesos y el dominio deben estar a tu nombre
Este es el punto que más caro sale cuando se ignora. El dominio, la cuenta de hosting, el repositorio del código y el correo deben estar registrados a nombre de tu empresa, no del proveedor. Tú puedes darle acceso al proveedor; él no debería ser el dueño.
Si mañana decides cambiar de proveedor, recuperar un dominio registrado a nombre de otra persona puede tomar semanas. Y en el peor caso, no se recupera.
Qué debe quedar por escrito
Un acuerdo de mantenimiento no necesita veinte páginas. Necesita responder estas preguntas:
- Quién mantiene y cuántas horas al mes destina a revisar el sistema.
- Qué incluye el mantenimiento mensual. Una funcionalidad nueva no es mantenimiento, es un desarrollo aparte y se cotiza aparte.
- Qué pasa cuando algo se cae: por dónde se reporta, en qué horario y en cuánto tiempo hay respuesta.
- Cómo se accede al servidor, al dominio y a la base de datos.
- Qué pasa si dejas de pagar el mantenimiento.
- Cómo termina la relación y cómo te llevas el sistema a otro proveedor.
Cómo saber si hoy estás expuesto
Responde estas seis preguntas con honestidad:
- ¿Sabes en qué proveedor está alojado tu sistema?
- ¿Tienes las claves del dominio y del hosting?
- ¿Sabes cuándo fue el último respaldo y si alguien lo restauró alguna vez para probarlo?
- ¿Sabes cuándo vence el certificado de seguridad?
- ¿Tienes un número al que escribir si el sistema se cae un sábado?
- ¿Sabes cuánto pagas al mes por todo esto?
Si dudas en dos o más, no tienes un problema técnico. Tienes un problema de continuidad que todavía no te ha costado dinero.
Cómo se ve un plan de mantenimiento sano
No necesitas a alguien mirando el servidor todos los días. Necesitas que el servidor avise solo y que exista una persona responsable de leer esos avisos.
Un plan razonable incluye:
- Monitoreo con alertas: caídas del sitio, disco por llenarse, errores del servidor, respaldos fallidos y certificados próximos a vencer.
- Respaldo automático diario, con una prueba de restauración cada trimestre.
- Parches de seguridad aplicados en una ventana acordada.
- Un canal de soporte con horario definido y un responsable claro.
- Un informe simple: qué se revisó, qué se encontró y qué se corrigió.
La diferencia entre esto y no tener nada es que la alerta llega antes que el cliente molesto.
Dónde vive el servidor importa
En Venezuela esto no es un detalle. Si el sistema corre en una computadora dentro de tu local, cualquier corte de luz o falla de internet deja a tu equipo sin trabajar, y nadie de afuera puede entrar aunque quiera. Si el sistema vive en la nube, tu local puede quedarse sin luz y el sistema sigue disponible desde un celular con datos.
Lo segundo es quién paga ese servidor. Si lo paga el proveedor como parte de un paquete, pregunta qué pasa con esa cuenta si la relación termina.
Para cerrar
La pregunta no es si tu sistema se va a caer. Se va a caer en algún momento, como cualquier cosa que depende de electricidad, red y software. La pregunta útil es otra: cuando se caiga, ¿ya sabes a quién escribir y esa persona ya sabe que le toca responder?
Eso se decide antes de la entrega, no durante la caída.