Traspaso de proyecto de software: checklist para recibirlo bien

Cambiar de agencia de desarrollo es una decisión normal: la relación se ha desgastado, el proveedor ya no da abasto o simplemente necesitas otro tipo de equipo. Lo que no es normal, aunque pasa a menudo, es que el cambio se haga sin un traspaso de proyecto de software ordenado y la empresa descubra meses después que le faltan contraseñas, código o información para seguir.

La respuesta corta: antes de cerrar la relación con el proveedor anterior, asegúrate de que tu empresa controla las cuentas (dominio, servidor, repositorio y servicios externos), tiene una copia completa del código y de los datos que alguien ha restaurado con éxito, dispone de documentación mínima para desplegar y mantener la aplicación, y ha acordado un periodo de transición en el que el proveedor saliente responde dudas.

En este artículo tienes la checklist completa, en el orden en que conviene recorrerla, y cómo comprobar cada punto aunque no tengas perfil técnico.

¿Qué es un traspaso de proyecto de software?

Un traspaso de proyecto de software es el proceso por el que una aplicación pasa de manos de un proveedor a otro (o al equipo interno de la empresa) sin perder accesos, datos ni conocimiento. Incluye entregar cuentas y contraseñas, el código fuente, la base de datos, la documentación y el contexto que solo tiene quien ha trabajado en el proyecto.

No es lo mismo que el caso de un proveedor de software que ha desaparecido. Aquí el proveedor anterior sigue localizable y, en principio, colabora. Es la mejor situación posible para cambiar de manos, y conviene aprovecharla: todo lo que no se pida ahora será mucho más difícil de conseguir después.

¿Cuándo hay que empezar a preparar el traspaso?

Hay que empezar antes de comunicar la decisión o, como muy tarde, en ese mismo momento, y siempre antes de que termine el contrato o se deje de pagar al proveedor. Mientras la relación está activa, el proveedor tiene un motivo para colaborar y tú tienes margen para revisar lo que te entrega.

Un orden razonable:

1. Revisa el contrato antes de anunciar nada: propiedad del código, obligaciones de entrega y plazos de preaviso.
2. Prepara la lista de lo que necesitas (la checklist de abajo).
3. Comunica el cambio y propón un calendario de traspaso con fechas concretas.
4. Recibe y comprueba cada entrega con quien vaya a hacerse cargo.
5. Cierra la relación solo cuando la checklist esté completa.

Checklist del traspaso: qué pedir al proveedor saliente

Esta es la lista de lo que tu empresa debería tener al terminar. No hace falta entender cada elemento técnicamente: basta con saber que existe, dónde está y que el acceso es vuestro.

1. Cuentas y accesos a nombre de tu empresa

• Dominio: registrado a nombre de la empresa, con acceso al panel del registrador.
• Servidor o hosting: cuenta de la empresa, con acceso de administración y la facturación a vuestro nombre.
• Repositorio de código (GitHub, GitLab, Bitbucket…): en una cuenta u organización de la empresa, no en la personal del desarrollador.
• Servicios externos: pasarela de pago, envío de correos, mapas, almacenamiento, APIs de terceros, tiendas de aplicaciones si hay app móvil.
• Correo electrónico y cualquier cuenta que reciba avisos técnicos (caducidades, alertas, facturas).

La regla es sencilla: si una cuenta solo la conoce el proveedor, en la práctica es suya. Cuando tengas cada acceso, cambia las contraseñas y retira los permisos del proveedor saliente cuando termine la transición.

2. Código fuente completo y actualizado

• El código de la versión que está funcionando hoy, no de una versión antigua.
• El historial de cambios del repositorio, si existe: ayuda a entender por qué se hizo cada cosa.
• Las librerías o componentes propios del proveedor que use la aplicación, o al menos sus licencias de uso.
• Cualquier aplicación relacionada: panel de administración, app móvil, scripts de tareas automáticas.

3. Datos y copias de seguridad

• Una copia completa de la base de datos y de los archivos que suben los usuarios (documentos, imágenes, facturas).
• Dónde se hacen las copias automáticas, cada cuánto y quién las vigila.
• Una prueba de restauración: que el nuevo equipo monte la aplicación a partir de esas copias en otro entorno. Es la única forma de saber que la copia sirve.

4. Documentación mínima

No esperes un manual perfecto: muchos proyectos tienen poca documentación. Pide, como mínimo:

• Cómo se despliega una nueva versión (los pasos para pasar un cambio a producción).
• Cómo se monta un entorno de pruebas desde cero.
• La lista de servicios externos y credenciales (entregadas por un canal seguro, no por correo en texto plano).
• Las tareas programadas: procesos que se ejecutan solos (cierres diarios, envíos, sincronizaciones).
• Los problemas conocidos y los "trucos" que solo sabe el equipo saliente.

5. Contexto del proyecto

• Qué hay a medio hacer y en qué estado está.
• Errores abiertos o incidencias recurrentes.
• Decisiones técnicas importantes y por qué se tomaron.
• Quién de tu empresa usa cada parte de la aplicación y para qué.

¿Cómo compruebas que lo que te entregan está completo?

La forma más fiable de comprobarlo es que el nuevo equipo reproduzca la aplicación por su cuenta: con el código y las copias entregadas, montar una versión en un entorno de pruebas y desplegar un cambio pequeño. Si lo consigue sin preguntar nada al proveedor anterior, el traspaso está completo. Si se atasca, lo que falta aparece enseguida.

Otras comprobaciones útiles, aunque no seas técnico:

• Entra tú mismo en cada cuenta (dominio, hosting, repositorio, pagos) con tu propio usuario.
• Compara fechas: el último cambio del repositorio debería coincidir, más o menos, con la última modificación que conoces de la aplicación.
• Pregunta por lo que no aparece: si sabes que existe una app móvil o una integración con tu ERP y no está en la entrega, falta algo.

Si tienes dudas sobre la calidad de lo recibido o sobre si merece la pena seguir con esa base, una auditoría técnica de software al inicio te da un punto de partida objetivo, tanto para ti como para el nuevo proveedor.

¿Qué dice el contrato sobre la propiedad del código?

El contrato es lo que determina quién es el dueño del código y qué está obligado a entregar el proveedor. Antes de iniciar el traspaso, revisa:

• Propiedad intelectual: si los derechos sobre lo desarrollado se ceden a tu empresa o el proveedor se los reserva y solo te concede una licencia de uso.
• Componentes propios del proveedor: algunas agencias usan una base de código común en varios clientes y no la ceden; conviene saber si podrás seguir usándola.
• Obligación de entrega al terminar la relación: código, documentación, accesos y plazos.
• Datos personales: si el proveedor trataba datos de tus clientes, el contrato de encargado del tratamiento debe prever qué hace con ellos al terminar. El artículo 28 del Reglamento General de Protección de Datos establece que, al finalizar el servicio, el encargado debe suprimir o devolver los datos según decida el responsable.

Si el contrato no es claro o no existe, consúltalo con un abogado antes de comunicar el cambio. Este artículo no sustituye a un asesoramiento legal.

¿Qué suele salir mal en un traspaso?

Los problemas más habituales no son técnicos, sino de orden y de tiempo:

¿Qué hacer en las primeras semanas con el nuevo proveedor?

Las primeras semanas el objetivo es conocer el sistema y asegurarlo, no mejorarlo. Un nuevo proveedor serio debería empezar por:

1. Revisar lo recibido y señalar lo que falta mientras el anterior todavía responde.
2. Comprobar las copias de seguridad y los accesos.
3. Detectar riesgos urgentes: versiones sin actualizaciones de seguridad, certificados a punto de caducar, errores que afectan a cobros o datos.
4. Proponer un plan, con prioridades claras, antes de tocar funcionalidades.

Si el diagnóstico muestra que la aplicación arrastra problemas de fondo, la decisión pasa a ser otra: reparar, modernizar o rehacer el software legacy. Pero esa decisión se toma con información, no en las primeras semanas.

¿Y si el proveedor saliente no colabora?

Si el proveedor anterior no colabora, prioriza lo que depende de tu empresa: recuperar las cuentas que están a vuestro nombre, hacer una copia de lo que puedas desde ellas y revisar el contrato con un abogado. Muchos registradores de dominio y empresas de hosting tienen procedimientos para acreditar la titularidad.

A partir de ahí, la situación se parece a la de un proveedor que ha desaparecido, y los pasos son los mismos: inventario, accesos, copia y diagnóstico. En nuestro servicio de rescate de software partimos de lo que haya, aunque sea incompleto, y te decimos con claridad qué se puede recuperar.

En resumen

• Un traspaso de proyecto de software se prepara antes de cerrar la relación con el proveedor anterior, no después.
• Lo imprescindible: cuentas a nombre de la empresa, código y datos completos, documentación mínima y un periodo de transición.
• La prueba definitiva es que el nuevo equipo monte y despliegue la aplicación solo con lo entregado.
• Revisa el contrato (propiedad del código y datos personales) y consulta a un abogado si hay dudas.
• Las primeras semanas, estabilizar antes que cambiar.

Si estás pensando en cambiar de proveedor, en AppSolución podemos ayudarte a preparar el traspaso y a recibir el proyecto con la checklist en la mano. Cuéntanos qué tienes y te diremos por dónde empezar.