Tomar el relevo de un proyecto de software: plan de 30 días
La toma de un proyecto de software es la transferencia controlada de la responsabilidad técnica y operativa de un producto activo a un equipo nuevo. Solo termina cuando el equipo entrante puede compilar, desplegar, observar, revertir y restaurar el sistema sin el proveedor saliente. Recibir un repositorio es una entrada, no la prueba de aceptación.
Esta guía responde a la pregunta de transición: qué hacer antes, durante y después de cambiar de proveedor. Usa la checklist de traspaso de software para la lista completa de artefactos, la guía para elegir una agencia de software para una decisión de compra más amplia y el servicio de toma de software de Wavect cuando necesites un equipo que evalúe y herede la base de código.
¿Debes cambiar de proveedor de software?
Cambia cuando el coste y el riesgo de quedarte superen el coste y el riesgo de la transición. Un hito incumplido no basta. Busca un patrón repetido: releases impredecibles, defectos que regresan sin trabajo de causa raíz, accesos o documentación bajo control del proveedor, riesgos materiales ocultos o incentivos comerciales que ya no encajan con el producto.
| Situación | Primer paso | Por qué |
|---|---|---|
| El equipo es capaz, pero faltan prioridades y responsables | Reiniciar gobierno y derechos de decisión | Otro proveedor heredaría el mismo problema de gestión. |
| La entrega es lenta, pero el sistema es estable y transparente | Hacer una evaluación independiente y acotada | Necesitas evidencia antes de pagar el coste del cambio. |
| Código, cloud o datos siguen en cuentas del proveedor | Planificar salida y recuperación del control | La dependencia operativa ya es un riesgo empresarial. |
| Seguridad, integridad de datos o continuidad están en peligro | Iniciar triaje de emergencia controlado | Contén el riesgo antes de negociar la hoja de ruta. |
No anuncies un corte definitivo antes de revisar contrato, derechos, plazo de preaviso, pagos, tratamiento de datos y accesos reales. Si se disputan derechos u obligaciones de entrega, consulta a un abogado cualificado. Esta guía es operativa y no constituye asesoramiento jurídico.
¿Qué debes comprobar antes de dar acceso al proveedor entrante?
Haz la lista corta antes de exponer credenciales de producción o datos de clientes. En julio de 2026, NIST publicó la versión final de una guía de due diligence para proveedores TIC. Estructura la evaluación alrededor de procedencia, resiliencia, prácticas básicas de ciberseguridad, niveles de la cadena de suministro y consideraciones de propiedad o control. Es una corrección útil a la selección por portfolio: investiga cómo opera el proveedor, no solo qué ha entregado. Consulta NIST SP 1326 sobre due diligence de la cadena de suministro.
- Identidad y responsabilidad. Qué entidad firma, quién dirige la toma, quién puede acceder a producción y quién decide durante un incidente.
- Evidencia brownfield. Pide una evaluación anonimizada, un registro de riesgos o un plan de 30 días, no solo capturas de proyectos nuevos.
- Límite de entrega. Confirma si las mismas personas evaluarán, estabilizarán y ampliarán el sistema.
- Práctica de seguridad. Pregunta cómo se aprueban, registran, revisan y revocan accesos, cómo se tratan secretos y cómo se escalan hallazgos.
- Independencia comercial. La evaluación debe ser útil aunque no adjudiques el trabajo posterior.
Concede acceso nominal, temporal y de mínimo privilegio mediante identidades propiedad del cliente. Empieza con lectura cuando sea posible. Nunca envíes un volcado de contraseñas por correo. Acuerda dónde se guarda la evidencia, quién puede verla y cuándo debe eliminarse.
Plan de 30 días para tomar el proyecto de software
Treinta días son un marco de planificación, no una promesa universal. Un producto web pequeño puede avanzar más rápido. Una plataforma regulada, un ecosistema móvil, un sistema industrial o un producto con obligaciones 24/7 puede necesitar equipos paralelos y más solapamiento. La secuencia importa más que el calendario.
| Fase | Objetivo | Evidencia de salida |
|---|---|---|
| Antes del día 1 | Acordar autoridad, alcance, comunicación y salida | Carta de transición, mapa de responsables y protocolo de acceso |
| Días 1 a 5 | Recuperar control y medir producción | Inventario, matriz de accesos y estado base |
| Días 6 a 10 | Mapear arquitectura, datos y recorridos críticos | Mapa del sistema, riesgos y build local verificado |
| Días 11 a 20 | Probar despliegue, rollback, restore e incidentes | Pruebas observadas y plan de estabilización |
| Días 21 a 30 | Entregar un cambio acotado y decidir la hoja de ruta | Cambio en producción, revisión y plan de 90 días |
Antes del día 1: redacta la carta de transición
Nombra a un responsable del cliente, uno del proveedor saliente y uno del entrante. Define sistemas incluidos, canal de emergencia, autoridad de cambio, cadencia, repositorio de evidencia, ventana de solapamiento y prueba de independencia. Separa salida ordinaria y de emergencia. La guía británica actual del Mid-Tier Contract trata la gestión de salida como preparación continua, con biblioteca virtual, plan de salida, ayuda para volver a licitar y asistencia de terminación. Tu contrato puede ser menor, pero el principio operativo se mantiene. Consulta la guía del gobierno británico sobre gestión de salida.
Mantén al proveedor saliente en un papel de transición claro y remunerado cuando sea posible. Un traspaso hostil produce peor evidencia y más riesgo. Paga entregables y sesiones concretas, registra dudas sin resolver y no conviertas los hallazgos del equipo nuevo en una campaña pública de culpa.
Días 1 a 5: recupera el control sin provocar una caída
- Inventaría antes de rotar. Repositorios, cloud, DNS, certificados, dominios, stores, bases de datos, colas, correo, analítica, observabilidad, soporte, registros de paquetes y licencias.
- Confirma propiedad. Titular legal y de facturación, administradores, contactos de recuperación y ruta de transferencia.
- Conserva evidencia. Haz backups, exportaciones y snapshots autorizados. Mantén logs de auditoría e historial Git.
- Rota según dependencias. Sustituye credenciales personales y compartidas cuando sepas qué las consume. Mantén rollback bajo control del cliente.
- Fija la línea base. Tráfico, errores, latencia, colas, backups, incidentes, soporte y versión actual.
La congelación de cambios debe ser selectiva. Detén roadmap de alto riesgo, cambios de esquema y rediseños de infraestructura. Conserva una vía de parche urgente con aprobación nominal. Un freeze total sin parche puede preservar una vulnerabilidad conocida igual que preserva la estabilidad.
Días 6 a 10: mapa del sistema y registro de riesgos
El equipo entrante debe seguir entre tres y cinco recorridos críticos desde la acción del usuario hasta datos y efectos externos, como login, compra, pago, documento o facturación periódica. Para cada uno, registra entrada, servicios, datos, terceros, permisos, monitorización, fallos y recuperación manual.
| Clase | Significado | Acción |
|---|---|---|
| P0: exposición activa | Riesgo actual de seguridad, pérdida de datos o continuidad | Contener, preservar evidencia y avisar al responsable |
| P1: bloqueo de release | No se puede cambiar o recuperar con seguridad | Restaurar build, deploy, rollback, backup u observabilidad |
| P2: fricción de entrega | Problema que ralentiza cada cambio | Corregir donde lo toque el siguiente trabajo |
| P3: mejora | Útil, pero no necesaria para operar con seguridad | Llevar al roadmap con caso de negocio |
No dejes que la estética del código supere al riesgo operativo. Un framework antiguo con build reproducible y recuperación probada suele ser más seguro el día 10 que un plan de reescritura sin evidencia de producción.
Días 11 a 20: prueba los caminos operativos
Ejecuta pruebas observadas en el entorno representativo más seguro. El equipo entrante debe demostrar setup limpio, build repetible, despliegue, smoke test, rollback, backup, ensayo de restore y escalado de incidentes. Los cambios de producción siguen el proceso normal de riesgo y aprobación.
En dependencias cloud y SaaS, confirma exportación y obligaciones de cambio. El Data Act de la UE se aplica desde el 12 de septiembre de 2025 y fija requisitos mínimos para cambiar entre servicios de tratamiento de datos, incluidos cloud y edge. La Comisión explica que los proveedores deben eliminar barreras y, en PaaS y SaaS, ofrecer interfaces abiertas y al menos exportaciones en formatos comunes y legibles por máquina. Alcance y excepciones importan, así que revisa servicio y contrato. Consulta la explicación del Data Act de la Comisión Europea.
Si un proveedor trata datos personales por tu cuenta, la salida debe ajustarse al contrato de tratamiento. El artículo 28 del RGPD exige, a elección del responsable, devolver o eliminar los datos tras acabar el servicio salvo obligación legal de conservación. Inventario, exportación, prueba de eliminación y retirada de accesos de subencargados forman parte de la transición. Revisa el texto oficial del RGPD en EUR-Lex.
Para productos con elementos digitales dentro del alcance del CRA, identifica quién asumirá evaluación de riesgo, documentación técnica, compromisos de soporte y gestión de vulnerabilidades. Depende del producto y del papel económico. El resumen del Cyber Resilience Act de la Comisión Europea explica obligaciones del fabricante, tratamiento de vulnerabilidades y fechas principales.
Días 21 a 30: entrega un cambio acotado
Una toma no se demuestra con diapositivas. Elige un cambio de bajo riesgo que recorra el camino real hasta producción: defecto pequeño, observabilidad, parche de dependencia o corrección de workflow. Exige revisión, controles automáticos, evidencia de despliegue y observación posterior.
Usa una base de seguridad explícita. El Secure Software Development Framework de NIST ofrece prácticas aplicables a distintos ciclos de desarrollo. Para aplicaciones web, OWASP ASVS 5.0 ofrece requisitos verificables y está pensado también para procurement. Selecciona controles según riesgo. No afirmes cumplimiento total porque un escáner se ejecutó una vez.
La decisión del día 30 debe ser una de cuatro: mantenimiento prudente, estabilización antes de funciones, modernización por límites o sustitución cuando la evidencia indique menor coste y riesgo. “Reescribir todo” es una conclusión, no un método inicial.
¿Qué puede salir mal al cambiar de proveedor?
| Fallo | Señal temprana | Control |
|---|---|---|
| Credenciales rotadas en mal orden | Consumidores desconocidos y cuentas compartidas | Mapear dependencias, rotar por fases y conservar rollback |
| El traspaso se convierte en archivo de vídeo | Muchas llamadas, ningún runbook ejecutable | Convertir cada sesión en artefacto y tarea verificada |
| El proveedor nuevo vende una reescritura inmediata | Estimación y arquitectura antes del acceso | Comprar evaluación con criterios de conservar o sustituir |
| El equipo anterior se va demasiado pronto | No hay solapamiento para deploy o incidente | Mantener asistencia hasta superar pruebas de independencia |
| El roadmap desplaza la estabilización | Fechas fijadas antes del registro de riesgos | Separar presupuesto de toma, estabilidad y roadmap |
| Licencias o cuentas no se transfieren | Servicios bajo contratos del proveedor | Inventariar contratos, exportación y sustitución |
| Un hallazgo grave queda en el chat | Sin responsable ni severidad | Escalado confidencial, control de evidencia y decision log |
| Éxito significa “repositorio entregado” | Sin prueba de deploy, rollback o restore | Usar independencia operativa como aceptación |
Cómo elegir al nuevo proveedor de software
Entrega a cada finalista el mismo paquete redactado: mapa, restricciones, un recorrido crítico y resultado deseado. Pide riesgos, incógnitas, accesos, primeras dos semanas, roles, puertas de decisión y supuestos. No premies la propuesta genérica más larga.
| Criterio | Peso | Evidencia |
|---|---|---|
| Experiencia brownfield y de toma | 20 | Evaluación anonimizada, caso o registro de riesgos |
| Método de transición | 20 | Plan de 30 días, pruebas de independencia y protocolo saliente |
| Release y recuperación | 15 | Build, deploy, rollback, backup y restore |
| Seguridad y datos | 15 | Acceso, escalado, evidencia y eliminación |
| Claridad comercial | 10 | Alcance, supuestos, exclusiones, IP, salida y continuidad |
| Juicio de producto | 10 | Ejemplos de conservar, cambiar o rechazar |
| Comunicación y continuidad | 10 | Líder, equipo real, sustitución y cadencia |
Define la regla antes de recibir ofertas. Nuestro valor por defecto es al menos 70 puntos sin un hard stop. Son hard stops: no tener responsable nominal, acceso seguro a producción, entregable escrito, derechos claros sobre el resultado o prometer una reescritura fija antes de inspeccionar. Ajusta pesos, pero no dejes que una gran llamada de ventas compense un control fallido.
Cuándo encaja Wavect y cuándo no
Wavect encaja si tienes un producto a medida activo o bloqueado, puedes proporcionar acceso legítimo y quieres una evaluación antes de mantenimiento o desarrollo. Nuestra preferencia es entender, documentar riesgos, estabilizar y presupuestar el trabajo posterior desde evidencia. Conservas el informe escrito.
No encajamos para una reescritura ciega, staff augmentation anónimo, helpdesk TI genérico 24/7 o una toma sin nadie que autorice acceso. A veces la recomendación correcta es mantener el equipo actual y arreglar el gobierno. Como este artículo es de Wavect, trata la scorecard como una perspectiva declarada y pide las mismas pruebas a todos, también a nosotros.
Un ejemplo relevante es el caso de FTW Ventures. Para una línea base de calidad independiente, consulta nuestro servicio de QA de software.
Preguntas frecuentes sobre la toma de software
Preguntas frecuentes
¿Cuánto tarda la toma de un proyecto de software?
¿Puede un proveedor tomar software sin documentación?
¿Debe el proveedor nuevo reescribir el software?
¿Qué hacer si el proveedor saliente no coopera?
¿Qué debe entregar una evaluación de toma?
¿Cómo comparo proveedores para la toma?
Reflexiones finales
Un cambio seguro de proveedor transfiere capacidad, no solo archivos. El equipo entrante debe explicar el sistema, operarlo bajo presión y llevar un cambio pequeño por la ruta real de release. Por eso el primer mes avanza desde el control al entendimiento, luego a la prueba operativa y solo después al roadmap.
Elige al proveedor más preciso sobre incógnitas, evidencia y puertas de decisión. La mejor propuesta no suele ser la promesa más grande, sino el método más claro para reducir dependencia mientras producto y negocio siguen funcionando.
¿Necesitas una evaluación escrita antes del nuevo roadmap?
Hablar sobre la toma de software