El proveedor dejó de responder.
La persona que desarrolló el sistema ya no trabaja con la empresa. La software factory cerró. El freelancer desapareció. O simplemente nadie sabe quién puede intervenir si mañana ocurre una falla.
Cuando un proveedor de software desapareció, el primer impulso suele ser buscar rápidamente a alguien que “tome el sistema”.
Pero antes de modificar nada conviene responder una pregunta más importante:
¿Qué activos tecnológicos controla realmente la empresa?
Código fuente, base de datos, servidores, dominios, credenciales, backups e integraciones determinan qué tan sencilla o compleja será la recuperación.
¿Qué significa que un proveedor de software haya desaparecido?
No necesariamente significa que la empresa proveedora haya cerrado formalmente.
En la práctica, existe un problema de continuidad cuando el proveedor:
- deja de responder;
- abandona el proyecto;
- deja de brindar mantenimiento;
- cierra su empresa;
- pierde al desarrollador que conocía el sistema;
- no puede continuar trabajando con la tecnología;
- finaliza la relación comercial sin realizar una transferencia adecuada.
El resultado es el mismo: la empresa necesita encontrar una forma segura de continuar operando.
¿El sistema deja de funcionar inmediatamente?
No necesariamente.
Muchos sistemas pueden seguir funcionando durante meses o años sin intervención.
El problema aparece cuando se necesita:
- corregir un error;
- renovar un certificado;
- actualizar un servidor;
- modificar una integración;
- incorporar un usuario;
- adaptarse a un cambio externo;
- recuperar información;
- agregar una nueva funcionalidad.
Por eso el mejor momento para recuperar el control es mientras el sistema todavía funciona.
Primer paso: no empezar modificando el sistema
Cuando aparece una urgencia tecnológica puede ser tentador permitir que un nuevo desarrollador haga cambios inmediatamente.
Eso puede aumentar el riesgo si todavía no se entiende qué existe.
Antes conviene realizar un inventario.
La prioridad inicial debería ser:
- asegurar accesos;
- respaldar información;
- identificar infraestructura;
- localizar el código;
- documentar dependencias;
- evaluar el estado técnico.
¿Qué hay que recuperar primero?
1. Código fuente
Localizar el repositorio donde se encuentra el código de la aplicación.
Puede estar alojado en plataformas como GitHub, GitLab, Bitbucket u otro servicio.
Conviene verificar:
- que el repositorio exista;
- que esté actualizado;
- que incluya la versión actualmente en producción;
- que la empresa pueda acceder;
- que exista historial de cambios.
2. Base de datos
Los datos suelen ser incluso más importantes que el código.
Es necesario identificar:
- dónde está la base de datos;
- cómo acceder;
- qué motor utiliza;
- qué tamaño tiene;
- si existen backups;
- cómo exportarla.
3. Infraestructura
Hay que identificar dónde funciona el sistema.
Por ejemplo:
- servidor físico;
- VPS;
- cloud;
- hosting compartido;
- contenedores;
- servicios administrados.
También conviene conocer quién administra la cuenta y cómo se factura.
4. Dominios y DNS
Un dominio puede ser crítico para acceder al sistema, recibir correos o mantener integraciones.
La empresa debería verificar:
- registrador;
- titularidad;
- fecha de vencimiento;
- DNS;
- acceso administrativo.
5. Servicios externos
Muchos sistemas dependen de terceros.
Por ejemplo:
- correo transaccional;
- pasarelas de pago;
- almacenamiento;
- SMS;
- WhatsApp;
- APIs;
- mapas;
- servicios fiscales;
- notificaciones.
Perder acceso a uno de estos servicios puede romper funcionalidades aunque el sistema principal siga funcionando.
Hacer un backup antes de tocar nada
Una de las primeras acciones técnicas debería ser preservar el estado actual.
Dependiendo del sistema, puede incluir:
- backup de base de datos;
- copia del código;
- snapshot del servidor;
- copia de archivos;
- exportación de configuraciones;
- registro de variables de entorno.
La idea es poder volver atrás si una intervención genera un problema.
¿Qué pasa si no tenemos el código fuente?
Es una situación más compleja, pero no todas las posibilidades desaparecen.
Primero hay que investigar si existen copias en:
- repositorios;
- computadoras de empleados;
- servidores;
- backups;
- cuentas del proveedor;
- entornos de desarrollo antiguos.
En algunas tecnologías parte del código puede encontrarse directamente en el servidor.
En otras, solamente existe la aplicación compilada.
La viabilidad de continuar dependerá de la arquitectura utilizada.
¿Qué pasa si tenemos el código pero no sabemos cómo funciona?
Esto es frecuente.
El código permite comenzar una investigación técnica, pero no reemplaza la documentación.
Un nuevo equipo puede analizar:
- estructura del proyecto;
- frameworks;
- dependencias;
- base de datos;
- integraciones;
- logs;
- configuraciones;
- procesos automáticos.
A partir de ahí puede reconstruir progresivamente el conocimiento necesario.
¿Puede otro proveedor continuar un software desarrollado por otra empresa?
Sí.
No existe una regla técnica que obligue a que el desarrollador original mantenga el sistema para siempre.
Otro equipo puede asumirlo si logra obtener suficiente información sobre:
- código;
- infraestructura;
- datos;
- integraciones;
- dependencias;
- reglas de negocio.
La dificultad dependerá del estado en que se encuentre el proyecto.
¿Qué suele hacer un nuevo equipo primero?
Antes de comprometerse con grandes desarrollos, conviene hacer una etapa de relevamiento técnico.
Puede incluir:
- obtener acceso al repositorio;
- levantar el proyecto en un entorno controlado;
- revisar tecnologías;
- analizar la base de datos;
- relevar infraestructura;
- identificar servicios externos;
- revisar backups;
- identificar riesgos;
- documentar arquitectura general.
Con esa información se puede saber si el sistema puede mantenerse, necesita estabilización o conviene comenzar una modernización.
No todo tiene que resolverse el primer día
Una recuperación puede dividirse por prioridades.
Prioridad 1: continuidad
Conseguir que la plataforma siga funcionando y que existan backups.
Prioridad 2: control
Recuperar cuentas, credenciales, repositorios e infraestructura.
Prioridad 3: conocimiento
Entender cómo funciona y documentar componentes críticos.
Prioridad 4: estabilización
Corregir vulnerabilidades, dependencias peligrosas o fallas frecuentes.
Prioridad 5: evolución
Recién después conviene plantear nuevas funcionalidades o modernización.
¿Qué pasa si el servidor está a nombre del proveedor?
Es una de las situaciones más delicadas.
La empresa deberá revisar qué acceso tiene y cuáles son las condiciones contractuales existentes.
Desde el punto de vista técnico, si se consigue acceso suficiente puede prepararse una migración hacia infraestructura controlada por la organización.
Por ejemplo:
- respaldar base de datos;
- copiar archivos;
- identificar configuraciones;
- preparar un nuevo servidor;
- probar el sistema;
- migrar DNS;
- validar la operación.
¿Qué pasa si tampoco tenemos las contraseñas?
Primero conviene identificar quién figura como propietario o administrador de cada servicio.
Algunas plataformas permiten recuperar acceso mediante:
- correo corporativo;
- titularidad de dominio;
- datos de facturación;
- administradores adicionales;
- procedimientos de recuperación del proveedor.
En otros casos será necesario contactar formalmente al proveedor anterior.
Cambiar las credenciales después de recuperar el control
Una vez recuperadas las cuentas críticas, conviene revisar los accesos existentes.
Esto puede incluir:
- rotar contraseñas;
- actualizar claves API;
- revocar usuarios antiguos;
- activar autenticación multifactor;
- crear cuentas individuales;
- registrar nuevos responsables.
El objetivo es saber exactamente quién conserva acceso.
Revisar los backups
Un backup no debería asumirse como válido solamente porque existe un archivo programado.
Conviene comprobar:
- última fecha;
- frecuencia;
- integridad;
- ubicación;
- retención;
- capacidad de restauración.
Cuando el proveedor desaparece, tener un respaldo independiente puede convertirse en la diferencia entre recuperar el sistema y perder información.
Identificar automatizaciones y procesos invisibles
Algunas funciones críticas pueden no aparecer dentro de la interfaz.
Por ejemplo:
- tareas programadas;
- cron jobs;
- scripts;
- sincronizaciones;
- importaciones automáticas;
- procesamiento de archivos;
- notificaciones;
- renovaciones.
Estos componentes deben relevarse antes de migrar infraestructura o modificar configuraciones.
Revisar certificados y vencimientos
Algunos sistemas dependen de elementos que vencen periódicamente.
Por ejemplo:
- certificados SSL;
- tokens;
- dominios;
- licencias;
- credenciales API;
- certificados de integración.
Si nadie sabe cuándo vencen, una aplicación aparentemente estable puede dejar de funcionar inesperadamente.
¿Conviene reemplazar inmediatamente el sistema?
No necesariamente.
Perder al proveedor y tener un sistema tecnológicamente obsoleto son problemas diferentes.
Primero conviene recuperar control.
Después puede decidirse si conviene:
- mantener;
- estabilizar;
- modernizar;
- migrar;
- reemplazar.
Tomar esa decisión bajo una emergencia suele producir peores resultados.
El error de pedir que “hagan uno igual”
Cuando un proveedor desaparece, algunas empresas buscan inmediatamente reconstruir el sistema pantalla por pantalla.
Eso puede generar dos problemas.
Primero, puede ser innecesario si la plataforma actual todavía puede recuperarse.
Segundo, puede reproducir procesos y limitaciones que ya no tienen sentido.
Antes de reconstruir conviene entender qué vale la pena conservar.
¿Cuándo conviene modernizar?
Después de recuperar el control puede descubrirse que existen problemas como:
- frameworks sin soporte;
- bases de datos antiguas;
- infraestructura frágil;
- falta de APIs;
- interfaces obsoletas;
- dependencias difíciles de mantener.
En ese caso puede ser conveniente modernizar el sistema por etapas en lugar de reemplazarlo completamente.
¿Cuándo conviene migrar?
Una migración puede tener sentido cuando:
- el sistema tiene riesgos estructurales;
- el mantenimiento es demasiado complejo;
- la tecnología ya no acompaña;
- las necesidades del negocio cambiaron;
- la plataforma no puede evolucionar de manera razonable.
La decisión debería realizarse después del relevamiento y no antes.
La importancia de separar recuperación de evolución
Son dos proyectos diferentes.
Recuperar busca asegurar continuidad y control.
Evolucionar busca mejorar funcionalidades y tecnología.
Mezclar ambas cosas puede aumentar el alcance precisamente en el momento donde la empresa necesita reducir incertidumbre.
Checklist de emergencia
Si tu proveedor dejó de responder, revisá inmediatamente:
- ¿tenemos acceso al código?
- ¿tenemos acceso al servidor?
- ¿tenemos acceso a la base de datos?
- ¿existe un backup reciente?
- ¿controlamos el dominio?
- ¿controlamos el DNS?
- ¿qué servicios externos utiliza?
- ¿qué cuentas están a nombre del proveedor?
- ¿qué certificados o licencias vencen?
- ¿existe documentación?
- ¿quién conoce el funcionamiento operativo?
¿Qué no conviene hacer?
- Apagar servidores sin tener backups.
- Actualizar tecnologías sin conocer dependencias.
- Cambiar DNS sin entender la infraestructura.
- Eliminar cuentas antiguas antes de relevar accesos.
- Modificar la base de datos directamente.
- Empezar una reconstrucción completa sin analizar el sistema existente.
Cómo debería quedar la empresa después de recuperar el sistema
El objetivo no debería ser solamente conseguir otro desarrollador.
La empresa debería terminar con mayor control que antes.
Idealmente debería contar con:
- repositorio accesible;
- infraestructura bajo control;
- backups verificados;
- credenciales centralizadas;
- documentación técnica;
- inventario de integraciones;
- procedimiento de recuperación;
- más de una persona con conocimiento crítico.
¿Cómo puede ayudar otro equipo de desarrollo?
Un nuevo equipo puede comenzar sin reemplazar el software existente.
El trabajo inicial puede concentrarse en:
- recuperar accesos;
- relevar arquitectura;
- revisar código;
- asegurar backups;
- documentar infraestructura;
- identificar riesgos;
- estabilizar el sistema.
Después de entender la situación se puede definir si conviene continuar manteniéndolo, modernizar determinadas partes o construir una nueva solución.
En Drimfix trabajamos con desarrollo de software a medida y sistemas empresariales, por lo que un proyecto existente puede evaluarse antes de asumir que todo necesita rehacerse.
Conclusión
Cuando un proveedor de software desaparece, el objetivo inicial no debería ser desarrollar más.
Debería ser recuperar control.
Código, datos, infraestructura, backups, credenciales e integraciones son los activos que permiten que otro equipo pueda continuar trabajando.
Cuanto antes se releven, menor será el riesgo de que una falla técnica transforme un problema de proveedor en un problema operativo.
Y una vez estabilizada la situación, la empresa puede decidir con más información si conviene mantener, modernizar o migrar el sistema.
Preguntas frecuentes
¿Qué hago si mi proveedor de software dejó de responder?
Primero asegurá accesos, código, base de datos, infraestructura y backups. Después conviene realizar un relevamiento técnico antes de hacer modificaciones importantes.
¿Puede otra empresa continuar un software desarrollado por otro proveedor?
Sí. Un nuevo equipo puede analizar el código, infraestructura, datos, integraciones y documentación para determinar cómo asumir el mantenimiento.
¿Qué pasa si no tengo el código fuente?
Hay que investigar si existen copias en repositorios, servidores, backups o equipos anteriores. La posibilidad de recuperar el sistema dependerá de la tecnología utilizada.
¿Qué pasa si el servidor está a nombre del proveedor?
Conviene recuperar acceso y preparar, si es necesario, una migración hacia infraestructura controlada por la empresa.
¿Hay que reemplazar el sistema si desaparece el proveedor?
No necesariamente. Primero conviene recuperar control y evaluar el estado técnico. El sistema puede ser mantenible aunque el proveedor original ya no esté disponible.
¿Qué debería controlar la empresa para evitar este problema?
Código fuente, infraestructura, dominio, base de datos, backups, credenciales, servicios externos y documentación básica del sistema.
¿Se puede recuperar un sistema sin documentación?
Sí, aunque el relevamiento suele requerir más tiempo porque el nuevo equipo debe reconstruir parte del conocimiento analizando código, infraestructura y funcionamiento.
¿Cuál debería ser la primera prioridad?
Preservar la operación y la información: recuperar accesos y generar backups antes de realizar cambios importantes.
