Plan de salida cloud: portabilidad de datos y cargas

La reversibilidad se diseña antes de necesitarla

Un plan de salida no obliga a ejecutar una migración ni a duplicar toda la infraestructura en otro proveedor. Su objetivo es saber qué habría que trasladar, qué elementos no son portables de forma directa y qué coste, plazo, riesgo y trabajo operativo tendría una alternativa.

El Reglamento de Datos de la UE (Data Act), capítulo VI, aborda obstáculos al cambio entre determinados servicios de tratamiento de datos y contiene obligaciones sobre contratos, datos exportables e interoperabilidad. El alcance depende del servicio y del papel de cada parte; el plan técnico no sustituye la revisión del contrato ni el análisis jurídico.

Ficha de salida por servicio

Completa una ficha por carga prioritaria:

• Datos: formatos disponibles, volumen, clasificación, región, dependencias y método probado de exportación e importación.
• Aplicación: imágenes, código, licencias, configuración, infraestructura como código y servicios gestionados usados.
• Identidad y seguridad: federación, cuentas de emergencia, claves, certificados, políticas, logs y controles que deberán recrearse.
• Conectividad: DNS, rangos IP, VPN, enlaces privados, balanceadores, reglas y consumidores externos.
• Contrato y operación: asistencia de salida, preavisos, cargos aplicables, responsabilidades, contactos, soporte y fecha de terminación.
• Validación: pruebas funcionales, integridad de datos, rendimiento, reconciliación y criterios de aceptación del negocio.

Marca cada componente como portable, sustituible, dependiente de una migración o pendiente de análisis. No llames “portátil” a una base de datos hasta haber probado que se pueden extraer datos, esquema, roles y rutinas necesarios y que la plataforma destino puede operarlos.

Prueba controlada sin cortar producción

Elige una carga de bajo riesgo que represente patrones reales. Exporta una copia, recréala en un entorno aislado y mide tiempos, transferencias, transformaciones, dependencias ausentes y esfuerzo manual. Compara los resultados con el RTO/RPO acordado y documenta qué no se pudo trasladar.

Por ejemplo, una aplicación puede empaquetarse con contenedores y seguir dependiendo de una base de datos propietaria, identidad del proveedor y colas gestionadas. Una alternativa no tiene que replicar cada servicio: puede sustituirlos, pero debe diseñarse, probarse y presupuestarse como parte de la salida.

Revisa el plan en renovaciones contractuales y tras cambios arquitectónicos. Complementa esta guía con la matriz de responsabilidad compartida cloud y los guardarraíles cloud como código.