La respuesta corta
Cambiar de agencia de desarrollo no falla por el código. Falla por las llaves: cuentas, certificados, secretos y accesos que están a nombre de la agencia saliente y que nadie pidió el primer día.
Un traspaso limpio es una lista de artefactos entregados y verificados, no una reunión de traspaso de conocimiento. Si al terminar puedes compilar, firmar y publicar una versión sin llamar a nadie de la agencia anterior, el traspaso está hecho. Si no, no lo está — aunque el correo diga lo contrario.
Esta es la lista, en el orden en que hay que pedirla.
Antes de anunciar nada
Dos cosas, y las dos antes de comunicar la decisión:
- Inventario de a nombre de quién está cada cosa. Cuentas de desarrollador, repositorio, dominios, DNS, servicios de terceros, gestor de secretos.
- Revisar el contrato: preaviso, obligaciones de traspaso, propiedad del código y qué pasa con el mantenimiento durante la transición.
Hacerlo después reduce tu capacidad de negociación exactamente cuando más la necesitas.
Bloque 1 · Las llaves
Sin esto no hay traspaso, hay una copia del código.
- Cuenta de Apple Developer a nombre del cliente, con el rol de Account Holder en una persona de la empresa.
- Cuenta de Google Play con propiedad transferida o confirmada.
- Certificados de distribución y llaves privadas, con inventario de fechas de caducidad.
- Keystore de Android y confirmación de si hay Play App Signing activado.
- Claves de API de App Store Connect y de Play Developer API.
- Certificados de push, o las claves si se usan claves.
Si algo de esto está a nombre de la agencia, lo que toca no es una entrega: es una transferencia de app con todo lo que arrastra — aquí está lo que se rompe y aquí por qué la custodia importa tanto.
Bloque 2 · Código e histórico
- Repositorio completo con todo el histórico, no un zip del último commit. El histórico es documentación: dice por qué las cosas son como son.
- Todas las ramas y etiquetas, incluidas las de las versiones publicadas.
- Transferencia de la propiedad del repositorio a la organización del cliente, no una copia.
- Dependencias privadas: paquetes internos, registros privados, submódulos. Es lo que más se olvida y lo que rompe la primera compilación.
- Ficheros de configuración de firma y de entornos que no estén en el repositorio.
Bloque 3 · Que compile sin ellos
Esta es la prueba real, y hay que hacerla antes de que la agencia saliente se vaya, no después.
- Un desarrollador que no ha tocado el proyecto clona, compila y ejecuta siguiendo la documentación.
- Genera una build de release firmada.
- La sube a TestFlight o a un canal de pruebas interno.
- Documenta cada paso en el que ha tenido que preguntar. Esa lista es lo que falta por entregar.
Si la prueba se hace después de la salida, cualquier hueco se convierte en una negociación de horas extra con quien ya no tiene incentivo.
Bloque 4 · Infraestructura y servicios
- Backend: acceso a la nube, con el titular de la cuenta confirmado y la facturación a nombre del cliente.
- Base de datos: copias de seguridad, política de retención y prueba de restauración.
- CI/CD: pipelines, secretos y quién es el propietario de la organización en la herramienta.
- Servicios de terceros: analítica, notificaciones, crash reporting, pasarela de pago, correo transaccional. Uno por uno, con el correo de administración cambiado.
- Gestor de secretos con todo dentro, y los secretos rotados después del traspaso. Esto es innegociable: gente que ya no trabaja para ti no debe conservar credenciales vivas.
Bloque 5 · Producto y conocimiento
- Diseño: ficheros fuente editables y sistema de diseño, no exportaciones.
- Fichas de las tiendas: textos, capturas y assets en sus originales.
- Documentación de arquitectura y decisiones: aunque sea escueta, lo que hay.
- Backlog e incidencias abiertas, con su histórico.
- Contactos y contratos de los proveedores implicados.
Bloque 6 · Lo que se rota el día después
- Secretos y claves de API.
- Accesos de personas de la agencia saliente en todas las herramientas.
- Contraseñas compartidas, si las hubiera — y si las hay, ese es otro problema.
- Webhooks y automatizaciones apuntando a sistemas de la agencia.
Este último punto se olvida siempre y es el que provoca los fallos raros semanas después: una automatización que sigue viva en la cuenta de otro.
Cómo se comporta cada parte
Un traspaso puede ser tenso o profesional, y depende bastante de cómo se plantea.
Del lado del cliente: pagar lo pactado, dar un preaviso razonable y no pedir trabajo nuevo durante la transición.
Del lado de la agencia saliente: entregar sin fricción. El sector es pequeño y una salida limpia es la mejor carta de recomendación que existe.
Del lado de la agencia entrante: no criticar el trabajo anterior. Casi siempre las decisiones que parecen absurdas tenían un contexto —un plazo, un presupuesto, una restricción del cliente— que no está en el código. Y quien entra criticando, sale criticado.
La señal de que el traspaso está terminado
No es un correo de conformidad. Es esto: has publicado una versión en producción sin que nadie de la agencia anterior participe. Hasta ese momento, el traspaso está en curso.
Si estás en ese punto y quieres una lectura independiente del estado real de lo que vas a heredar, es lo que hacemos en una auditoría técnica de app móvil.
