Migrar datos no consiste simplemente en copiar archivos de un servidor a otro.
Una migración puede implicar bases de datos, aplicaciones, permisos, usuarios, integraciones, servidores y procesos que deben seguir funcionando cuando la información cambie de ubicación.
Esto resulta especialmente importante cuando trasladamos sistemas a la nube, cambiamos de proveedor, sustituimos infraestructura antigua o implantamos una nueva aplicación empresarial.
Un plan de migración de datos permite identificar qué debemos trasladar, qué dependencias existen, cómo realizaremos el cambio y qué haremos si algo no funciona como estaba previsto.
El objetivo no es únicamente mover información. Es hacerlo sin perder datos y reduciendo al mínimo el impacto sobre la actividad de la empresa.
¿Qué es un plan de migración de datos?
Es el conjunto de decisiones, tareas y comprobaciones necesarias para trasladar información desde un entorno de origen hacia otro de destino.
Puede tratarse de una migración relativamente sencilla, como mover documentos a un nuevo servidor, o de un proyecto mucho más complejo donde intervienen aplicaciones, bases de datos e integraciones con otros sistemas.
Un buen plan debería permitir responder, antes de empezar, a preguntas como:
¿Qué información vamos a migrar? ¿Qué aplicaciones dependen de ella? ¿Cuánto tiempo puede estar interrumpido el servicio? ¿Cómo comprobaremos que los datos han llegado correctamente? ¿Podemos volver atrás si aparece un problema?
Resolver estas cuestiones antes de la migración reduce considerablemente la improvisación durante el cambio.
1. Inventariar qué vamos a migrar
El primer paso es conocer el entorno actual.
Antes de copiar nada debemos identificar qué datos, servidores, aplicaciones y servicios están involucrados.
No basta con saber que existe una carpeta de 500 GB o una base de datos de determinado tamaño.
Debemos entender qué contiene esa información y quién depende de ella.
Por ejemplo, una base de datos puede estar siendo utilizada por una aplicación interna, un sistema de facturación y una integración que se ejecuta cada noche.
Si migramos únicamente la base de datos sin conocer esas relaciones, podemos dejar alguno de esos procesos apuntando al servidor antiguo.
El inventario también ayuda a decidir qué merece la pena trasladar.
Una migración puede ser una buena oportunidad para eliminar información obsoleta, archivos temporales, copias duplicadas o sistemas que ya no deberían continuar operativos.
Migrar todo “porque está ahí” puede trasladar también problemas acumulados durante años.
2. Identificar las dependencias
Esta es una de las fases más importantes.
Los sistemas empresariales rara vez funcionan completamente aislados.
Una aplicación puede depender de una base de datos, un recurso compartido, Active Directory, DNS, una API externa o un determinado servidor de correo.
También pueden existir dependencias menos evidentes, como una tarea programada que genera un fichero cada noche o una hoja de cálculo que consulta directamente una base de datos.
Antes de definir el orden de la migración debemos localizar estas relaciones.
Los sistemas que dependen estrechamente unos de otros pueden necesitar migrarse conjuntamente o dentro de la misma ventana de cambio.
Esta es una de las razones por las que las migraciones complejas suelen organizarse por grupos u oleadas, en lugar de mover toda la infraestructura de una sola vez.
3. Diseñar el entorno de destino
Una vez conocemos qué tenemos y cómo se relaciona, podemos decidir cómo será el destino.
No debemos asumir que la nueva infraestructura tiene que ser una copia exacta de la anterior.
Una migración puede utilizarse para redimensionar servidores, actualizar sistemas operativos, modificar almacenamiento o cambiar la arquitectura de determinadas aplicaciones.
Si el destino es cloud, también tendremos que decidir qué servicios utilizaremos, cómo estará diseñada la red, dónde residirán los datos y qué mecanismos de seguridad, monitorización y backup necesitamos.
En nuestro artículo sobre nube pública, privada e híbrida explicamos por qué la arquitectura debería elegirse según las características de cada carga de trabajo y no únicamente por preferencia tecnológica.
También debemos comprobar la compatibilidad.
Versiones de sistemas operativos, motores de bases de datos, librerías, licencias o aplicaciones pueden comportarse de forma diferente en el nuevo entorno.
Descubrir una incompatibilidad durante la ventana de migración es mucho más problemático que detectarla durante la fase de diseño.
4. Preparar una copia de seguridad y un plan de reversión
Antes de modificar información crítica debemos disponer de una copia recuperable.
Pero backup y plan de reversión no son exactamente lo mismo.
La copia de seguridad protege los datos.
El rollback o plan de reversión define cómo volveremos al entorno anterior si la migración falla.
Por ejemplo, podemos tener un backup completo de una base de datos y, aun así, necesitar varias horas para reconstruir todo el servidor.
Por eso conviene definir previamente qué condiciones harán que demos la migración por fallida y cuánto tiempo tenemos disponible para volver atrás.
Un plan de reversión debería indicar qué sistemas deben restaurarse, qué cambios deben deshacerse y quién toma la decisión de abortar.
No debería diseñarse cuando ya tenemos la aplicación caída.
También debemos comprobar que las copias pueden restaurarse. En nuestra guía sobre copias de seguridad en la nube explicamos por qué disponer de un archivo de backup no es suficiente si nunca hemos validado su recuperación.
5. Revisar seguridad, permisos y accesos
Los datos no deberían llegar al nuevo entorno con permisos improvisados.
Antes de migrar debemos identificar qué usuarios, grupos y aplicaciones necesitan acceso y qué privilegios deberían conservar.
También puede ser una oportunidad para eliminar permisos que se han ido acumulando y que ya no tienen sentido.
Si cambiamos de infraestructura tendremos que revisar aspectos como cuentas de servicio, reglas de firewall, accesos remotos, credenciales, certificados y conexiones entre aplicaciones.
La seguridad debe diseñarse antes de poner el nuevo entorno en producción.
También debemos considerar los requisitos de protección y localización de la información cuando existan obligaciones legales, contractuales o internas.
Migrar a cloud no elimina estas responsabilidades.
6. Decidir cómo se transferirán los datos
No todas las migraciones utilizan el mismo método.
En un entorno pequeño podemos detener una aplicación, realizar una copia final, trasladar los datos y arrancar el nuevo sistema.
Pero si hablamos de grandes volúmenes o de servicios que deben permanecer disponibles, quizá necesitemos una migración progresiva.
Una estrategia habitual consiste en realizar primero una copia inicial de la mayor parte de la información y mantener posteriormente una sincronización de los cambios hasta el momento del corte definitivo.
Así reducimos la cantidad de datos que deben transferirse durante la ventana de interrupción.
La estrategia dependerá del volumen, del ancho de banda disponible, del tipo de datos y del tiempo máximo que el negocio puede permanecer sin servicio.
Una migración de varios terabytes a través de Internet, por ejemplo, debe dimensionarse teniendo en cuenta la velocidad real de transferencia y no únicamente la capacidad nominal de la conexión.
7. Realizar pruebas antes de producción
Una migración importante no debería estrenarse directamente sobre el sistema productivo siempre que podamos evitarlo.
Conviene preparar un entorno de prueba o realizar una migración piloto.
Esto permite comprobar tiempos de transferencia, compatibilidad, rendimiento y funcionamiento de las aplicaciones antes del cambio definitivo.
Las pruebas deberían reproducir las operaciones que realmente utiliza la empresa.
No basta con comprobar que el servidor responde.
Debemos verificar que los usuarios pueden autenticarse, las aplicaciones encuentran sus datos, las integraciones funcionan, los permisos son correctos y las operaciones principales pueden completarse.
Cuando existen bases de datos o grandes conjuntos de información también conviene comprobar integridad y consistencia, por ejemplo mediante recuentos de registros, comparaciones o mecanismos de verificación adecuados al sistema.
Una prueba piloto ayuda además a calcular de forma más realista cuánto durará la migración definitiva.
8. Preparar la ventana de migración
La ejecución debería estar suficientemente detallada para que cada persona sepa qué debe hacer y en qué momento.
Conviene definir la secuencia de tareas, responsables, contactos, tiempos previstos y criterios de validación.
También hay que decidir cuándo se producirá el corte.
Si los usuarios continúan modificando información en el sistema antiguo mientras estamos trasladando los últimos datos, podemos acabar con diferencias entre origen y destino.
Dependiendo del sistema puede ser necesario establecer un periodo de solo lectura, detener temporalmente determinadas aplicaciones o sincronizar los cambios hasta el momento del corte.
La ventana debe elegirse teniendo en cuenta la actividad real de la empresa.
Realizarla fuera del horario habitual puede reducir el impacto, pero necesitamos asegurarnos igualmente de que estarán disponibles las personas necesarias para validar el resultado y resolver cualquier incidencia.
9. Validar antes de dar la migración por terminada
Que los datos hayan terminado de copiarse no significa que la migración haya terminado.
Antes de abrir el nuevo entorno a todos los usuarios debemos realizar las comprobaciones previstas.
Hay que verificar acceso, permisos, aplicaciones, bases de datos, integraciones, rendimiento y cualquier proceso crítico para la actividad.
También debemos comprobar que los datos del destino corresponden con los esperados.
En algunas migraciones bastará con revisar archivos y permisos. En otras necesitaremos validar registros, transacciones y resultados de aplicaciones.
Lo importante es disponer de criterios de aceptación definidos antes de empezar.
Así evitamos decidir sobre la marcha si un resultado “parece suficientemente bueno”.
10. Mantener temporalmente el entorno anterior cuando sea necesario
Otro error es eliminar inmediatamente la infraestructura antigua porque la nueva ya parece funcionar.
Dependiendo de la migración puede ser recomendable mantener el entorno anterior durante un periodo controlado, normalmente desconectado de la operativa habitual o protegido frente a modificaciones.
Esto proporciona un margen adicional mientras comprobamos el funcionamiento del nuevo sistema.
Pero tampoco debemos mantener indefinidamente dos entornos activos.
Una vez superado el periodo de validación y confirmado que ya no necesitamos volver atrás, debemos retirar de forma ordenada servidores, recursos, cuentas y servicios antiguos.
Mantener sistemas olvidados aumenta costes y puede crear riesgos de seguridad.
Migrar por fases reduce el riesgo
No todas las migraciones deberían realizarse en un único gran cambio.
Cuando existen varias aplicaciones o departamentos podemos organizarlos en oleadas de migración.
Los primeros grupos pueden incluir sistemas menos críticos o con pocas dependencias.
Eso permite aprender del proceso antes de trasladar las cargas más complejas.
Las siguientes fases pueden incorporar las mejoras detectadas durante las anteriores.
Migrar progresivamente también facilita identificar dependencias que no aparecieron durante el análisis inicial.
El objetivo no es dividir artificialmente cualquier proyecto, sino reducir el número de variables que cambian simultáneamente.
Migrar datos a la nube: ventajas y riesgos
Trasladar sistemas a cloud puede proporcionar flexibilidad, facilidad para ampliar recursos, nuevos mecanismos de redundancia y menor dependencia de infraestructura física propia.
Pero una migración mal preparada también puede introducir problemas.
Podemos encontrar costes inesperados, aplicaciones incompatibles, latencia, conexiones mal dimensionadas o dependencias que no habíamos detectado.
La nube tampoco elimina la administración técnica.
Los sistemas siguen necesitando permisos, actualizaciones, backups, monitorización y controles de seguridad.
Por eso la pregunta no debería ser únicamente si merece la pena migrar a la nube, sino qué sistemas tienen sentido allí y cómo realizaremos la transición.
Un análisis previo permite seleccionar qué cargas trasladar, cuáles mantener temporalmente y qué arquitectura utilizar para cada una.
Errores habituales en una migración de datos
Muchos problemas proceden de empezar a mover información demasiado pronto.
Migrar sin inventario puede dejar sistemas olvidados. No estudiar dependencias puede romper aplicaciones. No realizar pruebas puede descubrir incompatibilidades durante el corte. Y no disponer de rollback puede convertir una incidencia solucionable en una interrupción prolongada.
Otro error frecuente es centrar todo el proyecto en la transferencia de datos.
La parte técnica es fundamental, pero también debemos coordinar usuarios, proveedores y responsables de negocio.
Un sistema puede haberse migrado perfectamente desde el punto de vista técnico y seguir provocando un problema si los empleados no saben cómo acceder o si una integración externa continúa utilizando la dirección antigua.
Un buen plan reduce la incertidumbre
No existe un único procedimiento válido para cualquier migración.
Mover un servidor de archivos, trasladar una base de datos crítica o migrar toda la infraestructura de una empresa son proyectos muy diferentes.
Pero todos deberían compartir una misma lógica:
conocer el origen, entender las dependencias, diseñar el destino, proteger los datos, probar, ejecutar con un plan de reversión y validar antes de retirar el sistema anterior.
Cuanto más crítica sea la información, mayor debe ser el nivel de preparación.
La migración no debería depender de improvisaciones durante la ventana de cambio.
En ENDEOS diseñamos y ejecutamos migraciones y servicios cloud para empresas, creando entornos de prueba y migración para validar los sistemas antes de afectar a la infraestructura productiva.