Dejar a un proveedor cloud debería parecerse a una mudanza, no a una reconstrucción. Sin embargo, recuperar los datos suele ser solo el primer paso: también hay que rehacer las conexiones, sustituir determinados servicios y comprobar que todo funciona en otro entorno. En este mes de septiembre de 2026, el Data Act constituye el nuevo marco europeo para reducir esta dependencia. Pero entre el derecho de salida y una migración exitosa sigue habiendo una distancia considerable. Analizamos el reglamento aprobado y los mecanismos técnicos conocidos, sin anticipar un balance de su aplicación que aún está por establecer.
Un derecho de salida, no una migración automática
El Reglamento europeo de Datos, que entró en vigor en enero de 2024, es aplicable desde el 12 de septiembre de 2025. Su apartado dedicado a los servicios de tratamiento de datos aborda, en particular, los obstáculos al cambio de proveedor: cláusulas disuasorias, procedimientos opacos, dificultades de exportación o falta de cooperación. Afecta tanto a los grandes grupos estadounidenses que operan en el mercado europeo como a los proveedores establecidos en la Unión.
El texto obliga a formalizar las condiciones de salida en el contrato. Prevé, en particular, un preaviso máximo de dos meses para iniciar el cambio, seguido de un período transitorio normalmente limitado a treinta días. Si este plazo resulta técnicamente inviable, el proveedor debe justificarlo y puede proponer una transición prolongada, dentro de los límites previstos por el reglamento. Este calendario proporciona al cliente una herramienta de presión, sin garantizar que su propio proyecto concluya con la misma rapidez.
Otra fecha decisiva: el 12 de enero de 2027. Ese día deben desaparecer los cargos por cambio de proveedor. Hasta entonces, los cargos reducidos autorizados no pueden superar los costes directamente relacionados con el cambio. Esto no significa que todo el tráfico de red sea gratuito ni que desaparezcan todas las cantidades adeudadas en virtud del contrato. La factura de salida y el coste real de la mudanza son dos cuestiones distintas.
Los archivos viajan mejor que las aplicaciones
Tomemos como ejemplo una cadena comercial ficticia. Sus fotos de productos se almacenan en objetos, su catálogo en una base de datos gestionada, sus pedidos pasan por un sistema de mensajería y sus promociones activan funciones que se ejecutan bajo demanda. Descargar las fotos parece sencillo. Reproducir las garantías de entrega de los mensajes, los permisos de acceso y el comportamiento de las funciones lo es mucho menos.
Ese es el núcleo de la dependencia técnica. Una máquina virtual que utiliza un sistema habitual se traslada relativamente bien, siempre que se adapten su imagen y su red. Una aplicación construida en torno a una base de datos propietaria, un motor de análisis o un servicio de inteligencia artificial específico requiere a veces una reescritura. Las interfaces pueden parecerse sin ofrecer el mismo rendimiento, los mismos límites o las mismas garantías.
El Data Act distingue estas situaciones. Para los servicios de infraestructura, prevé medidas que faciliten una equivalencia funcional en el destino, en las condiciones que define. Para las demás categorías, cobran mayor protagonismo las obligaciones relativas a las interfaces abiertas y la regulación de la interoperabilidad. El reglamento no obliga a un competidor a reproducir de forma idéntica cada servicio propietario. Por tanto, no convierte dos catálogos cloud en piezas intercambiables.
La trampa de las dependencias invisibles
Los contenedores y Kubernetes han popularizado una promesa: empaquetar una aplicación para ejecutarla en cualquier lugar. Efectivamente, mejoran la portabilidad, pero no transportan toda su infraestructura. Detrás del contenedor quedan los certificados, los secretos, los balanceadores de carga, las copias de seguridad y las reglas de seguridad. Incluso las herramientas que describen la infraestructura como código utilizan componentes propios de cada proveedor.
El riesgo también se esconde en la operación diaria. Un equipo acostumbrado a una consola, a sus alertas y a sus paneles de control debe adquirir nuevos hábitos. Una migración puede estar técnicamente terminada y, aun así, mermar la capacidad para diagnosticar un incidente. Por tanto, la documentación y la formación son elementos de reversibilidad, no accesorios.
El contrato puede retener sin prohibir
La dependencia no siempre adopta la forma de una cláusula que impide marcharse. Puede derivarse de un descuento obtenido a cambio de un compromiso plurianual, de un consumo mínimo o de créditos comerciales utilizables únicamente dentro del mismo ecosistema. La empresa conserva entonces la posibilidad de marcharse, pero renuncia a una ventaja o debe cumplir un compromiso distinto de los gastos de migración.
Por eso es necesario leer varios documentos de forma conjunta: contrato principal, anexos de servicio, condiciones tarifarias y acuerdos negociados. ¿Qué datos se pueden exportar? ¿En qué formatos? ¿Quién presta la asistencia? ¿Cuándo se eliminarán las copias? El Data Act regula la salida, pero la clasificación de un importe facturado o el alcance de un servicio aún pueden dar lugar a desacuerdos.
La cuestión se vuelve más delicada cuando interviene un integrador o un revendedor. El cliente no dispone necesariamente de un interlocutor único para el alojamiento, las licencias y la operación. Repartir las responsabilidades antes de la salida evita descubrir, durante el cambio, que nadie había previsto reconstruir los permisos de acceso.
La factura supera con creces los gastos de transferencia
Los cargos por salida de datos, a menudo denominados egress, se han convertido en el símbolo de la dependencia de un proveedor cloud. Su regulación importa, sobre todo cuando se trata de grandes volúmenes. Pero su eliminación en el marco del cambio de proveedor no financiará ni a los desarrolladores ni las pruebas. Los costes menos visibles pueden así convertirse en los más determinantes.
- El funcionamiento en paralelo: mantener los dos entornos durante la copia, la sincronización y las comprobaciones.
- La adaptación: modificar el código, los esquemas de datos, las políticas de seguridad y las herramientas de operación.
- La validación: comprobar el rendimiento, la integridad de los datos, las copias de seguridad y la recuperación tras un incidente.
- El riesgo operativo: prever un cambio gradual y una reversión si el servicio se degrada.
A ello se suma la gravedad de los datos: cuanto mayor es un conjunto y más conectado está a otros sistemas, más coordinación exige su traslado. Una base de datos en producción sigue evolucionando durante su transferencia. Hay que sincronizar las últimas escrituras, evitar duplicados y limitar la interrupción. El ancho de banda por sí solo no resuelve este problema.
La reversibilidad se prepara desde la compra
Para las empresas, la respuesta razonable no es necesariamente una estrategia multicloud generalizada. Repartir sistemáticamente cada aplicación entre varios proveedores puede multiplicar las competencias necesarias, los contratos y los puntos de fallo. Es preferible identificar los servicios críticos, trazar un mapa de sus dependencias y elegir conscientemente cuáles se aceptan.
Una prueba de salida limitada suele valer más que una promesa comercial. Exportar una base de datos, restaurar una copia de seguridad en otro entorno y medir el trabajo necesario permite contrastar el contrato con la realidad. Los compradores también pueden solicitar formatos documentados, un calendario de asistencia y una estimación que separe los cargos del proveedor de los trabajos internos.
¿Y ahora qué? La fecha límite de enero de 2027 debería desplazar el debate: menos hacia el precio anunciado de la salida y más hacia la capacidad real de funcionar en otro entorno. Es una perspectiva, no un resultado ya conseguido. El éxito del Data Act dependerá de su aplicación, pero también de decisiones de arquitectura y de compra menos improvisadas. La libertad de cambiar de cloud se medirá con una pregunta sencilla: ¿se ha intentado ya salir?
