Cuando una empresa decide cambiar de proveedor de IT o migrar su infraestructura en Azure, el foco natural está en lo que llega: la nueva solución, el nuevo partner, los nuevos sistemas funcionando. Lo que queda atrás —los backups del sistema anterior— raramente recibe la misma atención.
Y sin embargo, cerrarlos bien es obligatorio. Y cerrarlos rápido puede ser un error.
El período de transición que nadie planifica
Hay un detalle que se pasa por alto con frecuencia en los cambios de proveedor: el sistema de backup antiguo no puede apagarse el mismo día que el nuevo empieza a funcionar.
La razón no es técnica. Es de política de empresa.
Si tu organización tiene definida una política de copias de seguridad —algo que toda empresa debería tener antes de plantearse un cambio de proveedor—, esa política incluye un período de retención: el tiempo mínimo durante el cual los datos de backup deben estar disponibles para poder recuperarse. Puede ser 30 días, 90 días, un año o más, dependiendo del tipo de dato y del sector.
Ese plazo no desaparece porque hayas cambiado de proveedor.
Si tu política dice que los datos de facturación deben conservarse durante un año, y cambias de plataforma de backup en junio, los datos respaldados en enero todavía deben estar accesibles en enero del año siguiente. Aunque el nuevo sistema ya esté funcionando perfectamente. Aunque el proveedor anterior ya no gestione nada.
El resultado práctico: durante un período acordado, ambos sistemas deben coexistir. El antiguo sigue activo, sigue almacenando, sigue facturando en Azure. Y el nuevo está ya en marcha, protegiendo los datos nuevos.
Lo que establece ISO 27001 al respecto
ISO 27001 —el estándar internacional de referencia en seguridad de la información, del que hablamos en detalle en este artículo sobre estrategia de backup para pymes— requiere que las organizaciones definan y documenten formalmente su política de backup, incluyendo los plazos de retención por tipo de dato.
Lo que la norma no dice explícitamente, pero que se desprende directamente de su aplicación, es lo siguiente: cuando se produce una migración de plataforma, la política de retención sigue vigente. No se puede interrumpir el acceso a los datos protegidos simplemente porque el proveedor ha cambiado.
Esto tiene consecuencias concretas:
- El cierre del sistema antiguo debe planificarse con antelación, no improvisarse al final de la migración.
- El período de coexistencia de ambos sistemas debe acordarse formalmente antes de empezar, no descubrirse a posteriori.
- Alguien tiene que ser responsable de mantener el sistema antiguo operativo durante ese período, verificar que los datos siguen siendo accesibles y documentar cuándo se alcanza la fecha de cierre.
Sin esta planificación, las empresas se encuentran en una de estas dos situaciones igualmente incómodas: o apagan el sistema antiguo demasiado pronto —incumpliendo su propia política de retención— o lo dejan encendido indefinidamente porque nadie acordó cuándo apagarlo.
El coste de no acordarlo antes
En Azure, esto tiene un impacto económico directo y visible: un Recovery Services Vault —el almacén donde residen las copias de seguridad— factura mientras existe, independientemente de si está en uso activo o en período de retención pasiva.
Si la migración no incluía un plan de cierre del vault antiguo, ese vault puede llevar meses o años activo sin que nadie lo esté gestionando activamente. Con datos que ya no se necesitan para operación diaria, pero que todavía no se pueden borrar por cumplimiento. Y con una factura que sigue llegando.
Esto es exactamente el tipo de residuo que crece en silencio y que, como señalamos en este otro artículo, termina complicando cualquier intervención futura sobre la infraestructura.
Cómo debería planificarse la transición
Una migración de backups bien hecha incluye tres fases diferenciadas, y las tres son igual de importantes:
Antes de migrar: acordar por escrito el período de retención aplicable a cada tipo de dato, y establecer la fecha de cierre del sistema antiguo. Esta fecha debe derivarse de la política de backup, no de la fecha de firma del contrato con el nuevo proveedor.
Durante la coexistencia: verificar periódicamente que el sistema antiguo sigue siendo accesible y que las restauraciones son posibles si se necesitan. Documentar el estado. No «olvidarse» del vault antiguo hasta que llegue la fecha de cierre.
Al cerrar el sistema antiguo: seguir el proceso de cierre ordenado. En Azure, esto implica desactivar configuraciones de seguridad en el orden correcto, dar de baja los agentes registrados y eliminar el vault de forma controlada. Para los responsables técnicos que quieran ver exactamente cómo se hace, hemos documentado el proceso y publicado el script que utilizamos: Delete-BackupVault.ps1 (enlace al post técnico).
Las copias de seguridad no son solo un problema técnico
Lo que hace complejo este tipo de transiciones no es la tecnología. La tecnología existe, los procesos están definidos, las herramientas están disponibles.
Lo complejo es que la migración toca a la vez tres áreas que raramente coordinan bien: el proveedor saliente, el proveedor entrante y la dirección de la empresa, que es quien tiene que validar cuánto tiempo quiere mantener acceso a los datos del sistema antiguo.
Cuando esa coordinación no existe, el resultado habitual es que nadie cierra nada, o que se cierra demasiado rápido. En ambos casos, la empresa asume un riesgo que podría haberse evitado con una conversación al principio del proceso.
Si vas a cambiar de proveedor o llevas tiempo sin revisar tus backups
Si tu empresa está en proceso de migración, si acabas de cambiar de proveedor y no tienes claro el estado del sistema antiguo, o si simplemente no recuerdas cuándo se definió por última vez vuestra política de retención, podemos ayudarte a poner orden.
Sin alarmar, sin tecnicismos innecesarios: una revisión honesta de la situación, un plan de transición claro y, si hace falta, la ejecución ordenada del cierre. Tu equipo descansará tranquilo sabiendo que los backups están en regla, y tú tendrás la documentación que respalda que se hizo correctamente.
¿Hablamos? Cuéntanos tu caso y buscamos la solución juntos.
