Cuatro proyectos parados que se repiten
Un proyecto parado casi nunca está parado del todo. Sigue corriendo por inercia, alguien lo alimenta a mano y nadie se atreve a tocarlo. En nuestra guía de rescate de proyectos parados describimos los cuatro casos que más se ven en empresas de 20 a 500 empleados.
El ERP o CRM que nunca se cerró
La implantación arrancó hace entre 6 y 18 meses. Hay módulos a medias, datos que no cuadran entre departamentos y un equipo que sigue en Excel «hasta que el sistema funcione». No va a funcionar solo. El problema no es el software: es una migración que se quedó a medio camino, y en el blog explicamos cómo retomar una migración inacabada de ERP o CRM sin romper el negocio.
La plataforma o el e-commerce sin mantenimiento
Arrancó bien. Lleva más de 18 meses sin actualizaciones: pasarela de pago con una versión antigua, dependencias con avisos de seguridad y errores que se acumulan porque cambiar algo da miedo. Vende, pero nadie sabe hasta cuándo. Si además ha dejado de vender por cómo te encuentran y no solo por el código, eso ya no es un rescate técnico: es un problema de crecimiento empresarial y se analiza con la empresa entera delante.
La transformación digital con consultora
Presupuesto generoso, muchas presentaciones y, a los 12-18 meses, la operación está donde estaba. La causa rara vez es técnica. Suele ser una decisión que nadie tomó.
El piloto de IA que no llegó a producción
Funcionaba en la demo. Nunca se integró con el CRM real, cambiaron las prioridades y los modelos que usaba quedaron desfasados. Hemos escrito sobre por qué fracasan los proyectos de IA en las empresas y sobre cómo evaluar la viabilidad de un proyecto de IA que lleva meses parado. El patrón es siempre el mismo: se construyó algo y nadie lo cuidó.
Hay un quinto caso que no es un tipo de proyecto sino una forma de heredarlo: el stack técnico que llega con una adquisición. Para eso tenemos una guía para el CTO que hereda un stack técnico tras una operación de M&A.
Las primeras 72 horas cuando el proveedor desaparece
Deja de llamarle. Lo que necesitas ahora no es una explicación: es asegurar lo que todavía controlas. En esas 72 horas se decide cuánto va a costar el rescate; después, cada semana lo encarece. El orden importa, y lo detallamos en el artículo sobre las decisiones de las primeras 72 horas cuando un proveedor abandona el proyecto.
- Código. ¿Dónde está el repositorio y quién es el propietario de la cuenta? Si la respuesta es «en el GitHub de la agencia», pide hoy una copia completa con historial, ramas y la etiqueta del último despliegue en producción. Sin historial no hay auditoría.
- Accesos. Dominio, DNS, hosting, cloud, base de datos, pasarela de pagos, cuentas de servicios externos y claves de API. Cambia las contraseñas que puedas y anota las que no. Cada credencial que sigue en manos del proveedor es una dependencia.
- Datos. Una copia de la base de datos de producción, hoy, y verificada: que se pueda restaurar en otro sitio. Una copia que nadie ha restaurado nunca no es una copia.
- Documentación. Todo lo que exista, aunque sea poco: actas, correos, tickets, diagramas, el documento de requisitos original. Sirve para saber qué se prometió y qué se construyó.
- Contratos. Lee la cláusula de propiedad intelectual antes de escribir a nadie. Quién es dueño del código, qué se entregó formalmente y qué queda pendiente de pago condiciona lo que puedes hacer con lo que tienes.
Eso es todo en 72 horas. Nada de tocar código. Nada de pedir presupuestos. Primero, el sistema en tus manos.
Rescatar, reconstruir o cerrar: se decide con datos
Hay tres salidas y las tres son legítimas. Lo que no es legítimo es elegir una sin haber mirado el código, los datos y el encaje con la operación actual. Por eso la auditoría va antes que cualquier propuesta, incluida la nuestra.
Se rescata cuando el código es documentable, la base de datos guarda información recuperable, el caso de uso sigue vigente y la arquitectura aguanta un stack mantenible. Se reconstruye cuando depende de versiones sin migración viable, los datos nunca se poblaron con información real o el proceso cambió tanto que el sistema ya no encaja; en ese caso la salida es software a medida, escrito desde cero para tu empresa y con el código en tu propiedad. Se cierra cuando ni lo uno ni lo otro devuelve más de lo que cuesta. Cerrar bien un proyecto también es un entregable.
La falacia del coste hundido
Lo que ya has pagado no es un argumento. Es un apunte contable. Un proyecto en el que se invirtió mucho no merece más rescate que uno pequeño; merece la misma pregunta: ¿qué devuelve a partir de hoy y cuánto cuesta llegar ahí? Si la respuesta es reconstruir, lo pagado sigue siendo lo mismo lo reconstruyas o no. Pocas decisiones de dirección cuestan tanto como negarse a mirar esto.
Las cuatro fases y sus plazos
Un rescate serio tiene cuatro fases y cada una se cierra antes de abrir la siguiente. Los plazos son los que publicamos en la guía de rescate y en la guía paso a paso para rescatar un proyecto de software parado.
| Fase | Plazo | Qué obtienes |
|---|---|---|
| 1. Auditoría técnica y de viabilidad | 2 semanas | Qué se construyó, cómo está integrado, qué datos genera y si es operable. Veredicto: rescatar, reconstruir o cerrar. |
| 2. Decisión y plan | 1 semana | Plan ejecutable con los ajustes técnicos, la integración y la puesta en producción. Es tuyo: lo puede ejecutar cualquier equipo competente. |
| 3. Ejecución del rescate | 4-8 semanas | Sistema reimplantado, integrado con tu stack real, operando y documentado. Entregables semanales en producción, no demos. |
| 4. Transferencia y operación | Recurrente | Conocimiento transferido a tu equipo, supervisión técnica y evolución. Sin ella, el sistema vuelve a pararse en 12-18 meses. |
Entre 7 y 11 semanas para las fases 1 a 3. Un piloto de IA con código limpio puede cerrarse en 4 semanas de ejecución; un ERP con 18 meses de inconsistencias necesita 8.
Por qué desconfiar de una propuesta de 2-3 semanas
Porque no cabe. Una propuesta que promete todo en dos o tres semanas se ha saltado la auditoría, y saltarse la auditoría es exactamente lo que dejó el sistema donde está. Una semana de auditoría ahorra dos meses de retrabajo. Quien te diga lo contrario vende horas, no un sistema que funcione.
Deuda técnica: refactorizar o reescribir
Todo proyecto heredado llega con deuda técnica. La pregunta no es si la tiene, sino si conviene pagarla poco a poco o cancelarla de golpe. Refactorizar mantiene el sistema en producción mientras se corrige por dentro; reescribir sustituye piezas enteras. Ninguna de las dos es mejor en abstracto. En nuestro artículo sobre deuda técnica en proyectos heredados: refactorizar o reescribir desarrollamos los criterios; aquí van los tres que más pesan.
- Si el núcleo del sistema es legible y se le pueden escribir pruebas, se refactoriza. El coste se reparte y la operación no se detiene.
- Si una pieza depende de tecnologías que ya nadie mantiene, se reescribe esa pieza y solo esa. Reescribir todo porque una parte está mal es la forma más cara de sentirse a salvo.
- Si nadie de tu empresa puede desplegar una versión nueva sin miedo, lo primero no es refactorizar ni reescribir: es recuperar el control del despliegue. Todo lo demás espera.
¿Quién en tu empresa puede subir hoy una versión a producción? Si la respuesta es un nombre de fuera, ya sabes por dónde empieza el rescate.
Qué cuesta y cuánto tarda
No publicamos un precio de rescate porque no existe uno honesto antes de mirar. Lo que sí podemos decirte es cómo se presupuesta cada fase.
La auditoría se presupuesta como lo que es: una auditoría técnica. En nuestro artículo sobre auditorías de IA publicamos que una auditoría boutique de 4-8 días de trabajo se mueve entre 2.500 y 5.000 €, y en el mercado español se ven cifras parecidas. Tiene coste cerrado e independiente: puedes parar ahí, llevarte el informe y ejecutarlo con quien quieras. Si pagas bastante menos, recibes un cuestionario procesado, no un diagnóstico.
La ejecución se presupuesta después de la auditoría. Antes sería mentirte. Para que tengas una referencia y no un precio: en nuestra guía de software a medida publicamos que, para una empresa B2B de 30-80 empleados que necesita sustituir 2-3 piezas críticas de su stack, una primera fase razonable está entre 40.000 y 120.000 €, y que mantener vivo el sistema ronda los 5.000-15.000 € al mes según complejidad. Un rescate puede quedar por debajo de esas cifras porque parte de algo ya construido, o por encima si hay que deshacer lo mal hecho. Cuál de las dos es tu caso es justo lo que la auditoría responde. El desglose completo está en cuánto cuesta el software a medida.
Y una cosa más que conviene tener delante al decidir: cerrar mal un proyecto también tiene precio. Los datos que se pierden al apagar un sistema sin plan se pagan después, en la migración al siguiente.
Lo que te va a exigir
Un rescate no lo hace solo el equipo que rescata. Hay tres cosas que dependen de ti.
- Acceso total desde el primer día. Código, servidores, base de datos, contratos y las personas que usan el sistema. Una auditoría con acceso parcial devuelve un veredicto parcial, y ese lo pagas dos veces.
- Decidir rápido. El informe de la fase 1 acaba en tres opciones y una recomendación. Cada semana que pasa en un cajón, el sistema sigue degradándose y tu equipo sigue en Excel.
- Aceptar que algo se tire. Habrá módulos, integraciones o datos que no merezcan seguir vivos aunque se pagaran. Guardarlos «por si acaso» es la deuda técnica de mañana.
Si alguna de las tres no la puedes garantizar, mejor saberlo antes de la auditoría que después.
Cómo empezamos
Día 0: NDA firmado antes de que nos enseñes nada. Después, el equipo de Nexus mira el código, los datos y cómo está integrado con tu operación; no un junior con una lista de comprobación. Recibes un informe con el veredicto y los cambios exactos, priorizados por impacto en tu cuenta de resultados. Y tú decides: rescatar, reconstruir, cerrar o seguir con quien quieras. Trabajamos con un máximo de siete clientes simultáneos; si te encaja, solicita admisión y te respondemos en 24 horas laborables.
Preguntas frecuentes
¿Se puede rescatar un proyecto de software si el proveedor no entrega el código?
Depende de lo que tengas. Si el sistema está desplegado en servidores que controlas, casi siempre se puede extraer lo que corre en producción, aunque sin historial la auditoría es más lenta. Si solo tienes la base de datos, se rescatan los datos y se reconstruye el resto. Lo primero es leer la cláusula de propiedad intelectual del contrato: quién es dueño del código condiciona lo que puedes hacer. La disputa con el proveedor es trabajo de abogados, no del rescate.
¿Cuánto cuesta rescatar un proyecto de software parado?
No hay un precio cerrado antes de mirar. La auditoría se presupuesta como una auditoría técnica: en nuestro artículo sobre auditorías publicamos que una boutique de 4-8 días se mueve entre 2.500 y 5.000 €, con coste independiente y el informe en tu propiedad. La ejecución se presupuesta después. Como referencia, en nuestra guía de software a medida publicamos entre 40.000 y 120.000 € para una primera fase de sistema nuevo; un rescate puede quedar por debajo o por encima según lo que haya que deshacer.
¿Cuánto se tarda en retomar una implantación de ERP parada?
Entre 7 y 11 semanas para auditoría, plan y ejecución, según los plazos que publicamos en nuestra guía de rescate. Un ERP con 18 meses de inconsistencias entre departamentos suele necesitar las 8 semanas de ejecución completas, porque hay que conciliar datos antes de cerrar módulos. Después viene la transferencia a tu equipo, que es lo que evita que el sistema vuelva a pararse en 12-18 meses. Si alguien te promete todo en 2-3 semanas, se está saltando la auditoría.
¿Es mejor terminar un desarrollo a medias o empezar de cero?
Se decide con datos, no con lo que ya has pagado. Se termina cuando el código es documentable, los datos son recuperables y el caso de uso sigue vigente. Se empieza de cero cuando depende de tecnologías sin migración viable, los datos nunca se poblaron con información real o el proceso cambió tanto que el sistema ya no encaja. Una auditoría de dos semanas responde a esa pregunta con el código delante. Sin ella, cualquiera de las dos opciones es una apuesta.
¿Qué hago con un proyecto de IA que lleva meses parado?
Primero, asegura el código, los accesos y los datos que generó; sin eso no hay nada que evaluar. Después, una auditoría de viabilidad: qué modelos usa, si siguen disponibles, con qué sistemas debía integrarse y si el caso de uso sigue teniendo sentido para tu operación. Un piloto con código limpio puede cerrarse en 4 semanas de ejecución. Uno que solo funcionó en la demo y nunca tocó el CRM real muchas veces conviene reconstruirlo sobre lo aprendido.
¿Qué pasa si la auditoría concluye que no es viable rescatar el proyecto?
Te lo decimos por escrito, con los motivos, y el informe es tuyo. Ahí puedes decidir reconstruir con nosotros, con otro equipo o cerrar el proyecto y recuperar los datos que valgan. La auditoría tiene coste cerrado e independiente precisamente para eso: no obliga a continuar. Un rescate que acepta cualquier proyecto, viable o no, acaba entregando algo que funciona en demos y falla en producción. Decir «no» a tiempo es parte del servicio.