--- title: "Toma de proyecto software: plan de 30 días" canonical: https://wavect.io/es/blog/software-project-takeover-provider-change/ language: es description: "¿Cambias de proveedor de software? Usa este plan de 30 días, registro de riesgos y scorecard para proteger accesos, datos, releases y continuidad." image: "https://wavect.io/img/blog/headers/header_software-project-takeover-provider-change.png" --- [**Volver**](/es/blog/overview/) [![Kevin Riedl](/img/team/kevin.webp)](/es/team/kevin-riedl/) [Kevin Riedl](/es/team/kevin-riedl/) https://linkedin.com/in/wsdt 15 min de lectura · 13 de agosto de 2026 Última revisión 13 de agosto de 2026 [**Siguiente**](/es/blog/software-agency-proposal-teardown/) # Tomar el relevo de un proyecto de software: plan de 30 días Resumen La toma de un proyecto de software termina cuando el equipo entrante puede compilar, desplegar, observar, revertir y restaurar el producto sin el proveedor saliente. Dedica los días 1 a 5 a asegurar propiedad y línea base de producción, los días 6 a 10 a mapear arquitectura y recorridos críticos, los días 11 a 20 a probar release y recuperación, y los días 21 a 30 a entregar un cambio pequeño y de bajo riesgo. Elige proveedor por evidencia en sistemas existentes, control operativo, seguridad, método de transición y claridad comercial. Descarta a quien prometa una reescritura o un plan fijo antes de inspeccionar el sistema. **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](/es/software-development-guide/software-handover-checklist/) para la lista completa de artefactos, la [guía para elegir una agencia de software](/es/software-development-guide/how-to-choose-a-software-agency/) para una decisión de compra más amplia y el [servicio de toma de software de Wavect](/es/services/software-takeover/) 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](https://csrc.nist.gov/pubs/sp/1326/final). - **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](https://www.gov.uk/government/publications/guidance-on-the-mid-tier-contract/the-mid-tier-contract-guidance-for-buyers-html). 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 1. **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. 2. **Confirma propiedad.** Titular legal y de facturación, administradores, contactos de recuperación y ruta de transferencia. 3. **Conserva evidencia.** Haz backups, exportaciones y snapshots autorizados. Mantén logs de auditoría e historial Git. 4. **Rota según dependencias.** Sustituye credenciales personales y compartidas cuando sepas qué las consume. Mantén rollback bajo control del cliente. 5. **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](https://digital-strategy.ec.europa.eu/en/factpages/data-act-explained). 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](https://eur-lex.europa.eu/eli/reg/2016/679/oj). 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](https://digital-strategy.ec.europa.eu/en/policies/cra-summary) 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](https://csrc.nist.gov/pubs/sp/800/218/final) ofrece prácticas aplicables a distintos ciclos de desarrollo. Para aplicaciones web, [OWASP ASVS 5.0](https://owasp.org/www-project-application-security-verification-standard/) 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](/es/case-studies/ftw-ventures/). Para una línea base de calidad independiente, consulta nuestro [servicio de QA de software](/es/services/software-quality-assurance/). ## Preguntas frecuentes sobre la toma de software ## Preguntas frecuentes ### ¿Cuánto tarda la toma de un proyecto de software? Usa 30 días como primera ventana de control y evaluación, no como promesa universal. Productos pequeños pueden ser independientes antes. Sistemas regulados, distribuidos o mal documentados necesitan más solapamiento. Define el final con evidencia de build, deploy, rollback, restore e incidentes. ### ¿Puede un proveedor tomar software sin documentación? A menudo sí, si el cliente puede facilitar legalmente código, infraestructura y expertos. Habrá más discovery e incertidumbre. El equipo reconstruye arquitectura y operación desde repositorios, configuración, telemetría, tickets y entrevistas, y escribe runbooks al verificarlos. ### ¿Debe el proveedor nuevo reescribir el software? No antes de evaluar. Compara mantenimiento, estabilización, modernización por límites y sustitución. La reescritura solo se justifica cuando la evidencia muestra que conservar el sistema tiene mayor coste y riesgo total. ### ¿Qué hacer si el proveedor saliente no coopera? Conserva contratos, facturas, comunicaciones y accesos actuales. Identifica lo que el cliente controla, evita acceso no autorizado y pide revisión jurídica. Técnicamente, prioriza backups, recuperación de cuentas, continuidad y un registro de incógnitas. ### ¿Qué debe entregar una evaluación de toma? Inventario de activos y accesos, mapa de sistema y datos, estado de build y deploy, riesgos operativos y de seguridad, dependencias y licencias, lagunas documentales, prioridades, opciones, equipo necesario y propuesta posterior con supuestos. ### ¿Cómo comparo proveedores para la toma? Da a los finalistas el mismo escenario y puntúa evidencia. Pondera experiencia brownfield, método, release y recuperación, seguridad y datos, claridad comercial, juicio de producto y continuidad. Exige una evaluación útil aunque otro implemente. ## 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. ## También te puede gustar.. [**Análisis de una propuesta de agencia de software** Tras elegir proveedor, revisa alcance, aceptación, IP, seguridad y salida antes de firmar.](/es/blog/software-agency-proposal-teardown/) [**Wavect frente a una agencia de desarrollo generalista** Compara criterio de producto, continuidad senior y traspaso limpio con entrega centrada en capacidad.](/es/compare/wavect-vs-dev-agencies/) Compra y financiación de software ## Continúa por este clúster Selección de agencias, contratos, precios, subvenciones y mecánica comercial. [Empieza por el artículo fundamental**Análisis de una propuesta de agencia de software: 12 cláusulas sobre precio, alcance y propiedad**](/es/blog/software-agency-proposal-teardown/) - [A qué te compromete la palabra "Dienstleister"](/es/blog/werkvertrag-vs-dienstvertrag-software-austria/) - [Agencias de software en Tirol comparadas en 2026](/es/blog/software-agencies-tyrol-comparison-2026/) - [Análisis de una propuesta de agencia de software: 12 cláusulas sobre precio, alcance y propiedad](/es/blog/software-agency-proposal-teardown/) - [Consultoría de IA en Austria 2026: guía honesta para pymes](/es/blog/ai-consulting-austria-2026/) - [Ayudas a la IA en Austria 2026: aws, FFG, prima, KMU.DIGITAL](/es/blog/ai-funding-austria-2026/) Tu bandeja, sin ruido ## Sigue el trabajo que te importa Recibe un correo breve cuando publiquemos algo nuevo. Sigue todo el blog o solo los temas que te interesan. [**Volver**](/es/blog/overview/) [![Kevin Riedl](/img/team/kevin.webp)](/es/team/kevin-riedl/) [Kevin Riedl](/es/team/kevin-riedl/) https://linkedin.com/in/wsdt 15 min de lectura · 13 de agosto de 2026 Última revisión 13 de agosto de 2026 [**Siguiente**](/es/blog/software-agency-proposal-teardown/) Nuevos artículos por correo × × Recibe nuevos artículos por correo Un correo breve cuando publicamos. Gratis y sin seguimiento. ## Structured Data ```json { "@context": "https://schema.org", "@graph": [ { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ], "employee": [ { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } } ], "founder": [ { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } } ], "legalRepresentative": [ { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } } ], "name": "Wavect GmbH", "subjectOf": { "@id": "https://wavect.io/verified-claims.json#dataset", "@type": "Dataset", "creator": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] }, "description": "A machine-readable registry of quantitative and qualitative claims published by Wavect, with review dates, localized page appearances and public third-party citations where available.", "inLanguage": "en", "isAccessibleForFree": true, "license": "https://creativecommons.org/licenses/by/4.0/", "name": "Wavect verified publication claims", "url": "https://wavect.io/verified-claims.json" }, "url": "https://wavect.io/" }, { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "sameAs": [ "https://www.wikidata.org/wiki/Q139796365", "https://www.linkedin.com/in/wsdt", "https://github.com/wsdt" ], "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "sameAs": [ "https://www.wikidata.org/wiki/Q139796367", "https://www.linkedin.com/in/jocr77/", "https://github.com/jo-chris" ], "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/#website", "@type": "WebSite", "inLanguage": [ "en", "de", "es", "zh" ], "name": "Wavect", "potentialAction": { "@type": "SearchAction", "query-input": "required name=search_term_string", "target": { "@type": "EntryPoint", "urlTemplate": "https://wavect.io/search/?q={search_term_string}" } }, "publisher": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] }, "url": "https://wavect.io/" }, { "@id": "https://wavect.io/es/blog/software-project-takeover-provider-change/#webpage", "@type": "WebPage", "dateModified": "2026-08-13", "inLanguage": "es", "isPartOf": { "@id": "https://wavect.io/#website", "@type": "WebSite" }, "lastReviewed": "2026-08-13", "url": "https://wavect.io/es/blog/software-project-takeover-provider-change/" } ] } ``` ```json { "@context": "https://schema.org", "@type": "BlogPosting", "abstract": "La toma de un proyecto de software termina cuando el equipo entrante puede compilar, desplegar, observar, revertir y restaurar el producto sin el proveedor saliente. Dedica los días 1 a 5 a asegurar propiedad y línea base de producción, los días 6 a 10 a mapear arquitectura y recorridos críticos, los días 11 a 20 a probar release y recuperación, y los días 21 a 30 a entregar un cambio pequeño y de bajo riesgo. Elige proveedor por evidencia en sistemas existentes, control operativo, seguridad, método de transición y claridad comercial. Descarta a quien prometa una reescritura o un plan fijo antes de inspeccionar el sistema.", "articleBody": " Resumen del blog/Negocio y regulación/Compra y financiación de software Tomar el relevo de un proyecto de software: plan de 30 días Resumen La toma de un proyecto de software termina cuando el equipo entrante puede compilar, desplegar, observar, revertir y restaurar el producto sin el proveedor saliente. Dedica los días 1 a 5 a asegurar propiedad y línea base de producción, los días 6 a 10 a mapear arquitectura y recorridos críticos, los días 11 a 20 a probar release y recuperación, y los días 21 a 30 a entregar un cambio pequeño y de bajo riesgo. Elige proveedor por evidencia en sistemas existentes, control operativo, seguridad, método de transición y claridad comercial. Descarta a quien prometa una reescritura o un plan fijo antes de inspeccionar el sistema. 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ónPrimer pasoPor qué El equipo es capaz, pero faltan prioridades y responsablesReiniciar gobierno y derechos de decisiónOtro proveedor heredaría el mismo problema de gestión. La entrega es lenta, pero el sistema es estable y transparenteHacer una evaluación independiente y acotadaNecesitas evidencia antes de pagar el coste del cambio. Código, cloud o datos siguen en cuentas del proveedorPlanificar salida y recuperación del controlLa dependencia operativa ya es un riesgo empresarial. Seguridad, integridad de datos o continuidad están en peligroIniciar triaje de emergencia controladoConté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. FaseObjetivoEvidencia de salida Antes del día 1Acordar autoridad, alcance, comunicación y salidaCarta de transición, mapa de responsables y protocolo de acceso Días 1 a 5Recuperar control y medir producciónInventario, matriz de accesos y estado base Días 6 a 10Mapear arquitectura, datos y", "articleSection": "Engineering", "author": { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "name": "Kevin Riedl", "sameAs": [ "https://www.wikidata.org/wiki/Q139796365", "https://www.linkedin.com/in/wsdt", "https://github.com/wsdt" ], "url": "https://wavect.io/team/kevin-riedl/" }, "citation": [ { "@type": "WebPage", "name": "NIST SP 1326 sobre due diligence de la cadena de suministro", "url": "https://csrc.nist.gov/pubs/sp/1326/final" }, { "@type": "WebPage", "name": "guía del gobierno británico sobre gestión de salida", "url": "https://www.gov.uk/government/publications/guidance-on-the-mid-tier-contract/the-mid-tier-contract-guidance-for-buyers-html" }, { "@type": "WebPage", "name": "explicación del Data Act de la Comisión Europea", "url": "https://digital-strategy.ec.europa.eu/en/factpages/data-act-explained" }, { "@type": "WebPage", "name": "texto oficial del RGPD en EUR-Lex", "url": "https://eur-lex.europa.eu/eli/reg/2016/679/oj" }, { "@type": "WebPage", "name": "resumen del Cyber Resilience Act de la Comisión Europea", "url": "https://digital-strategy.ec.europa.eu/en/policies/cra-summary" }, { "@type": "WebPage", "name": "Secure Software Development Framework de NIST", "url": "https://csrc.nist.gov/pubs/sp/800/218/final" }, { "@type": "WebPage", "name": "OWASP ASVS 5.0", "url": "https://owasp.org/www-project-application-security-verification-standard/" } ], "dateModified": "2026-08-13", "datePublished": "2026-08-13", "description": "La toma de un proyecto de software termina cuando el equipo entrante puede compilar, desplegar, observar, revertir y restaurar el producto sin el proveedor saliente. Dedica los días 1 a 5 a asegurar propiedad y línea base de producción, los días 6 a 10 a mapear arquitectura y recorridos críticos, los días 11 a 20 a probar release y recuperación, y los días 21 a 30 a entregar un cambio pequeño y de bajo riesgo. Elige proveedor por evidencia en sistemas existentes, control operativo, seguridad, método de transición y claridad comercial. Descarta a quien prometa una reescritura o un plan fijo antes de inspeccionar el sistema.", "headline": "Tomar el relevo de un proyecto de software: plan de 30 días", "image": "https://wavect.io/img/blog/headers/header_software-project-takeover-provider-change.svg", "inLanguage": "es", "keywords": "Ingeniería, Toma de software, Cambio de proveedor", "mainEntityOfPage": { "@id": "https://wavect.io/es/blog/software-project-takeover-provider-change/", "@type": "WebPage" }, "publisher": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] }, "url": "https://wavect.io/es/blog/software-project-takeover-provider-change/", "wordCount": 2737 } ``` ```json { "@context": "https://schema.org", "@type": "BreadcrumbList", "itemListElement": [ { "@type": "ListItem", "item": "https://wavect.io/es/", "name": "Inicio", "position": 1 }, { "@type": "ListItem", "item": "https://wavect.io/es/blog/overview/", "name": "Resumen del blog", "position": 2 }, { "@type": "ListItem", "item": "https://wavect.io/es/blog/topics/business-regulation/", "name": "Negocio y regulación", "position": 3 }, { "@type": "ListItem", "item": "https://wavect.io/es/blog/clusters/software-buying-funding/", "name": "Compra y financiación de software", "position": 4 }, { "@type": "ListItem", "item": "https://wavect.io/es/blog/software-project-takeover-provider-change/", "name": "Toma de proyecto software: plan de 30 días | ", "position": 5 } ] } ``` ```json { "@context": "https://schema.org", "@type": "FAQPage", "mainEntity": [ { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "Usa 30 días como primera ventana de control y evaluación, no como promesa universal. Productos pequeños pueden ser independientes antes. Sistemas regulados, distribuidos o mal documentados necesitan más solapamiento. Define el final con evidencia de build, deploy, rollback, restore e incidentes." }, "name": "¿Cuánto tarda la toma de un proyecto de software?" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "A menudo sí, si el cliente puede facilitar legalmente código, infraestructura y expertos. Habrá más discovery e incertidumbre. El equipo reconstruye arquitectura y operación desde repositorios, configuración, telemetría, tickets y entrevistas, y escribe runbooks al verificarlos." }, "name": "¿Puede un proveedor tomar software sin documentación?" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "No antes de evaluar. Compara mantenimiento, estabilización, modernización por límites y sustitución. La reescritura solo se justifica cuando la evidencia muestra que conservar el sistema tiene mayor coste y riesgo total." }, "name": "¿Debe el proveedor nuevo reescribir el software?" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "Conserva contratos, facturas, comunicaciones y accesos actuales. Identifica lo que el cliente controla, evita acceso no autorizado y pide revisión jurídica. Técnicamente, prioriza backups, recuperación de cuentas, continuidad y un registro de incógnitas." }, "name": "¿Qué hacer si el proveedor saliente no coopera?" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "Inventario de activos y accesos, mapa de sistema y datos, estado de build y deploy, riesgos operativos y de seguridad, dependencias y licencias, lagunas documentales, prioridades, opciones, equipo necesario y propuesta posterior con supuestos." }, "name": "¿Qué debe entregar una evaluación de toma?" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "Da a los finalistas el mismo escenario y puntúa evidencia. Pondera experiencia brownfield, método, release y recuperación, seguridad y datos, claridad comercial, juicio de producto y continuidad. Exige una evaluación útil aunque otro implemente." }, "name": "¿Cómo comparo proveedores para la toma?" } ] } ```