--- title: "Cambiar de proveedor de software: qué pedir" description: "Cómo cambiar de proveedor de software sin perder el sistema: qué pedir, de quién es el código según la ley y una lista de traspaso que puedes copiar." canonical: https://caricalia.com/notas/cambiar-de-proveedor-de-software last-updated: 2026-09-29 --- # Cambiar de proveedor de software: qué pedir > El cambio de proveedor sale bien o mal según lo que tengas en las manos antes de anunciarlo: código, accesos, contratos y una cesión de derechos por escrito. Publicado: 2026-09-29 Autor: carlos Temas: proveedor, traspaso, propiedad intelectual --- ## Cómo cambiar de proveedor de software sin perder el sistema Para cambiar de proveedor sin perder el sistema, pide cinco cosas antes de anunciar el cambio: el código fuente completo, los accesos a todas las cuentas a nombre de tu empresa, los contratos de los servicios de terceros, la cesión escrita de los derechos y la documentación de cómo se despliega. Con eso en tu poder el cambio es un traspaso ordenado. Sin ello, es una negociación en la que el otro lado tiene todas las llaves. Es una de las situaciones que más veces vemos en [software a medida](/software-a-medida) ya en producción: el proveedor contesta, hace el cambio y factura, hasta el día en que quieres pedir presupuesto a otro y descubres que el repositorio está en su cuenta. Esta nota explica qué pedir, qué dice la ley española sobre de quién es el código y trae una lista de traspaso que puedes copiar. ## Qué pedir al proveedor actual Pídelo por escrito y en este orden. Lo primero es lo que no se puede reconstruir si se pierde. | Qué | Por qué | Cómo compruebas que lo tienes | |---|---|---| | Código fuente completo, con su historial | Sin el código, cualquier otro proveedor empieza de cero | Lo clonas en una máquina que no es la suya y ves el historial de cambios | | Accesos y titularidad de las cuentas: servidor, dominio y DNS, correo transaccional, almacenamiento, cuentas de pago | Quien es titular de la cuenta manda sobre ella | Entras con una cuenta de tu empresa y ves quién más tiene acceso | | Copia de la base de datos y de los ficheros de usuarios | Es tu negocio: clientes, pedidos, facturas | Restauras la copia en un entorno de prueba y compruebas que arranca | | Cómo se construye y se despliega: scripts, configuración y variables | Sin eso el código no se puede llevar a producción | Alguien ajeno lo despliega en un entorno de prueba siguiendo solo las instrucciones | | Contratos y licencias de terceros: servicios de pago, librerías con licencia, mapas, correo | Pueden estar a nombre del proveedor | Tienes la lista con titular, coste y fecha de renovación | | Documentación: cómo está montado, decisiones, reglas de negocio | Es lo que permite a otro cambiar algo sin romperlo | Una persona que no ha visto el proyecto la lee y entiende el sistema | | Cesión de derechos por escrito | Sin ella, el código puede no ser tuyo (ver abajo) | Está en el contrato, con alcance, plazo y territorio | | Contrato de encargado del tratamiento, si toca datos personales | Es obligatorio y regula qué pasa con los datos al terminar | Está firmado y dice que los datos se devuelven o se suprimen | ## De quién es el código Es la pregunta que más se pospone y la que más cuesta después. La Ley de Propiedad Intelectual (texto refundido, [BOE-A-1996-8930](https://www.boe.es/buscar/act.php?id=BOE-A-1996-8930)) dice cuatro cosas que conviene tener claras. No es asesoramiento jurídico: si el contrato es dudoso, que lo lea un abogado. **Toda cesión se formaliza por escrito.** Lo dice el artículo 45. Un proveedor externo no es un empleado: los derechos de explotación de un programa solo pasan a quien lo encarga si hay una cesión escrita. La regla de que la titularidad corresponde a la empresa vale para los trabajadores asalariados que crean el programa en el ejercicio de sus funciones (artículo 97.4). **La cesión se limita a lo pactado.** Según el artículo 43, queda limitada a las modalidades de explotación expresamente previstas, al tiempo y al ámbito territorial que se determinen. Si el contrato no menciona el tiempo, la cesión se limita a cinco años; si no menciona el territorio, al país donde se hace. Un contrato que dice «se cede el software» sin más puede dar menos de lo que crees. **Una licencia de uso no es una cesión.** El artículo 99 dice que, cuando se cede el derecho de uso de un programa, se entiende salvo prueba en contrario que es no exclusivo e intransferible y para satisfacer las necesidades del usuario. Con una licencia de uso puedes usar el programa, pero no dárselo a otro para que lo modifique. **El titular puede encargar versiones nuevas.** El artículo 100.4 establece que el autor, salvo pacto en contrario, no puede oponerse a que el cesionario titular realice o autorice versiones sucesivas del programa ni programas derivados. Es lo que te permite pedir a otro proveedor que siga con el sistema, siempre que tengas la cesión. Si el software trae piezas de terceros con licencia propia, esas piezas tienen su propia condición: la cesión del proveedor no las cubre. Por eso la lista de terceros va aparte. ## Los datos personales: el contrato que se olvida Si el sistema guarda datos de personas, el proveedor que los trata para ti es un encargado del tratamiento. El [artículo 28 del Reglamento general de protección de datos](https://www.boe.es/buscar/doc.php?id=DOUE-L-2016-80807) exige un contrato que regule, entre otras cosas, qué ocurre al terminar: a elección del responsable, el encargado suprimirá o devolverá todos los datos personales y suprimirá las copias existentes, salvo que el Derecho de la Unión o de un Estado miembro exija conservarlos. En la práctica: al cambiar de proveedor, pide por escrito la devolución de los datos y una confirmación de que se han borrado del lado del anterior, una vez el nuevo tiene todo funcionando. ## La lista de traspaso, para copiar Copia este bloque, pégalo en tu gestor de tareas y marca cada línea con una fecha y un nombre. Ningún punto vale «me han dicho que sí»: vale «lo he comprobado yo». ```text LISTA DE TRASPASO ENTRE PROVEEDORES DE SOFTWARE A. Antes de anunciar el cambio [ ] Contrato leído: quién es titular del código, alcance, plazo y territorio de la cesión [ ] Licencia de uso o cesión de derechos: cuál de las dos dice el contrato [ ] Cláusulas de salida: preaviso, entrega de material y plazos [ ] Lista de terceros con contrato a nombre del proveedor [ ] Persona de la empresa responsable del traspaso, con nombre B. Código [ ] Repositorio completo, con historial, en una cuenta de la empresa [ ] Ramas y etiquetas de versiones incluidas [ ] Código clonado y construido en una máquina que no es del proveedor [ ] Lista de dependencias y de sus licencias C. Entornos y despliegue [ ] Instrucciones para construir y desplegar, probadas por una persona ajena [ ] Configuración y variables de entorno listadas, con los valores en un gestor de contraseñas [ ] Entorno de pruebas que arranca desde cero [ ] Cómo se vuelve atrás si un despliegue sale mal D. Cuentas y accesos, todos a nombre de la empresa [ ] Servidor o alojamiento [ ] Dominio y DNS [ ] Correo transaccional y notificaciones [ ] Almacenamiento de ficheros y copias de seguridad [ ] Servicios de pago y facturación [ ] Analítica, registros de errores y monitorización [ ] Cuentas de tiendas de aplicaciones, si hay aplicación móvil [ ] Lista de personas con acceso a cada cuenta E. Datos [ ] Copia completa de la base de datos y de los ficheros de usuarios [ ] Copia restaurada en un entorno de prueba, con fecha [ ] Contrato de encargado del tratamiento firmado, si hay datos personales [ ] Confirmación por escrito de devolución y supresión de datos al terminar F. Conocimiento [ ] Documento de cómo está montado el sistema [ ] Decisiones de arquitectura con fecha y motivo [ ] Reglas de negocio raras, mejor como pruebas que se ejecutan solas [ ] Sesiones de traspaso con el proveedor anterior, con fecha y asistentes G. Cierre [ ] Prueba de relevo: alguien que no ha visto el proyecto hace un cambio real con solo el repositorio [ ] Claves y contraseñas del proveedor anterior cambiadas [ ] Accesos del proveedor anterior retirados, uno por uno [ ] Acta de entrega firmada por las dos partes ``` ## El traspaso en cuatro semanas Un plan razonable para un sistema de tamaño normal. Los plazos dependen de cuánto colabore el proveedor y de lo grande que sea el sistema, y se ajustan al leer el código. | Semana | Qué se hace | Cómo sabes que está hecho | |---|---|---| | Primera | Se envía la petición formal por escrito con la lista de arriba. Se pasan las cuentas a nombre de la empresa | Tienes acceso propio a cada cuenta y ves quién más lo tiene | | Segunda | Se recibe el código y se construye en una máquina ajena. Se restaura una copia de los datos | El sistema arranca en un entorno de pruebas sin ayuda del proveedor | | Tercera | El nuevo proveedor lee el código y hace un primer cambio pequeño, con el anterior disponible para dudas | El cambio se despliega en pruebas y funciona | | Cuarta | Se hace la prueba de relevo y se retiran los accesos del proveedor anterior | Un cambio real llega a producción sin preguntar al proveedor anterior | ## Errores que salen caros - **Anunciar el cambio antes de tener los accesos.** Cambia el tono de la conversación y a partir de ahí todo se negocia. - **Aceptar «te lo doy cuando acabemos el mes».** Lo que no está en tu poder no es tuyo. Se pide ya y se comprueba. - **No probar que el código construye.** Un repositorio al que le faltan piezas parece completo hasta el día en que lo necesitas. - **Olvidar el dominio y el DNS.** Quien controla el dominio controla el correo y la web, aunque no tenga una línea de código. - **No cambiar las claves.** Cuando el traspaso acaba, las claves que conocía el proveedor anterior se rotan. ## Cuándo un diagnóstico ayuda Si no sabes qué hay dentro, o el proveedor no colabora, o el sistema depende de una sola persona de su equipo, lo primero es que alguien independiente lo lea. Es lo que hace un [diagnóstico](/diagnostico): tres semanas leyendo el sistema y un informe con qué falta para poder cambiar de proveedor, qué cuesta y en qué orden. El informe es tuyo. Si el problema es de dependencia interna, lo cuenta [software que depende de una sola persona](/notas/software-depende-de-una-persona), y si te preguntas si el sistema merece seguir, [reescribir o refactorizar](/notas/reescribir-o-refactorizar) da los criterios. ## Preguntas frecuentes ### ¿Puedo recuperar el código fuente de mi proveedor? Depende del contrato. Si hay una cesión escrita de los derechos, el código es tuyo y puedes exigirlo. Si solo tienes una licencia de uso, puede que no. Lo primero es leer las cláusulas de propiedad intelectual y de salida, y pedirlo por escrito. ### ¿El proveedor puede quedarse con el código que ha hecho para mí? En un programa hecho por un proveedor externo, los derechos no pasan a quien lo encarga sin una cesión por escrito (artículo 45 de la Ley de Propiedad Intelectual). Si hay cesión, se limita a lo pactado en modalidades, tiempo y territorio (artículo 43). Por eso el contrato tiene que decirlo con claridad. ### ¿Qué pasa con la base de datos de mis clientes? Es tuya como responsable del tratamiento. El proveedor, como encargado, tiene que devolverla o suprimirla al terminar, según elijas tú (artículo 28.3.g del Reglamento general de protección de datos). Pide la copia y una confirmación de borrado por escrito. ### ¿Cuánto se tarda en cambiar de proveedor de software? Con colaboración y un sistema de tamaño normal, un traspaso ordenado cabe en cuatro semanas. Sin colaboración, o con un sistema grande, se tarda más y conviene un diagnóstico para saber cuánto antes de anunciar nada. ### ¿Se puede cambiar de proveedor sin que el actual colabore? A veces, si ya tienes accesos y código. Si no los tienes, un abogado tiene que leer el contrato antes de nada, y el primer paso habitual es un requerimiento por escrito con constancia de entrega. Nadie puede prometer un resultado sin ver el contrato. Si quieres saber cuál es tu punto de partida, [pide un diagnóstico](/diagnostico).