Rescate de software inconcluso
¿Te dejaron un sistema a medias? Primero revisamos qué se puede rescatar
Ya invertiste tiempo y dinero, y lo que tienes no funciona como debería o quedó a la mitad. Antes de decirte que hay que empezar desde cero, revisamos lo que ya existe: código fuente, base de datos, servidor e infraestructura, para saber con claridad qué conviene hacer.
01 · El sistema que quedó a la mitad
Un desarrollo detenido, dinero invertido y desconfianza real
Un proveedor anterior desapareció, dejó de responder o entregó un sistema con errores y sin terminar. Ahora tienes código que no entiendes, poca o ninguna documentación y la sensación de que cualquier decisión puede significar perder lo que ya se pagó.
El miedo más común no es técnico: es volver a invertir en algo que termine igual. Por eso empezamos por entender qué hay, no por vender una reconstrucción completa.
Lo que buscamos que sientas
- Que alguien entienda tu sistema antes de opinar sobre él.
- Que la decisión se base en evidencia, no en un diagnóstico apresurado.
- Que lo que ya se pagó no se descarte sin revisarlo primero.
Situaciones frecuentes
- Proveedor que desaparecióSin contacto, sin soporte y sin explicación de cómo sigue.
- Desarrollo con erroresFunciona a medias o falla en partes críticas del proceso.
- Sin documentaciónNadie dejó explicado cómo está construido el sistema.
Ninguna de estas situaciones impide revisar el sistema y definir una ruta.
Antes de proponer nada
Qué se revisa en el diagnóstico
No empezamos diciendo «hay que rehacerlo». Primero se entiende qué existe y en qué estado está; solo entonces se puede decir qué conviene conservar, corregir o reemplazar.
Código fuente
Revisamos qué existe, cómo está organizado, dependencias, versiones y qué tan viable es continuar sobre esa base.
Base de datos
Analizamos estructura, consistencia, relaciones, respaldos y qué información necesita protegerse antes de cualquier cambio.
Servidor e infraestructura
Revisamos dónde vive el sistema, cómo se publica, qué servicios utiliza y qué riesgos existen en su entorno actual.
Integraciones
Identificamos conexiones con ERP, APIs, servicios externos, archivos, correos, almacenamiento y otros sistemas que dependen de él.
Situaciones con las que suele llegar la gente
El proveedor anterior ya no responde
No hay soporte o nadie conoce bien el sistema.
El sistema quedó a medias
Hay funciones importantes sin terminar o procesos que nunca quedaron completos.
Es software legado difícil de tocar
Tecnología antigua, poca documentación o demasiadas dependencias.
No sabes si conviene rescatarlo
Existe incertidumbre sobre mantener, mejorar, migrar o reconstruir.
No sabes dónde quedó el código fuente
Puede estar con el proveedor anterior, en un servidor o repartido entre distintas versiones. Primero determinamos qué accesos y activos existen.
No necesitas tener todo perfectamente organizado para empezar la conversación: parte del trabajo es determinar qué accesos y qué activos existen todavía.
El resultado de la revisión
Cuatro rutas posibles, no una sola respuesta genérica
Después de revisar tu sistema, clasificamos cada parte y te explicamos por qué.
- ConservarPartes que ya funcionan bien y no necesitan tocarse.
- CorregirPartes con errores puntuales que se pueden arreglar sin rehacerlas.
- CompletarPartes que quedaron sin terminar y siguen el mismo camino.
- ReemplazarPartes que conviene reconstruir, cuando así lo justifica la revisión.
No prometemos que todo se pueda rescatar. Lo que sí garantizamos es que la decisión se toma después de revisar tu sistema real, no antes.
Cómo lo abordamos
Primero entender lo que existe, después decidir
No opinamos sobre un sistema que no hemos visto. El proceso empieza por revisarlo a fondo.
- 01
Nos cuentas tu situación
Qué tienes, qué funciona, qué no, y qué te preocupa de seguir con este sistema.
- 02
Revisamos código y base de datos
Cómo está construido, qué tan consistente es la información y qué tan lejos está de su objetivo.
- 03
Revisamos infraestructura
Dónde vive el sistema, qué integraciones tiene y qué necesita para seguir operando.
- 04
Clasificamos cada parte
Conservar, corregir, completar o reemplazar, con la razón detrás de cada decisión.
- 05
Definimos una ruta razonable
Qué conviene atender primero y qué alcance tiene sentido para tu situación.
- 06
Retomamos el desarrollo
Con la ruta acordada, seguimos construyendo sobre lo que ya existe.
Punto de entrada
El diagnóstico es un entregable, no una cortesía previa
Cuando un sistema quedó a medias, la decisión difícil no es técnica: es no saber qué tienes. Por eso el primer paso no es una propuesta de desarrollo, es un diagnóstico del sistema existente con alcance y plazo cerrados antes de empezar.
Sale un documento con lo que encontramos, lo que se puede conservar y qué implica cada camino. Ese documento es tuyo. Si decides no continuar con nosotros, te sirve igual para hablar con cualquier otro proveedor, o para saber que lo que tienes está mejor de lo que creías.
Y si el trabajo continúa, no damos nada por terminado sin comparar: el comportamiento nuevo se contrasta contra el que ya existía, y las diferencias se explican. Así entramos a un sistema que no construimos. Si lo que quedó a medias es una implementación de ERP, el caso más frecuente tiene su propia ruta: rescatar una implementación de Odoo.
Qué contiene el diagnóstico
- Qué existeInventario de lo que hay: código, base de datos, accesos, servicios y dónde está hospedado.
- Qué funciona hoyProbado ejecutándolo, no supuesto leyendo el código.
- Qué faltaRespecto de lo que el sistema debía hacer, no respecto de un ideal.
- De qué dependeLibrerías, servicios de terceros, licencias, integraciones y quién controla cada acceso.
- Qué te puede detenerLos riesgos concretos que pueden parar la operación, y qué tan probable es cada uno.
- Qué se puede conservarCada parte clasificada en conservar, corregir, completar o reemplazar, con su razón.
- AlternativasLos caminos posibles y qué implica cada uno en esfuerzo, riesgo y tiempo.
- Siguiente paso recomendadoCuál conviene atender primero y por qué ese y no otro.
No prometemos que todo se pueda rescatar. Si lo que encontramos es que conviene rehacer, el diagnóstico lo dice con esa claridad y con lo que lo sostiene.
02 · Ejemplo demostrativo
Un sistema web a medias, sin documentación
Imagina un sistema web construido para gestionar pedidos, con la parte de captura terminada pero sin el módulo de reportes, sin documentación y sin acceso al desarrollador original. La revisión encuentra una base de datos consistente y un código organizado, aunque incompleto.
Qué podría salir de un caso así
- Conservar la captura de pedidos, que ya funciona.
- Corregir un par de validaciones que fallan en casos específicos.
- Completar el módulo de reportes que quedó sin construir.
Ejemplo demostrativo · caso ficticio
- Código fuenteOrganizado, sin documentación, con un módulo sin terminar.
- Base de datosConsistente, sin corrupción de información.
- Conclusión de la revisiónConviene continuar, no reconstruir desde cero.
Ejemplo demostrativo con fines ilustrativos. No corresponde a una implementación real ni a un cliente de HazloSistema.
Alcance y límites reales
No todo se puede rescatar, y te lo decimos con claridad
La revisión inicial nos permite decirte qué es viable, sin comprometer un alcance a ciegas.
Con qué solemos poder trabajar
Tecnologías con las que tenemos experiencia.
- Sistemas web construidos en .NET o JavaScript.
- Frontends en Vue, React o Next.js.
- Bases de datos SQL Server, PostgreSQL o HANA.
- APIs, integraciones y sistemas legacy.
Lo que depende de la revisión
Antes de comprometer alcance o tiempos.
- Qué tan accesible es el código y la base de datos.
- Qué tan consistente está la información existente.
- Si hay accesos a servidor o infraestructura disponibles.
- Qué tan lejos está el sistema de cumplir su objetivo original.
No prometemos que cualquier sistema se pueda rescatar sin verlo primero. Cuando la revisión concluye que conviene reemplazar una parte, te lo decimos con la razón detrás de esa conclusión, no como una salida fácil.
Preguntas frecuentes
Lo que preguntan antes de enseñarnos su sistema
Sí. Antes de decirte que hay que empezar desde cero, revisamos lo que ya tienes: código fuente, base de datos, servidor y lo que esté disponible. La mayoría de las veces algo se puede conservar, aunque lo haya construido otro equipo.
No siempre. Depende de qué tan sólido esté lo que ya existe. Después de la revisión te decimos, con evidencia concreta, qué conviene conservar, corregir, completar o reemplazar; empezar de cero es una posibilidad, no el punto de partida.
Idealmente el código fuente, acceso a la base de datos y algo de contexto sobre qué funciona, qué no y qué quedó a medias. Si te falta alguna de estas piezas, dínoslo: muchas veces también se puede recuperar acceso o reconstruir parte de lo que falta.
Sí. La falta de documentación es común en desarrollos inconclusos. Revisamos el código y la base de datos directamente para entender cómo está construido el sistema, aunque no exista un documento que lo explique.
Es una situación frecuente y no impide avanzar. Trabajamos con lo que exista: código, accesos y cualquier rastro disponible del sistema, sin necesitar contacto con el desarrollador anterior.
Revisando el código, la arquitectura, la base de datos y qué tan lejos está de cumplir su objetivo. Clasificamos cada parte del sistema en conservar, corregir, completar o reemplazar, y te explicamos el porqué de cada clasificación.
El siguiente paso
Cuéntanos qué tienes, aunque no esté completo
Si te dejaron un sistema a medias, sin documentación o sin proveedor que responda, podemos revisarlo y decirte con claridad qué se puede rescatar y qué conviene hacer. Sin compromiso.
HazloSistema desarrolla e integra software alrededor de la operación real de cada empresa. Revisamos tu sistema antes de proponer cualquier ruta, sin prometer resultados sin haberlo visto.