Cómo cambiar de proveedor de software sin perder el proyecto.

Cambiar de proveedor de desarrollo de software a mitad de un proyecto es una de las operaciones con más riesgo y peor gestionadas del mundo corporativo tecnológico. Las razones para plantear el cambio son variadas y reconocibles: el proveedor actual incumple plazos sistemáticamente, la calidad del código degrada el producto, el equipo que empezó el proyecto ya no está y el que lo continúa no tiene el nivel, las estimaciones son crónicamente optimistas, el escalado ha colapsado la relación, el coste por funcionalidad entregada sube sin razón aparente o simplemente el proveedor no da la talla para la siguiente fase. Pero cambiar sin plan bien estructurado es peligroso: el proveedor actual tiene el código, los accesos, las credenciales productivas, la documentación informal y, en muchos casos, el contexto de negocio acumulado durante meses o años. Si la transición se hace mal, el resultado es semanas o meses de parón, pérdida de funcionalidades no documentadas, compromiso de producción o demanda legal cruzada.

El proceso de transición ordenada que recomendamos en Dribba tiene cuatro fases no negociables: asegurar control (antes de anunciar cambio, documentar el estado actual: qué repositorios existen, qué credenciales tienes, qué datos están en qué servicios, qué contratos vinculan al proveedor actual, qué IP y propiedad intelectual hay en cada artefacto); auditoría técnica del código existente (2-3 semanas, 3.000-10.000€) que evalúa con datos objetivos el estado real del código —no percepciones— y responde la pregunta crítica: ¿vale la pena recuperar este código o es más barato empezar de cero?; plan de transición con solapamiento controlado entre proveedor saliente y entrante donde el saliente documenta y traspasa mientras el entrante se onboarda, asume la operación productiva gradualmente y recibe el conocimiento informal; ejecución y continuidad con el nuevo proveedor operando el producto mientras se corrigen los problemas heredados y se establecen los procesos que eviten repetir los errores con el anterior.

Los elementos críticos a recuperar durante la transición son: código fuente de todas las ramas activas con historial Git completo; credenciales de servicios productivos (cloud, DNS, correo, pagos, analytics, monitoreo); accesos a las stores (App Store Connect, Google Play Console) como propietario principal, no delegado; builds firmadas y certificados; documentación técnica (incluso mínima) de arquitectura, integraciones y flujos; claves de firma y secrets críticos; base de datos productiva con backup verificado; documentación de compliance aplicable; y contexto de negocio no documentado (decisiones pasadas, errores aprendidos, integraciones no obvias). Cada uno de estos elementos tiene su propio protocolo de traspaso y puede tener implicaciones legales o de seguridad si se gestiona mal. En Dribba hemos recuperado proyectos de decenas de proveedores distintos —agencias que no entregaron, freelancers que desaparecieron, equipos internos que se quedaron sin capacidad— y conocemos las trampas.

El tiempo y coste de onboarding a un nuevo proveedor depende del estado de la documentación. Con documentación y accesos completos, un equipo experimentado alcanza productividad plena en 3-6 semanas. Sin documentación —el escenario más frecuente— el proceso lleva 6-10 semanas incluyendo auditoría técnica inicial y plan de continuación. Durante este período, el desarrollo se ralentiza pero no debe pararse; el nuevo proveedor absorbe el producto gradualmente mientras el saliente mantiene la operación. En el 60% de los casos que auditamos en Dribba, recuperar el código existente es más económico que empezar de cero; en el 40% restante, una reescritura parcial o modular es la decisión correcta y la auditoría lo dice con datos. Los presupuestos para la transición misma son modestos (3.000-15.000€ para auditoría + plan), el grueso va al desarrollo posterior. Si estás considerando cambiar de proveedor, no anuncies nada hasta tener el plan: la primera reunión confidencial con Dribba aporta criterio sobre cómo ejecutar la transición con riesgo mínimo.