Cómo entregar una aplicación a otro equipo sin depender del desarrollador

Publicado el 2026-11-14 por frfrand

Checklist de repositorios, documentación, secretos, infraestructura, CI/CD, acceso y pruebas para un traspaso de software.

# Cómo entregar una aplicación a otro equipo sin depender del desarrollador

Un proyecto no está completamente entregado si el cliente tiene una URL funcionando pero no puede recuperar el código, cambiar credenciales o reconstruir el despliegue. La transferencia debe demostrar que un equipo distinto puede operar y mantener el sistema sin depender de la memoria del autor.

1. Propiedad y repositorios

Entrega acceso apropiado al repositorio Git bajo una organización controlada por el propietario. Identifica rama de producción, versión/tag entregada, licencias y dependencias. Incluye instrucciones de git clone, instalación, ejecución de tests y build. Confirma que el histórico no contenga secretos; si hubo filtraciones, rota credenciales, no basta con borrar el último commit.

2. Documentación mínima

| Documento | Contenido | | --- | --- | | README | Objetivo, arranque local, comandos, tests | | Arquitectura | Servicios, API, DB, colas y dependencias | | Infraestructura | Dominios, DNS, VPS, proxy y almacenamiento | | Runbook | Deploy, reinicio, health checks, rollback | | Datos | Esquemas, migraciones, backups y restauración | | Operación | Incidentes conocidos, alertas y contactos |

Documenta decisiones difíciles y limitaciones conocidas; no conviertas el README en un manual enorme imposible de actualizar.

3. Accesos sin compartir contraseñas

Usa roles por persona y credenciales individuales en GitHub, hosting, DNS, base de datos, proveedor de email y servicios de terceros. Un gestor de secretos facilita transferencias; no entregues un archivo .env real por correo o chat. Aplica mínimo privilegio, rota credenciales tras el relevo y revoca tokens del equipo saliente una vez que el nuevo tenga control verificado.

4. Transferencia de datos y despliegue

Prepara un backup recuperable y un procedimiento probado de restauración. Documenta cómo desplegar una versión nueva desde Git, ejecutar migraciones, comprobar salud, consultar logs y regresar a una versión compatible. Si el sistema procesa pagos o datos personales, define una ventana de transición y tareas de supervisión. Evita transferir datos innecesarios o sensibles sin autorización.

5. Prueba de independencia

El nuevo equipo debe poder, por sí mismo: 1. Clonar, instalar dependencias y ejecutar tests. 2. Desplegar una corrección pequeña en staging. 3. Localizar logs y métricas de una incidencia simulada. 4. Restaurar una copia en infraestructura de ensayo.

Registra evidencia de cada paso y anota bloqueos. La entrega se acepta cuando esas pruebas están superadas y el propietario confirma recepción de recursos esenciales.

6. Transición y cierre

Define período de apoyo, responsabilidades y procedimientos para preguntas posteriores. Transfiere cuentas de facturación y titularidad de dominios cuando correspondan. Entrega inventario final de componentes, licencias, costes recurrentes, riesgos pendientes y documentación. Desactiva accesos antiguos solo después de verificar que la operación no depende de ellos.

Relacionados: qué es CI/CD y migraciones de base de datos.

Preguntas frecuentes

¿Basta entregar un ZIP? No. ¿Es obligatorio entregar secretos en texto plano? No, se transfieren controles de acceso seguros. ¿Cómo verifico la entrega? Con una prueba operativa ejecutada por el nuevo equipo.