Cuando termina una construccion
Un buen traspaso permite a tu equipo operar, modificar y recuperar el software desde cuentas que controla. Pide el código y su historial, documentación, pruebas, un proceso de despliegue operativo y acceso a los sistemas necesarios. Antes de aceptar la entrega, encarga al equipo receptor que despliegue y recupere el sistema.
Reservar una call de treinta minutosRespuesta corta
Verifica el traspaso haciendo que tu equipo compile, despliegue y recupere el software con el código, los manuales y las cuentas que controla.
Ideal para
No es para
Como distinguir un traspaso limpio de una trampa de dependencia.
Repos en tu organizacion, con todo el historial de git.
El codigo vive en la cuenta del proveedor, o un zip sin historial.
Las cuentas están bajo control del cliente y las credenciales de servicio se han renovado o rotado.
Las claves y los accesos se quedan con el proveedor.
Tu organización controla las cuentas necesarias de alojamiento, DNS y monitorización, con los roles operativos asignados.
El proveedor es el unico administrador en produccion.
Arquitectura, configuracion y runbooks estan por escrito.
El conocimiento vive en la cabeza del desarrollador original.
Tests automatizados y un pipeline que puedes ejecutar tu mismo.
Sin tests, o despliegues que solo el proveedor puede disparar.
Cualquier equipo competente puede asumirlo.
Solo el constructor original puede cambiar algo.
El equipo receptor debería poder desplegar y recuperar el software sin los desarrolladores originales.
Entregamos el código y su historial en tus repositorios, junto con documentación, manuales operativos, pruebas y un proceso de despliegue. Acordad quién controla cada cuenta de producción y cómo desplegará el equipo receptor, recuperará el servicio y cambiará de proveedor. En un servicio gestionado, el acceso puede limitarse a tu propio entorno. Documenta esos límites, cómo exportar los datos y quién autoriza los cambios.
Pide a alguien que no haya construido el sistema que parta de una copia nueva del repositorio en la organización del cliente. Con el manual operativo, esa persona compila, ejecuta las pruebas, despliega en un entorno seguro y verifica que una alerta llegue a la nueva persona de guardia. Restaurad una copia en un entorno aislado y comprobad registros representativos y un recorrido de usuario clave. Registrad el tiempo de recuperación y la pérdida de datos que habría supuesto. Comparad ambos con los objetivos acordados. Guía de AWS Well-Architected sobre pruebas de recuperación.
Una transferencia de repositorio puede arrastrar configuraciones pendientes de revisar. GitHub, por ejemplo, conserva los webhooks, los secretos y las claves de despliegue asociados. Revisa también los ejecutores externos, los registros de paquetes y las identidades de despliegue. Renueva o rota las credenciales en las cuentas del cliente, pruébalas y revoca los accesos sustituidos. Anota quién se ocupa de renovaciones, facturación, licencias y servicios externos que el software siga necesitando. Documentación de GitHub sobre transferencia de repositorios.
La checklist de aceptación de pipelines ayuda a acordar métricas, conciliación, datos tardíos, repeticiones seguras y responsabilidad de los informes.
Confirma cada uno de estos antes de aceptar el traspaso.
Marca los puntos a medida que avanzas. No se guarda ni se envía nada.
Estos casos describen productos que llegaron a producción. Usa el ensayo para verificar tu propio traspaso.
Plataforma AR-RWA: $2M+ recaudados a través del producto, 1.000+ usuarios concurrentes, seis semanas exactas.
Plataforma EdTech nativa de IA, de 0 a producción en 6 semanas bajo presión de mercado comprimida.
Estos son proyectos seleccionados, no nuestro portfolio completo. Hemos entregado más de 100 productos desde 2018.
Si no puedes operar tu software sin las personas que lo construyeron, aun no eres su dueno.