Es una de las llamadas más frecuentes que recibimos en IT Efectivos: una empresa mediana descubre, a veces de golpe, que el proveedor que desarrolló su sistema crítico ya no está. El correo rebota, el teléfono no contesta, la página web devuelve un error, o simplemente el contrato llegó a su término y el proveedor decidió "no renovar".
La pregunta es siempre la misma: ¿qué hacemos ahora?. En este artículo explicamos un protocolo de respuesta en caliente, qué evaluar en las primeras 48 horas y qué opciones existen para proteger la continuidad del negocio.
Primer paso: no entrar en pánico (y no tomar decisiones apresuradas)
Es tentador, frente a la noticia, querer actuar rápido: "reemplacemos el sistema", "llamemos al primer desarrollador que encontremos", "migremos todo a SAP". Casi siempre son malas decisiones. La urgencia real es entender el riesgo, no resolverlo en la primera semana.
El sistema no va a dejar de funcionar hoy por el hecho de que el proveedor no responda. La prioridad es estabilizar la situación y ganar tiempo para tomar decisiones informadas.
Las primeras 48 horas
1. Haz inventario de lo que tienes
Reúne, en un solo lugar, todo lo relacionado con el sistema:
- Contrato original y anexos.
- Correos recientes con el proveedor.
- Accesos: servidor, base de datos, panel de administración, hosting, dominio.
- Credenciales: usuarios y contraseñas de administración.
- Repositorio de código, si lo tienes.
- Documentación existente (aunque esté desactualizada).
- Facturas de licencias o servicios relacionados.
Si no tienes acceso al código fuente, este es el primer problema a resolver.
2. Asegura los accesos que están en manos del proveedor
Pregúntate:
- ¿Las claves del servidor las tiene solo el proveedor, o también nuestro equipo?
- ¿El dominio está registrado a nombre de la empresa o del proveedor?
- ¿El hosting está a nombre de la empresa o del proveedor?
- ¿Los respaldos (backups) están en nuestra infraestructura o en la del proveedor?
Si algún activo crítico está a nombre del proveedor, hay que gestionar la transferencia antes de que se pierda el acceso. Esto a veces es una carrera contra el tiempo.
3. Identifica los procesos que dependen del sistema
Haz una lista corta de los procesos de negocio que se caen si el sistema se cae:
- Facturación.
- Pedidos y operación.
- Inventario.
- Gestión de clientes.
- Reportes regulatorios.
- Procesos internos administrativos.
Esta lista es la base de la priorización: si algo se rompe en producción y no hay quien lo arregle, estos son los procesos que te dirán qué resolver primero.
4. Contacta al proveedor por los canales posibles
Antes de asumir que el proveedor desapareció, verifica:
- Correos a todas las personas con las que trabajaste históricamente.
- Canales alternativos (LinkedIn, teléfonos personales si los tienes).
- Cámara de comercio (a veces la empresa sigue inscrita con otra razón social).
- Otros clientes del mismo proveedor (frecuentemente están en la misma situación).
A veces hay conversación posible: el proveedor está en dificultades pero entrega código y documentación por un pago puntual.
Evaluación del riesgo
Con la información reunida, responde a estas preguntas para entender qué tan crítica es la situación:
Riesgo bajo
- Tienes acceso al código fuente.
- Los accesos a infraestructura están a nombre de la empresa.
- El sistema lleva funcionando estable varios meses.
- No hay cambios críticos pendientes en el corto plazo.
En este escenario, tienes tiempo (6-12 meses) para decidir con calma. Aprovecha para hacer una auditoría técnica y planificar el siguiente movimiento.
Riesgo medio
- Tienes código fuente pero sin documentación.
- El sistema tiene incidentes ocasionales.
- Hay dependencias de librerías o servicios discontinuados.
- No conoces la arquitectura en detalle.
Hay que actuar en 1-3 meses: contratar un equipo que haga transferencia de conocimiento, cierre las vulnerabilidades críticas y estabilice la operación.
Riesgo alto
- No tienes acceso al código fuente.
- La infraestructura está a nombre del proveedor.
- Hay incidentes frecuentes.
- El sistema depende de servicios externos que el proveedor controlaba.
Es urgente. En 2-4 semanas debes tener un equipo técnico dedicado, evaluar opciones de contingencia e incluso considerar procesos legales si el proveedor no responde a requerimientos de entrega.
Opciones para seguir adelante
Opción 1: Retoma de Software: Cómo Rescatar Sistemas Abandonados por su Proveedor Original">Retoma de software
Un nuevo equipo —interno o externo— asume el sistema. Lo documenta, lo estabiliza y lo mantiene. Es la opción más común y casi siempre la más eficiente.
Cuándo aplica: el sistema funciona, tienes código fuente (o se puede recuperar), y su valor para el negocio justifica mantenerlo.
Opción 2: Reescribir desde cero
Se desarrolla un sistema nuevo que reemplace al anterior, aprovechando para rediseñar la arquitectura. Es costoso y lento, pero a veces necesario.
Cuándo aplica: el sistema es pequeño, la tecnología base está discontinuada más allá del rescate, o el negocio ha cambiado al punto que el sistema ya no sirve.
Opción 3: Migrar a un producto comercial
Si el sistema hace lo que hace un software de caja (ERP, CRM, facturación), puede tener sentido reemplazarlo por una solución comercial (SAP, Oracle, Odoo, Siesa, Microsoft Dynamics, etc.).
Cuándo aplica: la diferenciación de tu empresa no depende del software, el proceso es estándar, y el ahorro en mantenimiento compensa la pérdida de personalización.
Opción 4: Combinación
Lo más común: retoma del núcleo crítico, reemplazo de módulos secundarios por soluciones comerciales. No es blanco o negro.
Errores comunes en esta situación
Contratar al primer desarrollador disponible
La urgencia lleva a contratar a quien esté libre. Si no tiene experiencia en retoma de código ajeno, el proyecto se vuelve un reemplazo encubierto —y costoso—.
No hacer auditoría previa
Empezar a "arreglar cosas" sin entender el sistema completo lleva a romper lo que funcionaba. La auditoría inicial de 2-3 semanas no es un gasto: es la base de todo lo demás.
Dejar el tema en manos solo de IT sin visibilidad directiva
Un sistema crítico sin proveedor es un riesgo de continuidad operativa. El comité directivo debe estar informado y las decisiones grandes deben escalarse.
No blindar legalmente la nueva relación
Si contratas un nuevo equipo, asegúrate de que el contrato incluya: entrega de código fuente, documentación, transferencia de conocimiento a terceros, cláusulas de salida. Aprende de la experiencia reciente.
Conclusión
Cuando un proveedor de software desaparece, la primera reacción debe ser estabilizar, no reaccionar. Los primeros días son para asegurar accesos y entender el riesgo; las primeras semanas, para evaluar opciones y tomar una decisión informada; los primeros meses, para ejecutar la opción elegida con disciplina.
En IT Efectivos hemos liderado decenas de retomas de software en empresas que se encontraron de pronto sin proveedor. Si estás en esa situación, una conversación de 30 minutos con nuestro equipo puede darte claridad sobre el riesgo real y las opciones concretas. Escríbenos.