Cambiar de proveedor, retomar un software tras la salida de un desarrollador clave o recuperar una aplicación adquirida no consiste solo en transferir un repositorio Git. Una aplicación en producción depende de un conjunto mucho más amplio: cuentas en la nube, certificados, tareas programadas, respaldos, servicios de terceros, procedimientos de operación, conocimiento del negocio y decisiones históricas.
Las primeras semanas determinan la calidad de la relación futura. Un equipo que comienza inmediatamente a desarrollar nuevas funciones sin asegurar este entorno corre el riesgo de descubrir las dependencias en el momento menos favorable: durante un incidente o una puesta en producción.
El método de los 90 días tiene como objetivo retomar el control sin inmovilizar innecesariamente el producto. Combina aseguramiento, comprensión, estabilización y construcción de una hoja de ruta.
Antes de la transferencia: definir lo que realmente debe entregarse
La reversibilidad debe ser preparada antes de la fecha de cambio. La primera lista concierne a los activos: código fuente, historial, tickets, documentación, esquemas, archivos de diseño, pruebas, scripts de despliegue, imágenes de contenedores y licencias.
La segunda concierne a los accesos: alojamiento, DNS, certificados, base de datos, almacenamiento, correo electrónico transaccional, herramientas de supervisión, CDN, registros de paquetes, cuentas móviles, tiendas de aplicaciones, servicios de pago, plataformas analíticas y copias de seguridad. Para cada acceso, es necesario conocer al propietario legal, los administradores, el modo de recuperación y el proceso de rotación.
La tercera se refiere al funcionamiento del negocio. ¿Qué procesos no pueden ser interrumpidos? ¿Qué operaciones requieren tratamiento manual? ¿Qué intercambios se esperan de los socios? ¿Qué incidentes se repiten? ¿Qué compromisos se han asumido con los usuarios?
Un inventario incompleto no siempre impide la reapertura. Sin embargo, convierte las zonas faltantes en riesgos explícitos y en tareas prioritarias.
Fase 1 — D0 a D15: asegurar y hacer observable
El primer paso no consiste en « limpiar el código ». Consiste en asegurarse de que la aplicación pueda ser observada, respaldada y recuperada.
El equipo confirma los accesos, retira las cuentas obsoletas, activa la autenticación reforzada cuando es posible y organiza la rotación de los secretos. Verifica las copias de seguridad, su retención y sobre todo la posibilidad de restauración. Recensa los certificados y suscripciones que podrían expirar silenciosamente.
Paralelamente, ella reconstruye el camino de puesta en producción: construcción, configuración, migraciones de base, despliegue, purga de cachés, reinicio de trabajadores y retroceso. Una primera ejecución debe realizarse en un entorno no productivo. Si este camino no es reproducible, toda evolución se clasifica temporalmente como riesgosa.
La supervisión debe cubrir las señales esenciales: disponibilidad, tasa de error, tiempo de respuesta, saturación, espacio en disco, colas, fallo de tareas planificadas y estado de las copias de seguridad. El objetivo no es instalar inmediatamente una plataforma compleja, sino evitar que un incidente sea descubierto por el cliente final.
Entregables de la fase: inventario de los accesos, lista de riesgos inmediatos, procedimiento de contacto, prueba de respaldo, mapa simplificado de la operación y primer tablero de control.
Fase 2 — Día 15 a Día 45: comprender y documentar
Una vez asegurada la continuidad mínima, el equipo recompone la arquitectura y las principales reglas de negocio. Instala el proyecto en un entorno limpio, ejecuta las pruebas, observa los registros y sigue algunas solicitudes reales de principio a fin.
Las entrevistas son cortas y específicas. La labor describe las operaciones críticas y las excepciones. El antiguo proveedor, cuando está disponible, explica las áreas sensibles, los procedimientos no documentados y las elecciones que parecen extrañas sin su contexto. La explotación describe los incidentes recurrentes y las manipulaciones manuales.
El código se analiza según las nueve dimensiones de una auditoría técnica: arquitectura, mantenibilidad, dependencias, seguridad, datos, rendimiento, pruebas, explotación y transferibilidad. El objetivo no es aún corregir cada defecto, sino saber dónde una modificación es segura y dónde requiere protecciones adicionales.
La documentación producida debe ser útil de inmediato: inicio local, arquitectura, flujos externos, procedimientos de despliegue, restauración, tareas planificadas, matriz de entornos y glosario de negocio. Una documentación exhaustiva pero nunca revisada es menos útil que una guía corta verificada por una persona nueva.
Entregables de la fase: cartografía, guía de inicio, registro de dependencias, auditoría inicial y lista de incógnitas restantes.
Fase 3 — Día 45 a Día 90: estabilizar y restaurar la capacidad de evolución
La tercera fase trata los riesgos que impiden trabajar normalmente. Las correcciones prioritarias generalmente se refieren a las copias de seguridad, permisos, dependencias vulnerables, errores silenciosos, tareas inestables y procedimientos de despliegue.
Los recorridos profesionales más sensibles están protegidos por pruebas de caracterización. Estas pruebas describen el comportamiento actual, incluso cuando el código aún no es ideal. Luego permiten modificar gradualmente sin reinventar las reglas.
El equipo también construye una estrategia de actualización. Las dependencias se clasifican entre actualizaciones simples, migraciones a preparar y componentes a reemplazar. Las mejoras de rendimiento se basan en mediciones. Las solicitudes funcionales pendientes se reclasifican a la luz de las nuevas restricciones técnicas.
Finalmente, las partes interesadas validan una hoja de ruta en tres horizontes: aseguramiento, modernización y evolución del producto. Cada proyecto especifica su beneficio, su riesgo, sus dependencias y su orden de magnitud.
Entregables de la fase: versión estabilizada, cobertura de pruebas prioritaria, canal de entrega fiable, lista de tareas priorizada y hoja de ruta negociable.
Después de 90 días: pasar a mantenimiento controlado
El mantenimiento corriente se basa en un marco visible. Las solicitudes están calificadas, los incidentes tienen un procedimiento, los cambios son rastreables y las versiones están sujetas a una política. Los indicadores se centran en la calidad del servicio, no solo en el número de tickets cerrados.
Un funcionamiento sano sigue en particular: disponibilidad de los caminos críticos, tiempo de detección, tiempo de recuperación, tasa de fallos de los despliegues, antigüedad de las dependencias, cobertura de los caminos de riesgo y volumen de trabajo no planificado.
El conocimiento debe permanecer distribuido. Las revistas, informes, procedimientos probados y rotaciones de guardia evitan recrear una dependencia en una sola persona en el nuevo proveedor.
La cronología comienza antes de la transferencia con el inventario de los activos, los accesos y las reglas de negocio. De J0 a J15, la prioridad es asegurar los accesos, las copias de seguridad, las implementaciones y la supervisión. De J15 a J45, el equipo reconstruye la arquitectura, documenta la operación e identifica los aspectos desconocidos. De J45 a J90, estabiliza los riesgos prioritarios, protege los procesos sensibles mediante pruebas y construye la hoja de ruta. El régimen actual mantiene entonces la calidad del servicio y el conocimiento compartido.
Los escenarios difíciles y la respuesta adecuada
El antiguo proveedor no coopera
Comience por asegurar lo que pertenece al cliente: dominios, cuentas contractuales, datos, depósitos y copias de seguridad. Documente cada elemento que falte y su impacto. Evite las acusaciones técnicas no verificadas; concentre los intercambios en los activos y obligaciones de reversibilidad.
El equipo de recuperación deberá reconstruir una parte del conocimiento a partir del código, las configuraciones, los registros y los usuarios. Este trabajo debe ser planificado como tal, no absorbido silenciosamente en el mantenimiento.
El código no contiene ninguna prueba
Sería imprudente lanzar inmediatamente una refactorización general. Identifiquen los recorridos de alto impacto, capturen su comportamiento actual y agreguen pruebas alrededor de las interfaces estables. Los registros, copias anonimizadas de datos y pruebas de extremo a extremo pueden aportar una primera protección antes de una cobertura más detallada.
El alojamiento no está documentado
Establezca un mapa desde el exterior hacia el interior: DNS, CDN, cortafuegos, equilibradores, servidores, contenedores, bases, almacenamiento, tareas y servicios externos. Verifique las facturas y consolas para identificar los recursos invisibles en el código. No elimine nada sin un período de observación y prueba de inutilidad.
La aplicación ya está experimentando incidentes
Separe el flujo « restablecer el servicio » del flujo « comprender y modernizar ». Establezca una célula de incidentes, prioridades temporales y un congelamiento de cambios no esenciales. Cada incidente debe enriquecer la cartografía y las protecciones en lugar de desencadenar una sucesión de correcciones aisladas.
Lo que el cliente debe conservar al final de la recuperación
Una recuperación exitosa no se mide únicamente por el hecho de que el nuevo proveedor sepa intervenir. El cliente debe recuperar el control de sus activos y de sus decisiones. Debe disponer de un inventario de cuentas, de una documentación mínima verificada, de visibilidad sobre los riesgos, de un procedimiento de salida y de un presupuesto comprensible.
Los entornos deben ser reproducibles, las copias de seguridad restaurables, las puestas en producción trazables y los accesos nominativos. El backlog debe distinguir mantenimiento correctivo, deuda técnica, seguridad, evoluciones y solicitudes de negocio.
El valor de una recuperación progresiva
La tentación es fuerte de aprovechar el cambio de equipo para reescribir todo. Sin embargo, los primeros 90 días a menudo revelan que algunos bloques son fiables, que ciertas reglas de negocio son más complejas de lo anunciado y que las urgencias no se encuentran donde se pensaba.
Una recuperación estructurada preserva lo que funciona, reduce primero los riesgos y crea las condiciones para una modernización racional. Partitech sabe retomar el mantenimiento de proyectos desarrollados por terceros y acompañar su evolución a lo largo del tiempo, desde la auditoría hasta el alojamiento y la externalización de la gestión.
Para enmarcar la transición, comience por una auditoría técnica completa de la aplicación, luego descubra cómo preparar la reversibilidad y el cambio de proveedor. La oferta Mantenimiento, evoluciones y alojamiento y nuestra referencia de plataforma empresarial financiera acompañada a lo largo del tiempo completan este enfoque.
Referencias oficiales
Referencias verificadas el 17 de agosto de 2026 :