Tabla de contenido
- ¿Qué es la migración de un centro de datos?
- Tipos de migración de centros de datos
- Plan de migración del centro de datos en 7 fases
- Lista de verificación para la migración de centros de datos
- Estrategia de migración de centros de datos: elección de un enfoque
- Minimización del tiempo de inactividad: replicación en vivo frente a conmutación en frío
- Factores de cronograma y costo
- Salida del centro de datos: desmantelamiento y contratos
- Mejores prácticas y errores comunes en la migración de centros de datos
- Cómo la plataforma Hystax automatiza la migración de centros de datos
Conclusiones clave
- Con la replicación en segundo plano, la única pausa real es la sincronización final y el reinicio.
- Un plan de migración de un centro de datos consta de siete fases, desde la decisión de qué se traslada hasta el cierre de la antigua sede.
- Los problemas surgen en el momento de la transición, pero comienzan antes: un servidor desconocido, una aplicación separada de su base de datos o una prueba que nunca se ejecuta.
- El sitio web antiguo seguirá cobrando hasta que canceles los contratos de alquiler, los contratos de soporte y los circuitos, cada uno con su propio plazo de preaviso.
¿Qué es la migración de un centro de datos?
La migración de centros de datos consiste en transferir aplicaciones, datos e infraestructura de soporte de un entorno de centro de datos a otro. El destino puede ser una nube pública, una nube privada, un centro de coubicación o un sitio consolidado. En una migración basada en red, las cargas de trabajo se replican en la nueva plataforma y se ejecutan allí, por lo que no se transporta ningún hardware.
Una gran parte de ese movimiento ahora está impulsado por la salida de VMware. Broadcom Finaliza el soporte general para vSphere 8.0. El 11 de octubre de 2027, los equipos que aún la utilicen necesitarán una nueva plataforma para esa fecha.
Tipos de migración de centros de datos
Pocos proyectos se ajustan a un solo tipo: se pueden consolidar dos sitios, trasladar la mayoría de las cargas de trabajo a la nube y dejar unas pocas en su lugar.
| Tipo | Lo que se mueve | Conductor típico | Consideración principal |
|---|---|---|---|
| Centro de datos a la nube | Migración de cargas de trabajo locales a una nube pública | Salida de hardware propio, capacidad elástica | Ancho de banda, costes operativos en la nube, licencias |
| Convertidor CC a CC | Transferencia de cargas de trabajo a otro sitio, a menudo con un hipervisor diferente. | Fin del contrato de arrendamiento, dejando un proveedor de virtualización | Los controladores, la configuración de red y la configuración de arranque difieren entre plataformas. |
| Consolidación | Concentrar la carga de trabajo de varios sitios en menos sitios. | Reducción de costes, integración de fusiones | Planificación de capacidad, rangos de IP superpuestos |
| Híbrido | Parte de la propiedad se traslada, el resto se queda. | Residencia de datos, latencia, hardware especializado | Un vínculo estable entre sitios durante meses o años. |
El tipo de dato cambia lo que se comprueba, no el orden de las tareas.
Plan de migración del centro de datos en 7 fases
Un plan de migración de un centro de datos convierte un proyecto de gran envergadura en una secuencia de puntos de control.
1. Definir el alcance y los criterios de éxito.
El plan comienza con una lista de lo que se traslada, lo que permanece y lo que se retira. Los criterios de éxito incluyen el período de transición, la pérdida de datos aceptable (RPO), el tiempo de recuperación (RTO) y un límite presupuestario.
2. Descubrir activos y mapear dependencias
3. Elija una estrategia por carga de trabajo.
Cada carga de trabajo tiene su propia estrategia de migración al centro de datos, y la sección siguiente describe las opciones.
4. Preparar el entorno objetivo
Las redes, el almacenamiento, los servicios de identidad, las políticas de seguridad, la capacidad y las reglas del firewall entre los sitios deben existir antes de que llegue la primera réplica. El tráfico de replicación necesita una ruta de salida desde la red de origen hasta donde se ejecute la herramienta de migración.
5. Replicar y probar
La replicación en segundo plano copia las cargas de trabajo al destino mientras la producción sigue en funcionamiento. Las migraciones de prueba inician copias en una red aislada para comprobar el arranque, el comportamiento de la aplicación y el rendimiento.
6. Cortar en ondas
Las cargas de trabajo se mueven en grupos ordenados por dependencia y riesgo empresarial. Una única migración ejecuta una réplica final, apaga el origen, inicia el destino, realiza pruebas de aceptación y redirige el tráfico al nuevo sitio.
El código fuente permanece intacto hasta que se aprueba, lo que mantiene abierta una ruta de reversión. Una vez que comienzan las oleadas, la replicación y la transición se superponen: los grupos posteriores siguen copiando mientras los primeros realizan la transición.
7. Validar, optimizar y desmantelar
Tras la aceptación, los equipos comparan el rendimiento con los valores de referencia, redimensionan los recursos, actualizan la monitorización y las copias de seguridad, y dan de baja el entorno anterior. Los contratos y la eliminación segura de datos se tratan en una sección aparte.
Lista de verificación para la migración de centros de datos
La tabla que aparece a continuación convierte el plan de migración del centro de datos en comprobaciones que se adaptan a un sistema de gestión de incidencias o a una hoja de cálculo.
| Fase | Cheques | Hecho cuando |
|---|---|---|
| 1. Alcance | Cargas de trabajo para trasladar, retener y retirar; RPO, RTO, período de transición y presupuesto establecido. | Inventario aprobado y objetivos escritos |
| 2. Descubrimiento | Inventario de servidores, almacenamiento y rutas de red; mapeo de dependencias por aplicación; configuraciones no compatibles señalizadas. | Grupos de máquinas definidos por oleada, lista de excepciones con un propietario por elemento. |
| 3. Estrategia | Reubicar, cambiar de plataforma, retirar o conservar asignado por carga de trabajo | Cada carga de trabajo tiene una estrategia. |
| 4. Objetivo | Políticas de red, firewall, plan IP, computación, almacenamiento, identidad y seguridad implementadas; copias de seguridad de las cargas de trabajo de origen y prueba de restauración. | Prueba de conectividad superada, la capacidad cubre la carga máxima, restaurar registro de prueba |
| 5. Replicar y probar | Agentes o dispositivos desplegados, replicación inicial finalizada, prueba de migración ejecutada por grupo de aplicaciones | Todas las máquinas sincronizadas, informe de prueba con problemas resueltos. |
| 6. Transición | Ventana de mantenimiento aprobada y usuarios informados, réplica final, inicio en el objetivo, pruebas de aceptación, tráfico redirigido al nuevo sitio. | Aprobación de los propietarios de la aplicación. |
| 7. Validar y salir | Monitoreo, respaldo y recuperación ante desastres en funcionamiento en el nuevo sitio; contratos cerrados, discos duros borrados. | Alertas y trabajos activos, registro de desmantelamiento |
Estrategia de migración de centros de datos: elección de un enfoque
Guía prescriptiva de AWS para migraciones a gran escala, lo que significa movimientos de 300 o más servidores, define siete estrategias, conocidas como las 7 R. Reubicar, cambiar de plataforma, trasladar y retirar son opciones comunes a gran escala, y se desaconseja la refactorización durante el traslado, ya que es la ruta más compleja.
| Estrategia | Lo que sucede | Encaja cuando |
|---|---|---|
| Retirarse | La aplicación está desactivada. | Sin valor comercial o sin conexiones entrantes durante 90 días. |
| Retener | La aplicación permanece en la fuente | Residencia de datos, hardware especial, una actualización reciente |
| Reubicar | La aplicación se traslada tal cual (copiar y mover). | Grandes volúmenes y plazos ajustados |
| Trasladarse | Un cambio a la versión en la nube de la misma plataforma. | El origen y el destino ejecutan la misma pila. |
| Replatform | La aplicación se mueve con cierta optimización. | Cambio de plataforma de la base de datos o se planea un sistema operativo más reciente |
| Recompras | La aplicación se reemplaza por un producto SaaS. | Existe una alternativa de proveedor. |
| Refactor | La aplicación se reconstruye para el destino. | Un argumento comercial sólido; generalmente después de la mudanza. |
La elección de la estrategia de migración del centro de datos también determina la cantidad de trabajo que una herramienta puede asumir. La reubicación y el traslado se ejecutan de principio a fin en la replicación. La migración a una nueva plataforma, la recompra y la refactorización requieren trabajo adicional en la aplicación, por lo que generalmente se realizan como proyectos separados.
Minimización del tiempo de inactividad: replicación en vivo frente a conmutación en frío
El tiempo de inactividad depende de cómo los datos llegan al destino. Una conmutación en frío detiene la aplicación, copia los datos y la inicia en la nueva ubicación, por lo que la interrupción dura lo que dura la copia. La replicación en vivo se ejecuta en segundo plano y la interrupción se reduce al momento de la conmutación final. La elección es crucial cuando no hay una ventana de mantenimiento lo suficientemente larga como para copiar los datos sin conexión.
| Aspecto | corte en frío | Replicación en vivo |
|---|---|---|
| Aplicación durante la copia | Interrumpido | Correr |
| Duración de la interrupción | Crece con el volumen de datos. | Sincronización final y reinicio |
| Pruebas antes del cambio | Limitado | Lanzamientos de prueba repetidos desde réplicas |
| Reintentar después de la reversión | La interrupción y la copia completa vuelven a ocurrir. | La replicación se reanuda donde se detuvo, por lo que un nuevo intento solo requiere otro breve cambio. |
| Mejor ajuste | Sistemas pequeños y no críticos | Propiedades de gran tamaño o de importancia crítica para el negocio. |
La duración de la transición final depende de la herramienta. La plataforma Hystax funciona en cinco etapas: iniciar la replicación, almacenar los datos en el destino, automatizar la orquestación, ejecutar las migraciones de prueba y realizar la transición final, que suele durar entre 1 y 3 minutos. Los resultados dependen de la carga de trabajo y del destino.
Factores de cronograma y costo
Algunos factores clave determinan cuánto tiempo tarda una migración y cuál es su coste.
| Factor | Efecto en la línea de tiempo | Efecto sobre el coste |
|---|---|---|
| Número y tamaño de las máquinas virtuales | Replicación inicial más larga | Más almacenamiento y ancho de banda de destino |
| Tasa de cambio de datos | Sincronización final más grande | Ejecución paralela más larga de ambos sitios |
| Ancho de banda entre sitios | Establece la velocidad de la primera copia | Actualizaciones de enlaces o circuitos temporales |
| Complejidad de dependencia | Más olas para coordinar | Más horas de proyecto |
| Licencias | Tiempo de revisión por objetivo | Licencias que no se transfieren tal cual: RHEL migrado a AWS llega como BYOL (Traiga su propia licencia), por lo que necesita suscripciones elegibles de Red Hat o un cambio a los precios de AWS con licencia incluida. |
| Herramientas de migración | La herramienta de migración debe implementarse antes de que comience la replicación. | El tamaño del cómputo depende de cuántas máquinas se replican simultáneamente. |
Salida del centro de datos: desmantelamiento y contratos
El cierre del antiguo sitio es la fase final, y gran parte de ella implica trabajo contractual: plazos de preaviso para arrendamiento o colocación, soporte de hardware, circuitos de red y licencias vinculadas al hardware antiguo. Los plazos de preaviso pueden ser largos, así que consúltelos durante la planificación, no después de la transición. Una vez eliminadas las cargas de trabajo, desactive las aplicaciones marcadas para su retirada durante la fase de detección, borre o destruya las unidades y archive los certificados de borrado seguro y los registros de activos.
Cuéntanos qué carrera realizas hoy y te trazaremos la ruta.
¡Gracias por tu solicitud!
Nos pondremos en contacto contigo pronto.
Mejores prácticas y errores comunes en la migración de centros de datos
Las filas que aparecen a continuación muestran cómo se ven las fases anteriores cuando una de ellas se ejecuta con prisas.
| Error | Lo que sucede | Buenas prácticas |
|---|---|---|
| Inventario incompleto | Servidores olvidados reaparecen tras el cierre del antiguo sitio web. | Los datos de descubrimiento se cotejan con el tráfico de red y la monitorización. |
| Dependencias faltantes | Una aplicación se mueve sin su base de datos. | Grupos de dependencia fijados antes del plan de oleadas |
| Migraciones de prueba omitidas | En el momento de la transición aparecen problemas de arranque y de controladores. | Lanzamientos de prueba repetidos en una red aislada |
| Una transición de big bang | Un solo fallo afecta a toda la propiedad. | Ondas con una trayectoria de retroceso definida |
| Licencias pasadas por alto | Cargos inesperados o casos de incumplimiento | Revisión de licencias por plataforma de destino |
| Capacidad de la red subestimada | Retrasos en la replicación y ventanas deslizantes | Pruebas iniciales de ancho de banda, con compresión y deduplicación. |
| desmantelamiento anticipado | No hay plan B cuando aparece un problema tarde | Una fuente de solo lectura que se conserva durante un período acordado. |
Cómo la plataforma Hystax automatiza la migración de centros de datos
La plataforma Hystax combina tres productos: Hystax Migration, Hystax Disaster Recovery y Hystax Backup. Migración Traslada las cargas de trabajo entre centros de datos y nubes siguiendo un patrón de migración gradual: replicación inicial, réplicas incrementales, lanzamientos de prueba y una transición final.
Las fuentes incluyen VMware, OpenStack y oVirt a nivel de plataforma, además de cualquier otra plataforma o servidor físico a nivel de máquina.
Los objetivos se dividen en dos grupos. Las plataformas de nube privada y virtualización incluyen OpenStack, Servicios Red Hat OpenStack en OpenShift, VMware, oVirt, Nebulosa abierta, virtuoso, Apache CloudStack, KubeVirt, Red Hat OpenShift Virtualization, Oracle Linux KVM y Oracle Linux Virtualization Manager. Las nubes públicas incluyen AWS, Microsoft Azure, Google Cloud, Alibaba Cloud, CloudSigma y PILAR como una opción soberana europea.
La replicación puede ejecutarse de dos maneras. Un agente interno se instala dentro del sistema operativo invitado y cubre cualquier plataforma de virtualización o servidor físico. Para las fuentes de VMware, oVirt y OpenStack, un dispositivo externo hace lo mismo sin un agente en cada sistema operativo invitado. En VMware, lee los discos a través de la biblioteca VDDK de Broadcom, que es Ya no está disponible para su descarga pública.. El agente interno no lo necesita.
A Direct2Target Esta opción envía los datos replicados directamente a los discos de destino mediante un agente dedicado, sin necesidad de acceder a la API de la plataforma de destino. Cualquier entorno con acceso de escritura a nivel de disco puede funcionar como destino, lo que incluye plataformas con acceso limitado a la API, infraestructura aislada y sitios perimetrales.
Tres casos de clientes demuestran la eficacia del software a gran escala:
- A empresa global de nóminas Se pasó de VMware a Red Hat OpenStack Services en OpenShift: 500 máquinas virtuales en la primera fase, luego más de 4500 a lo largo de un programa de dos años. En un Entrada de blog de septiembre de 2026, Red Hat informó que el programa contaba con 9000 máquinas virtuales Windows y Linux, incluyendo cargas de trabajo de una nube OpenStack heredada. Posteriormente, necesitaron una alternativa a VMware Site Recovery Manager, por lo que el proyecto se convirtió en una prueba de concepto para la recuperación ante desastres.
- CompuGroup Medical En pocos meses, migramos más de 5000 máquinas virtuales entre plataformas basadas en OpenStack, utilizando una implementación que se ejecuta dentro del entorno del cliente sin acceso a Internet.
- A proveedor global de ciberseguridad Ha migrado miles de máquinas virtuales de VMware a RHOSO, de las más de 10.000 previstas, y las transiciones finales se completaron en cuestión de minutos.
Una vez que las cargas de trabajo se ejecutan en el nuevo centro de datos, recuperación ante desastres y copias de seguridad pueden protegerlos allí, y el Regla de respaldo 3-2-1 Describe cuántas copias conservar.
Deje su correo electrónico empresarial y un ingeniero de Hystax le guiará a través de una migración de prueba.
¡Gracias por tu solicitud!
Nos pondremos en contacto contigo pronto.
Preguntas frecuentes
¿Cuánto tiempo tarda la migración de un centro de datos?
La duración depende del volumen de datos, el ancho de banda, las dependencias y la profundidad de las pruebas. Los proyectos de clientes de Hystax han durado desde unos pocos meses hasta aproximadamente dos años, según el alcance.
¿Cuál es la diferencia entre la migración de un centro de datos y la migración a la nube?
Ambos procesos se superponen: migrar de un centro de datos local a una nube pública implica ambas cosas. Migración a la nube También abarca los traslados entre nubes. La migración de centros de datos incluye traslados entre ubicaciones, consolidación de centros de datos y configuraciones híbridas.
¿Es posible realizar una migración de centro de datos con un tiempo de inactividad mínimo?
La replicación en vivo mantiene las aplicaciones en funcionamiento durante la copia, por lo que la interrupción se limita al cambio final. En Hystax Platform, el cambio suele tardar entre 1 y 3 minutos. Este es un promedio, no una garantía.
¿El software de migración es compatible con servidores físicos?
Sí. En Hystax Platform, los servidores físicos se replican mediante agentes internos para Windows y Linux. Hay dos limitaciones a tener en cuenta: la migración P2V no convierte la BIOS a UEFI, por lo que una máquina con BIOS necesita un destino que admita el arranque de BIOS. El agente de Linux tampoco se ejecuta en sistemas con arranque seguro habilitado.
¿Qué ocurre con el antiguo centro de datos tras la migración?
Permanece intacto durante un período acordado como medida de respaldo, luego se desactiva: se cierran los contratos, se borran los datos de las unidades y se archivan los registros, como se describe en Salida del centro de datos.
¿Cuánto cuesta la migración de un centro de datos?
No existe una cifra única aplicable. Depende del número de máquinas virtuales, la tasa de cambio de datos, el ancho de banda, los entornos de prueba, las licencias y el tiempo que ambos sitios funcionen en paralelo.