Una empresa necesita cambiar de proveedor, el equipo interno que desarrollaba el producto se ha marchado o un proyecto lleva meses detenido y alguien debe retomarlo. La petición al nuevo equipo parece sencilla: revisar el código, calcular cuánto falta y presentar un presupuesto para continuar.
El repositorio existe. También hay una lista de funcionalidades pendientes, varios documentos y una aplicación que, al menos en determinadas condiciones, funciona. Desde fuera puede parecer que el trabajo consiste en familiarizarse con la tecnología y empezar a resolver tareas.
Sin embargo, el código solo explica una parte del proyecto. No indica necesariamente quién controla la infraestructura, cómo se despliega una versión, qué datos son fiables, por qué existen determinadas reglas, qué compromisos se comunicaron a clientes o qué proveedor mantiene una pieza esencial del sistema.
También puede describir correctamente lo que se construyó hace meses y no lo que el negocio necesita ahora. El proyecto pudo cambiar de alcance, acumular soluciones provisionales o depender de procesos manuales que nunca llegaron al repositorio.
Heredar un desarrollo exige recuperar el control, el contexto y la capacidad de tomar decisiones. Leer el código forma parte de ese trabajo, pero resulta insuficiente para prometer fechas, cerrar un presupuesto o decidir qué debe hacerse a continuación.
Por qué un proyecto cambia cuando pasa a otro equipo
El equipo anterior no solo escribía código. También conservaba una interpretación del producto: qué partes eran prioritarias, qué incidencias podían esperar, qué excepciones aceptaba el negocio, cómo se publicaban los cambios y con quién había que hablar cuando un servicio externo fallaba.
Parte de ese conocimiento estará documentado. Otra parte aparecerá dispersa entre conversaciones, tickets, correos, hojas de cálculo y decisiones que nunca se registraron formalmente. También habrá información que cada persona considera evidente porque lleva meses trabajando con ella.
Cuando cambia el equipo, ese contexto deja de estar disponible de forma automática. El nuevo proveedor puede acceder al código y seguir sin saber:
- Qué funcionalidades utiliza realmente la empresa.
- Qué procesos del negocio dependen del sistema.
- Qué partes están terminadas y cuáles solo parecen estarlo.
- Qué errores se conocen y cómo se resuelven actualmente.
- Qué decisiones técnicas responden a una restricción real.
- Qué promesas comerciales o contractuales condicionan el roadmap.
El takeover debe convertir ese conocimiento disperso en una visión verificable del proyecto. Hasta entonces, cualquier estimación estará construida sobre supuestos que todavía no se han comprobado.
La primera capa: activos, propiedad y accesos
Antes de analizar la calidad del código hay que comprobar si la empresa controla los activos necesarios para operar el sistema. Un repositorio completo sirve de poco si nadie puede acceder al servidor de producción, renovar el dominio, administrar la base de datos o recuperar una cuenta externa.
La revisión debería identificar, como mínimo:
- Repositorios de código y ramas utilizadas.
- Servidores, alojamiento y servicios en la nube.
- Dominios, DNS y certificados.
- Bases de datos y sistemas de almacenamiento.
- Cuentas de correo transaccional, pagos, analítica y monitorización.
- API, integraciones y credenciales de terceros.
- Licencias, suscripciones y cuentas de facturación.
- Copias de seguridad y mecanismos de recuperación.
Para cada activo hay que saber quién es su titular, quién puede administrarlo, cómo se recupera el acceso y qué ocurriría si el proveedor anterior dejara de colaborar ese mismo día. También conviene distinguir qué pertenece al cliente, qué depende de una licencia y qué componente solo puede utilizarse bajo determinadas condiciones.
En algunos proyectos, las cuentas se crearon desde correos personales del equipo anterior o dentro de una organización compartida con otros clientes. En otros, el cliente paga el servicio, pero no tiene permisos para administrarlo. Resolver estas dependencias puede ser más urgente que añadir cualquier funcionalidad.
La segunda capa: arquitectura e infraestructura
Una vez recuperados los activos, hay que entender cómo funciona el sistema en conjunto. El repositorio puede contener una aplicación y dejar fuera trabajos programados, configuraciones del servidor, integraciones creadas directamente en una plataforma externa o procesos que se ejecutan desde otra herramienta.
La revisión debe identificar los componentes, sus dependencias y la forma en que intercambian información. También debe comprobar cómo se separan los entornos de desarrollo, pruebas y producción, cómo se configura cada uno y qué pasos permiten publicar una versión.
Algunas preguntas iniciales son especialmente reveladoras:
- ¿Puede el proyecto instalarse y ejecutarse fuera del equipo de quien lo desarrolló?
- ¿Las dependencias y variables necesarias están identificadas?
- ¿Existe un procedimiento de despliegue que pueda repetir otra persona?
- ¿Es posible revertir una publicación si algo falla?
- ¿Dónde se registran los errores y quién recibe las alertas?
- ¿Las copias de seguridad pueden restaurarse?
- ¿Qué componentes están obsoletos o próximos a dejar de recibir soporte?
El objetivo todavía no es rediseñar la arquitectura. Primero hay que saber qué existe, qué sostiene la producción y qué cambios podrían provocar una interrupción. Una mejora técnicamente razonable puede ser una mala primera decisión si afecta a una dependencia que aún no se conoce.
La tercera capa: lógica de negocio y procesos reales
El código muestra reglas, validaciones y cálculos, pero no siempre explica por qué existen. Una condición que parece redundante puede responder a una restricción contractual. Un campo que nunca se utiliza en la interfaz puede alimentar un informe externo. Una tarea manual puede compensar una excepción que el sistema no contempla.
Por eso la revisión necesita combinar la lectura técnica con conversaciones con las personas que utilizan y operan el producto. Hay que seguir los procesos principales de principio a fin y comparar lo que debería ocurrir con lo que ocurre realmente.
Esta capa incluye preguntas como:
- ¿Qué problema del negocio resuelve cada flujo importante?
- ¿Quién inicia el proceso y quién necesita su resultado?
- ¿Qué decisiones toma el sistema y cuáles toma una persona?
- ¿Qué excepciones aparecen con frecuencia?
- ¿Qué tareas se completan fuera de la aplicación?
- ¿Qué información se corrige en Excel, correo u otras herramientas?
- ¿Qué partes del sistema son críticas para ventas, facturación, servicio u operaciones?
Sin esta información, el nuevo equipo corre el riesgo de corregir algo que el negocio considera necesario, conservar una solución temporal como si fuera definitiva o estimar una funcionalidad sin conocer todos los procesos que afecta.
La cuarta capa: datos, migraciones y fuentes de verdad
Los datos suelen conservar una parte de la historia que no aparece en la documentación. Tablas duplicadas, campos incompletos, estados que ya no se utilizan o relaciones inconsistentes pueden mostrar cambios de dirección, migraciones parciales y procesos que evolucionaron sin actualizar todo el modelo.
Antes de modificar la estructura o prometer una migración hay que conocer el volumen, la calidad y el uso de esos datos. También hay que decidir qué sistema actúa como fuente de verdad cuando la información aparece en varias plataformas.
La revisión debería comprobar:
- Qué información contiene cada sistema.
- Qué datos son personales, confidenciales o críticos.
- Qué reglas de validación se aplican al crearlos o modificarlos.
- Qué procesos los sincronizan con otras plataformas.
- Qué inconsistencias o duplicidades se conocen.
- Qué históricos deben conservarse.
- Cómo se realizan las copias y restauraciones.
- Qué consecuencias tendría alterar el modelo actual.
Una aplicación puede compilar correctamente y seguir teniendo un problema grave de datos. También puede contener información válida dentro de una estructura difícil de evolucionar. Son situaciones distintas y exigen decisiones diferentes.
La quinta capa: calidad, seguridad y capacidad de cambio
Revisar un proyecto heredado no consiste en puntuar el estilo del equipo anterior. El objetivo es determinar con qué nivel de confianza puede modificarse el sistema.
Las pruebas automatizadas ayudan, pero su ausencia no demuestra por sí sola que todo deba reescribirse. Hay que comprobar qué partes críticas están cubiertas, qué comportamientos pueden validarse de otra manera y qué riesgo implica cambiar cada componente.
La revisión también debe observar la gestión de errores, los permisos, las dependencias externas, las actualizaciones pendientes y la exposición de información sensible. Conviene entender cómo se conceden los accesos, dónde se almacenan las credenciales y qué trazabilidad existe sobre acciones importantes.
Algunas áreas necesitarán pruebas antes de tocarlas. Otras requerirán documentar primero su comportamiento actual. En determinados casos será necesario estabilizar una parte del sistema antes de continuar con el backlog.
El resultado debería explicar qué puede cambiarse con seguridad, qué necesita protección adicional y qué zonas acumulan una incertidumbre que debe reducirse antes de estimar nuevos desarrollos.
La sexta capa: backlog, incidencias y compromisos existentes
Un listado de tareas pendientes no siempre refleja el estado real del proyecto. Puede mezclar errores, mejoras, ideas, compromisos comerciales y solicitudes que perdieron prioridad. También puede dar por terminadas funcionalidades que nunca se validaron en producción.
Antes de utilizar ese backlog como base para un presupuesto, hay que revisar:
- Qué tareas siguen siendo necesarias.
- Qué requisitos tienen criterios de aceptación claros.
- Qué incidencias afectan actualmente a usuarios u operaciones.
- Qué elementos dependen de otros cambios todavía no contemplados.
- Qué compromisos se han comunicado y a quién.
- Qué fechas responden a una obligación real.
- Qué trabajo está iniciado y en qué estado se encuentra.
Una tarea descrita como «terminar la integración con el ERP» puede esconder decisiones sobre datos, reintentos, permisos, facturación y gestión de errores. Otra denominada «corregir el formulario» puede afectar a varias versiones, idiomas o sistemas conectados.
El nuevo equipo necesita reconstruir el alcance antes de convertir el backlog en calendario. De lo contrario, la estimación parecerá precisa porque contiene horas o fechas, pero seguirá basada en definiciones incompletas.
La séptima capa: personas, proveedores y conocimiento concentrado
Los sistemas dependen de personas y empresas que no aparecen en el repositorio. Puede haber un proveedor que gestiona la infraestructura, una persona de administración que corrige los datos, un especialista externo que mantiene una integración o un cliente que valida cada cambio antes de publicarlo.
El takeover debe identificar quién conoce cada parte, qué responsabilidad tiene y qué disponibilidad puede ofrecer durante la transición. Cuando sea posible, conviene hablar con el equipo saliente y plantear preguntas concretas sobre riesgos, incidencias frecuentes, procedimientos y decisiones pendientes.
La conversación resulta más útil cuando busca hechos que cuando se convierte en una valoración sobre si el proyecto está «bien» o «mal». Qué cambiarían primero, qué parte evitarían tocar sin pruebas, qué proceso genera más incidencias o qué depende de una sola persona suelen ser preguntas más productivas.
También hay que revisar contratos, licencias, niveles de soporte y servicios prestados por terceros. Un componente técnicamente estable puede convertirse en riesgo si el acuerdo está a punto de terminar o si el nuevo equipo no puede acceder al proveedor que lo mantiene.
Por qué no conviene prometer una fecha o un presupuesto cerrado al principio
La empresa necesita previsibilidad y el nuevo proveedor necesita definir el alcance de su responsabilidad. Es comprensible que se solicite una fecha y un presupuesto desde la primera conversación. El problema aparece cuando se presenta una cifra cerrada antes de verificar los activos, la arquitectura, los datos y el backlog.
Para ofrecer esa cifra, el proveedor tendría que asumir que la documentación está actualizada, el código puede ejecutarse, los accesos existen, las tareas están bien definidas y las dependencias son las esperadas. Si alguno de esos supuestos falla, solo quedan tres opciones: ampliar el presupuesto, reducir el alcance o absorber un coste que acabará afectando a la relación y a la calidad del trabajo.
Una estimación prematura crea riesgo para ambas partes. El cliente puede tomar decisiones con una cifra que no representa el estado real del sistema. El proveedor puede comprometerse con un trabajo que todavía no puede dimensionar.
Es posible ofrecer un marco inicial, un alcance para la evaluación y, cuando existe suficiente información, rangos condicionados. El presupuesto detallado y el calendario del siguiente tramo deberían construirse con las evidencias obtenidas durante el diagnóstico.
Qué debe entregar la fase inicial de takeover
La evaluación no debería terminar con una descripción genérica del código. Tiene que producir información que permita decidir y actuar.
Entre sus resultados deberían estar:
- Un inventario de activos, accesos y responsables.
- Un mapa de componentes, sistemas e integraciones.
- Una descripción de los procesos críticos y su relación con la tecnología.
- Los principales riesgos técnicos, operativos y de continuidad.
- Las incidencias que necesitan estabilización inmediata.
- Una revisión del backlog y de los compromisos existentes.
- Las dependencias de personas, proveedores y licencias.
- Una propuesta priorizada para estabilizar, mantener y evolucionar el sistema.
- Los supuestos y límites utilizados para preparar la siguiente estimación.
No todos los proyectos necesitarán un informe extenso. Sí necesitan una visión compartida del punto de partida y una explicación clara de qué se conoce, qué sigue siendo incierto y qué debe ocurrir antes de acelerar el desarrollo.
Estabilizar antes de acelerar
La empresa puede llegar al cambio de proveedor con funcionalidades urgentes, clientes esperando y un equipo cansado de retrasos. La presión para empezar a construir de inmediato es real. Sin embargo, añadir cambios a un sistema que todavía no puede desplegarse, observarse o recuperarse con seguridad aumenta la fragilidad.
La primera prioridad puede consistir en recuperar accesos, comprobar las copias, documentar el despliegue, corregir una incidencia crítica o añadir trazabilidad. Estas tareas no siempre producen una funcionalidad visible, pero crean las condiciones para que el trabajo posterior sea más predecible.
Estabilizar tampoco significa detener durante meses cualquier evolución. Es posible atender necesidades urgentes mientras se reduce la incertidumbre, siempre que se diferencie el trabajo imprescindible de los cambios que pueden esperar a comprender mejor el sistema.
La secuencia adecuada depende del riesgo: controlar primero aquello que podría interrumpir la operación, perder datos o bloquear al equipo, y avanzar después sobre las funcionalidades con una base más fiable.
Continuar, modernizar o reconstruir
Un proyecto heredado no tiene que reescribirse automáticamente. Incluso un sistema con problemas puede contener años de lógica de negocio, integraciones y excepciones que costaría reproducir. Empezar de cero también crea riesgos: migración de datos, convivencia entre versiones, pérdida de comportamientos útiles y un periodo prolongado antes de alcanzar la funcionalidad existente.
En otros casos, seguir añadiendo cambios puede resultar poco sostenible. La tecnología puede carecer de soporte, la arquitectura impedir evoluciones necesarias o el coste de verificar cualquier modificación ser demasiado elevado.
La decisión debe basarse en evidencias. Hay que comparar la criticidad de cada componente, su estado, el coste de mantenerlo, la capacidad de probarlo y las necesidades futuras del negocio. El resultado puede ser continuar como está, estabilizar, modernizar por partes, sustituir algunos componentes o preparar una reconstrucción controlada.
La evaluación inicial no necesita resolver todo el futuro del producto, pero sí evitar que una preferencia técnica se convierta en estrategia antes de comprender el sistema.
Qué puede preparar la empresa antes del cambio de equipo
La transición será más eficiente si la empresa reúne la información disponible antes de que llegue el nuevo proveedor. No hace falta esperar a tener una documentación perfecta.
Conviene localizar:
- Contratos, presupuestos y alcances anteriores.
- Repositorios, cuentas y credenciales administradoras.
- Facturas de infraestructura, licencias y servicios externos.
- Backlogs, incidencias y documentación funcional.
- Diagramas, manuales y procedimientos de despliegue.
- Copias de seguridad y políticas de recuperación.
- Personas que conocen la operación diaria.
- Compromisos asumidos con clientes, usuarios o dirección.
También ayuda preparar una explicación honesta de por qué se produce el cambio. No es lo mismo asumir un producto estable por una reorganización que recuperar un desarrollo detenido tras meses de conflicto. El contexto permite priorizar mejor las primeras comprobaciones.
Heredar un proyecto es recuperar la capacidad de decidir
El takeover termina cuando el nuevo equipo puede entender, operar y modificar el sistema con un nivel de riesgo conocido. Para llegar ahí necesita más que acceso al código: necesita control de los activos, comprensión de la arquitectura, conocimiento de los procesos, visibilidad sobre los datos y claridad sobre las responsabilidades.
En Pibeca asumimos y evolucionamos plataformas y productos digitales construidos por otros equipos. Cuando el proyecto incluye CRM, ERP, ecommerce u otros sistemas empresariales, también revisamos sus integraciones y automatizaciones como parte de la operación completa.
Si necesitas cambiar de proveedor, recuperar un desarrollo detenido o entender el estado real de una plataforma antes de seguir invirtiendo, podemos empezar con una conversación de diagnóstico.
La primera promesa responsable no es una fecha exacta. Es explicar qué hay que revisar para convertir un proyecto heredado en un sistema que pueda volver a avanzar con control.
Preguntas frecuentes sobre cómo heredar un proyecto de software
¿Qué necesita un nuevo equipo para asumir un proyecto de software?
Necesita acceso al código, la infraestructura, los datos, los servicios externos y la documentación disponible. También debe conocer los objetivos actuales, los procesos de negocio, las incidencias, el backlog, los compromisos asumidos y las personas o proveedores que intervienen en la operación.
¿Cuánto se tarda en evaluar un proyecto heredado?
Depende del tamaño, la criticidad, la documentación, el número de sistemas conectados y la disponibilidad de accesos y personas. Una plataforma pequeña y bien documentada puede revisarse con rapidez. Un sistema crítico con varias integraciones, datos sensibles y conocimiento disperso exige una evaluación más profunda. El alcance del diagnóstico debe definirse antes de comenzar.
¿Puede darse un presupuesto cerrado antes de revisar el código?
Puede presupuestarse la fase de evaluación si su alcance está definido. Cerrar el presupuesto de todo el desarrollo antes de revisar código, infraestructura, datos y backlog obliga a trabajar con demasiados supuestos. Después del diagnóstico se puede preparar una estimación mejor fundamentada y especificar qué incertidumbres permanecen.
¿Es imprescindible colaborar con el proveedor anterior?
No siempre, pero una transición ordenada puede ahorrar tiempo y recuperar contexto importante. Si el proveedor anterior no está disponible, el proyecto aún puede asumirse utilizando el código, la infraestructura, la documentación, los datos y el conocimiento de los usuarios. La falta de traspaso debe incluirse como un riesgo de la evaluación.
¿Hay que reescribir un proyecto desarrollado por otro equipo?
No necesariamente. Primero hay que determinar qué partes funcionan, cuáles pueden evolucionar con seguridad y dónde se concentra el riesgo. La mejor opción puede ser continuar, estabilizar, modernizar gradualmente, sustituir componentes concretos o reconstruir. Reescribir todo sin evaluar también puede perder lógica de negocio y crear nuevos riesgos.
¿Qué debe revisarse primero si el proyecto está en producción?
Los accesos, la infraestructura, las copias de seguridad, el despliegue, la monitorización y las incidencias que puedan afectar a la operación o a los datos. Después se puede profundizar en arquitectura, calidad, backlog y evolución. La prioridad inicial es asegurar que el sistema puede mantenerse y recuperarse mientras se completa el diagnóstico.
