Qué es rescatar un proyecto parado (y por qué no es lo mismo que mantenimiento)
La mayoría de proyectos de tecnología empresarial que se quedan parados no fallan por la tecnología. Fallan por la operación. Alguien construyó algo, nadie lo cuidó, el equipo interno no tuvo tiempo, los responsables cambiaron y el sistema murió silenciosamente. Rescatar un proyecto es exactamente lo contrario de mantenerlo: es devolver a la vida algo que ya está muerto.
Rescate vs. mantenimiento
Mantener significa cuidar un sistema vivo: parches, actualizaciones, mejoras incrementales. Rescatar significa enfrentarse a un sistema que dejó de operar: identificar qué hay, qué funciona, qué se ha roto, qué se ha quedado obsoleto y qué hay que reconstruir. La diferencia de mentalidad es total — y casi ningún proveedor de mantenimiento sabe rescatar.
Por eso «contratar a la consultora siguiente para que retome lo anterior» suele fallar. Las consultoras de mantenimiento parten de la premisa de que el sistema funciona; las de rescate parten de la opuesta. Cada conjunto de herramientas, métodos y expectativas es distinto.
Por qué los proyectos se quedan parados
Cuatro patrones se repiten casi siempre. El primero: la consultora original entregó código y desapareció. El segundo: el equipo interno se redujo y dejó de tener capacidad para operar lo construido. El tercero: cambió la dirección y el nuevo responsable no entiende el sistema. El cuarto: la integración prevista nunca se completó, así que el sistema funciona aislado, sin valor real. Conocer el patrón es la mitad del trabajo de rescatarlo.
Cuándo se rescata un proyecto y cuándo se reconstruye
No todo lo parado es rescatable. A veces el código está demasiado roto, los datos son inservibles o el caso de uso original ya no encaja con la operación actual. Identificar honestamente cuándo rescatar y cuándo reconstruir es el primer entregable de cualquier intervención seria.
Se rescata cuando…
- El código está documentado o es documentable.
- La base de datos contiene información operativa recuperable.
- El caso de uso original sigue siendo relevante para la operación actual.
- La arquitectura es compatible con un stack moderno mantenible.
- Existe alguien (cliente o auditor) que entiende lo suficiente del dominio para validar el resultado del rescate.
Se reconstruye cuando…
- El código depende de versiones obsoletas sin migración viable.
- Los datos están corruptos, dispersos en formatos incompatibles o nunca se llegaron a poblar con información real.
- El proceso operativo ha cambiado tanto que el sistema original ya no encaja.
- La arquitectura usa tecnologías abandonadas por la comunidad y mantenerlas es más caro que rehacerlo.
- El coste estimado del rescate supera el de reconstruir.
Auditoría honesta como condición previa
La decisión «rescatar o reconstruir» no se toma en una llamada comercial. Se toma después de una auditoría técnica que mira el código, los datos, la arquitectura y el encaje operativo. Cualquier propuesta de rescate que no incluya esta fase como entregable cerrado e independiente es una venta a ciegas — y los rescates a ciegas son los que terminan costando el doble y entregando menos.
Tipos de proyectos que se pueden rescatar
El rescate se asocia a menudo con pilotos de IA, pero el método es el mismo para cualquier proyecto de tecnología empresarial parado. Lo común es el patrón de fallo, no la tecnología concreta. Estos son los tipos más frecuentes en el mercado.
Software a medida abandonado
Una aplicación interna, un portal, una herramienta operativa construida por una agencia que ya no responde. El código está en algún repositorio, la base de datos en algún cloud y nadie sabe ya cómo desplegar una nueva versión. El sistema sigue corriendo por inercia, pero cualquier cambio asusta porque podría romperlo todo.
Pilotos de IA que no llegaron a producción
Un agente de IA, una integración con LLM, un sistema de cualificación automática que funcionaba en demos pero nunca se integró al CRM real. El proveedor entregó, hubo cambio de prioridades, los modelos se desactualizaron y el piloto murió. Recuperarlo significa actualizar dependencias, integrar de verdad y desplegar con supervisión operativa.
ERPs y CRMs sin estabilizar
La implantación arrancó hace 6-18 meses, pero nunca se cerró. Hay módulos a medias, datos inconsistentes entre departamentos y procesos que el equipo sigue ejecutando en paralelo en Excel porque «el sistema no termina de funcionar». El rescate consiste en cerrar lo abierto, conciliar datos y dejar la operación corriendo realmente sobre el sistema, no a su lado.
E-commerce o plataformas que perdieron mantenimiento
Una tienda online, un marketplace, una plataforma de servicios que arrancó bien pero lleva 18+ meses sin actualizaciones. Bugs acumulados, integraciones de pago obsoletas, problemas de seguridad. El rescate aquí es estabilizar, modernizar las dependencias críticas y dejar la plataforma operativa antes de tomar decisiones sobre su futuro.
Sistemas heredados de una M&A
Una adquisición trae consigo un stack tecnológico que el comprador no construyó. Hay sistemas críticos para el día a día sobre los que el equipo nuevo no tiene visibilidad. El rescate aquí empieza por entender — qué hay, cómo funciona, qué riesgos hay — antes de decidir conservar, refactorizar o sustituir.
Transformaciones digitales detenidas
Un proyecto de transformación que arrancó con consultora externa, presupuesto generoso y mucha presentación de PowerPoint — y que a los 12-18 meses está donde estaba. La causa raíz no suele ser técnica; suele ser organizativa. Rescatar aquí es identificar qué partes son recuperables, qué decisiones operativas pendientes están bloqueando el avance y qué intervención mínima desbloquea el resto.
La metodología de rescate en cuatro fases
Un rescate bien hecho tiene cuatro fases — y cada una se cierra antes de empezar la siguiente. Saltarse el orden es la fuente principal de rescates que terminan costando el doble.
Fase 1 — Auditoría técnica y de viabilidad (2 semanas)
Revisar qué se construyó, cómo está integrado, qué datos genera, si es operable y bajo qué condiciones. Entregable: diagnóstico honesto con tres veredictos posibles — viable de rescatar, parcialmente viable, o reconstruir desde cero. Esta fase tiene coste cerrado independiente: el cliente puede decidir no continuar tras ella y llevarse el informe.
Fase 2 — Plan de rescate (1 semana)
Roadmap concreto con los ajustes técnicos necesarios, mejoras de integración, plan de puesta en producción y dimensionamiento de la operación continua posterior. Entregable: plan ejecutable que puede aplicarse con el equipo de Nexus o con cualquier equipo técnico competente. El roadmap es del cliente, no del rescatador.
Fase 3 — Ejecución del rescate (4-8 semanas)
Re-implantar lo que haga falta, integrar con el stack real, dejar el sistema operando y documentado. Cada semana hay entregables verificables, no demos: módulos que funcionan en producción con datos reales. La duración depende del estado de partida — un piloto de IA con código limpio puede cerrar en 4 semanas; un ERP con 18 meses de inconsistencias necesitará 8.
Fase 4 — Operación supervisada continua (recurrente)
Rescatado el sistema, hay que mantenerlo vivo. La operación continua incluye supervisión técnica, evolución funcional, ajustes de agentes de IA cuando aplica y soporte senior. Es la diferencia entre rescatar y mantener vivo: sin esta fase, el sistema vuelve a su muerte original en 12-18 meses. El cliente puede asumir esta fase internamente si su equipo está listo — pero hay que decidirlo conscientemente, no por defecto.
Duración total típica
Entre 7 y 11 semanas para las fases 1-3. La fase 4 arranca cuando termina la 3 y es recurrente. Cualquier propuesta significativamente más corta (2-3 semanas para todo) suele significar saltarse la auditoría — y eso es precisamente lo que llevó al sistema al cementerio la primera vez.
Errores típicos al intentar rescatar un proyecto
La mayoría de rescates fallidos repiten los mismos errores. Conocerlos sirve para evaluar las propuestas que recibas — incluyendo la nuestra.
Error 1: empezar a tocar código antes de auditar
La presión por «ir rápido» lleva a saltarse la fase de auditoría y empezar a corregir lo que aparenta estar roto. Resultado típico: dos meses después, alguien descubre un problema estructural que invalida lo arreglado. Una semana de auditoría ahorra dos meses de retrabajo.
Error 2: forzar rescates inviables
A veces el sistema no se puede rescatar — y eso hay que decirlo. Las consultoras que aceptan cualquier rescate, lo cobren o no, terminan entregando algo que funciona en demos pero falla en producción. La honestidad de «no es viable, reconstruir es más barato» es lo que distingue un rescate serio de una venta forzada.
Error 3: rescatar sin operación continua después
Rescatar un sistema y entregárselo al cliente sin un plan de operación es repetir el mismo error que lo llevó al cementerio la primera vez. El sistema rescatado vuelve a quedarse parado a los 12 meses. La operación continua post-rescate no es venta cruzada: es la condición de que el rescate sirva para algo.
Error 4: no documentar lo rescatado
El rescate sin documentación es deuda técnica acumulada. Si el rescatador es el único que entiende cómo quedó el sistema, has cambiado un vendor lock-in por otro. La documentación operativa, arquitectónica y de procesos es entregable obligatorio — no opcional.
Error 5: pelearse con la consultora anterior
Algunos rescates incluyen disputas legales o técnicas con el proveedor original: quién tiene los repositorios, quién es el dueño del código, quién pagó qué. Eso es trabajo de abogados, no de rescatadores. Un rescate serio trabaja sobre el código y la documentación que el cliente ya tiene, sin entrar en peleas que no resuelve.
Cuando lo parado no es un proyecto, es la empresa entera
A veces el fallo no afecta solo a un proyecto: paraliza una operación o una vía de negocio completa. Una implantación de software fallida que congeló la facturación. Una migración de ERP que rompió la logística. Un e-commerce que perdió sus datos y opera ahora en Excel. En esos casos, rescatar el proyecto no basta — hay que coordinar la recuperación de la operación.
El combo auditoría → rescate → reconstrucción
Para empresas con la operación entera parada, la entrada es siempre un diagnóstico estratégico completo: mapea la operación al completo — no solo el proyecto fallido — para identificar qué áreas siguen vivas, cuáles sangran, qué datos son recuperables y qué decisiones no pueden esperar. Con ese mapa se decide qué piezas se intervienen y en qué orden.
A continuación, el rescate actúa sobre las piezas rotas — el proyecto fallido, el sistema abandonado, los datos huérfanos — y las devuelve a un estado operativo estable y documentado. Cuando el diagnóstico confirma que el problema estructural es más profundo, la salida es reconstruir la operación como software a medida orquestado por agentes de IA supervisados.
Lo que NO es rescate de empresas
Rescate de proyectos no es turnaround financiero, restructuring concursal ni asesoría legal: esas son disciplinas distintas con profesionales especializados. Si el problema de la empresa es de tesorería, deuda o procedimiento concursal, lo correcto es trabajar con abogados y consultores financieros. Si el problema es tecnológico u operativo, encajamos.
El orden importa
La regla básica en rescates a escala empresa: nunca empezar por el módulo más doloroso. Empezar por el módulo más crítico — el que está bloqueando al resto. Eso suele ser distinto de lo que la dirección percibe como prioridad. La auditoría existe precisamente para identificar la diferencia entre lo urgente percibido y lo verdaderamente crítico.