Migración de centros de datos
CPD a CPD, on-premise a CPD, CPD a cloud, cloud a CPD y entre clouds. Con inventario, pruebas y un plan de vuelta atrás que existe de verdad.
El problema
Una migración de centro de datos no falla por la parte técnica evidente. Copiar máquinas de un sitio a otro es, hoy, un problema resuelto. Falla por lo que nadie tenía apuntado.
La lista es siempre parecida: un servidor que resulta que da servicio a un proceso crítico y que nadie sabía que existía; una aplicación que apunta a una dirección IP fija en lugar de a un nombre; un certificado emitido a mano hace tres años; una integración con un tercero que valida el origen de las conexiones; una licencia atada al identificador de una máquina; un proceso que se ejecuta a las dos de la madrugada y que nadie recuerda.
El otro gran motivo de fracaso es la ausencia de vuelta atrás. Cuando el plan asume que todo saldrá bien, cualquier imprevisto obliga a improvisar en plena ventana de cambio, con el servicio parado y con prisa.
Qué hace IT Encore
Llevamos ejecutando migraciones de infraestructura desde 2013 y es una de nuestras líneas de trabajo más constantes. Hemos migrado entre centros de datos, desde instalaciones del cliente hacia CPD, desde CPD hacia cloud público y en sentido contrario, y entre plataformas de virtualización distintas.
La metodología es siempre la misma y su parte más laboriosa no es la ejecución, sino el descubrimiento: levantar el inventario real, encontrar las dependencias que no están documentadas y decidir en qué orden se mueve cada cosa.
El proyecto se ejecuta por oleadas, agrupando sistemas por dependencias, y con el entorno de origen disponible hasta que cada oleada queda validada. La vuelta atrás es un procedimiento escrito y probado, no una intención.
Metodología de migración
- 1
Discovery
Descubrimiento activo de la infraestructura: qué hay encendido, qué escucha en red y qué se comunica con qué.
- 2
Inventario
Sistemas, versiones, recursos, almacenamiento, licencias y contratos de soporte asociados.
- 3
Dependencias
Mapa de relaciones entre sistemas, integraciones externas, certificados, DNS y direcciones fijas.
- 4
Diseño del destino
Arquitectura de llegada: cómputo, almacenamiento, red, perímetro, copia y alta disponibilidad.
- 5
Conectividad
Enlace entre origen y destino con capacidad suficiente para la réplica y para la fase de convivencia.
- 6
Réplica
Copia previa de los datos con el entorno de origen en producción, y sincronizaciones incrementales.
- 7
Pruebas
Arranque de sistemas en el destino en red aislada y validación funcional antes de tocar producción.
- 8
Plan de migración
Oleadas por dependencia y criticidad, con calendario, responsables y criterios de éxito.
- 9
Ventana de cambio
Ejecución en la franja acordada, con sincronización final, corte y conmutación.
- 10
Rollback
Procedimiento de vuelta atrás definido y probado, con punto de no retorno explícito.
- 11
Validación
Comprobación funcional, de rendimiento, de integraciones y de copia en el destino.
- 12
Estabilización
Acompañamiento posterior, ajuste fino y retirada ordenada de la infraestructura de origen.
Tipos de migración que ejecutamos
CPD a CPD
Cambio de proveedor de centro de datos o consolidación de varias ubicaciones en una.
On-premise a CPD
Salida de los servidores de la oficina hacia un centro de datos profesional.
CPD a cloud
Traslado de cargas a cloud público, completo o parcial, con arquitectura rediseñada.
Cloud a CPD
Retorno de cargas estables cuyo coste en cloud público ha dejado de compensar.
Cloud a cloud
Cambio de proveedor de cloud público o reparto entre varios.
Entre plataformas
Cambio de hipervisor o de sistema de almacenamiento. Ver VMware a Proxmox.
Riesgos que controlamos
Sistemas no inventariados
El descubrimiento activo encuentra lo que no aparece en la documentación, que siempre es algo.
Direcciones IP fijas en aplicaciones
Se detectan antes del cambio para decidir si se conserva el direccionamiento o se corrige la aplicación.
Licencias atadas al hardware
Identificación previa y gestión con el fabricante antes de la ventana, no durante.
Ventana insuficiente
La réplica previa reduce el corte al mínimo: en la ventana sólo se sincroniza el delta.
Integraciones con terceros
Proveedores que filtran por origen o que exigen preaviso se gestionan como parte del proyecto.
Ausencia de vuelta atrás
El origen se mantiene operativo y el procedimiento de reversión está escrito y probado.
Preguntas frecuentes
¿Cuánto tiempo estará parado el servicio?
El objetivo es reducir la parada a la sincronización final y la conmutación. Con réplica previa, muchos sistemas se mueven con cortes de minutos. Las bases de datos grandes y los sistemas con dependencias complejas requieren ventanas mayores, que se acuerdan en el plan.
¿Se migra todo de una vez?
Casi nunca, y no lo recomendamos. Se trabaja por oleadas agrupadas por dependencia, empezando por sistemas de bajo impacto para validar el procedimiento. Un "big bang" sólo tiene sentido en entornos muy pequeños o cuando las dependencias no permiten separar.
¿Y si algo sale mal durante la ventana?
Se ejecuta la vuelta atrás. Por eso el entorno de origen se mantiene disponible y el punto de no retorno está definido de antemano: hasta ese punto, revertir es una operación prevista y ensayada.
¿Pueden migrar sin gestionar después la plataforma?
Sí. La migración se contrata como proyecto cerrado. Muchos clientes continúan después con nosotros en servicios gestionados, pero no es una condición.
Servicios relacionados
Interconexión de centros de datos
Enlaces dedicados, redes privadas, VPN, BGP, redundancia y replicación entre ubicaciones.
Ver servicioCloud privado gestionado
Infraestructura dedicada y aislada en nuestros centros de datos, diseñada y administrada por nosotros.
Ver servicioMigración de VMware a Proxmox
Metodología para cambiar de hipervisor sin perder disponibilidad ni control del proyecto.
Ver servicioPlanifique su migración
El descubrimiento y el inventario son el primer paso, y ya aportan valor por sí solos.