Migración de data center sin downtime: fases y errores que cuestan meses

Migrar un data center físico sin detener la operación es uno de los proyectos más riesgosos que puede ejecutar una empresa. La mayoría se subestima en tiempo y costo porque se confunde ‘mover equipos’ con ‘mover operación’.

Lo crítico no es la logística del hardware: lo crítico es mover dependencias que a veces ni siquiera están documentadas.

Las cinco fases que separan un proyecto exitoso de uno que se atrasa seis meses

Una migración sin downtime estructurada sigue cinco fases. Saltarse alguna es la causa más común de sobrecostes.

1. Discovery e inventario completo: cada servidor, cada IP, cada dependencia upstream y downstream. Herramientas como Device42 o netbox ayudan, pero la verificación manual es inevitable.
2. Diseño de arquitectura objetivo: definir qué se queda, qué se mueve, qué se transforma en el camino. Incluye red, storage, identidad, y monitoreo.
3. Plan de ventanas de corte y rollback: cada componente a mover debe tener un procedimiento de rollback probado. Sin rollback, no hay go-live.
4. Pruebas en paralelo: durante una ventana extendida, ambos entornos operan simultáneamente. La comparación revela diferencias reales que el diseño no anticipó.
5. Go-live y estabilización: el corte real con equipo disponible 24/7 durante al menos 72 horas. La estabilización toma más tiempo que el corte mismo.

Errores comunes que cuestan meses

1. Subestimar dependencias ocultas: servicios que ‘nadie usa’ pero que otro sistema crítico llama internamente.
2. No probar bajo carga real: pruebas con datos sintéticos que no reflejan picos reales. La primera hora de operación post-go-live es donde aparecen los problemas.
3. No tener rollback funcional: tener documentado el rollback es distinto a haberlo probado. Si nunca lo probaste, no es un rollback: es una esperanza.
4. Subestimar el tiempo del equipo humano: las migraciones exitosas tienen un project manager dedicado y equipo disponible 24/7 durante go-live.

Cuándo conviene hacerlo por fases vs fin de semana largo

Si la operación es 24/7 y la carga es crítica, la migración por fases con paralelo extendido es la única opción realista. Si tienes ventanas nocturnas o fines de semana con tráfico bajo, una migración concentrada puede ser viable.

El factor decisivo es el costo de una hora de downtime, no la complejidad técnica. Si una hora cuesta más que el costo del proyecto, no escatimes en planificación.

Cómo elegir proveedor para el destino

El proveedor destino debe tener capacidad demostrada en migraciones similares, no solo en operación estable. Pregunta por referencias de proyectos parecidos, tiempo medio de go-live, y disponibilidad de su equipo de proyecto.

Exige contractualmente tiempo de respuesta ante incidente durante la fase de estabilización (al menos 30 días post go-live). Una vez estabilizado, vuelve al SLA estándar.

Documentación mínima que no puede faltar

Runbook paso a paso con procedimientos exactos, contactos de emergencia 24/7, matriz de dependencias actualizada, plan de comunicación a usuarios internos, criterios explícitos de rollback, y criterios explícitos de go/no-go en cada paso.

Sin esta documentación firmada por las partes, el proyecto se vuelve una sucesión de decisiones improvisadas bajo presión. La improvisación en migraciones se paga cara.

Fuentes

[1] Uptime Institute — Best Practices for Data Center Migration — https://uptimeinstitute.com/

[2] TIA-942 — Telecommunications Infrastructure Standard for Data Centers — https://tiaonline.org/products/tia-942/

[3] ISO/IEC 22237 — Data centre facilities and infrastructures — https://www.iso.org/standard/63921.html

[4] Gartner — Data Center Migration Best Practices (research) — https://www.gartner.com/en/infrastructure-it-operations