Migrar a la nube no es pulsar un botón y apagar el servidor del armario. Hecho bien, es un proceso por fases: primero entiendes lo que tienes, luego decides qué mover y cómo, pruebas, cortas con red de seguridad y verificas. Hecho mal, acabas pagando de más, con una aplicación lenta o con un corte de servicio que no habías previsto. Esta guía explica un camino realista para responsables técnicos y gerentes de PYME que quieren delegar infraestructura sin perder el control.
Empieza por la auditoría, no por el proveedor
Antes de mirar precios de ningún proveedor, hay que inventariar lo que se va a mover. Una auditoría seria responde a tres preguntas: qué cargas de trabajo existen, cómo dependen unas de otras y cuántos recursos consumen de verdad, medido durante semanas y no estimado de memoria. Es habitual descubrir servidores sobredimensionados que llevan años funcionando al 10 % de su capacidad, o aplicaciones críticas que dependen de una base de datos que nadie documentó. Esa foto real cambia el proyecto entero: define qué se puede mover tal cual, qué conviene redimensionar y qué es mejor no tocar todavía, y marca la diferencia entre pagar en la nube por lo que consumes y trasladar allí el sobredimensionamiento que ya pagabas en tu CPD. Sin auditoría, el presupuesto del proveedor es una cifra construida sobre los supuestos de otro.
- Inventario de servidores, aplicaciones y bases de datos, con su uso real de CPU, memoria y almacenamiento.
- Mapa de dependencias: qué habla con qué y por qué puerto.
- Requisitos de cumplimiento y ubicación de los datos (RGPD, sector regulado).
- Ventanas de mantenimiento toleradas por el negocio.
Qué migrar primero y qué dejar para el final
No todo se mueve a la vez ni en el mismo orden. La regla práctica es empezar por lo de bajo riesgo y alto aprendizaje: entornos de pruebas, webs estáticas, servicios sin estado o cargas que no dependen de nada más. Eso permite al equipo coger soltura con la plataforma antes de tocar lo crítico. En el extremo contrario quedan las bases de datos con mucha escritura, los sistemas con integraciones profundas y todo lo que exige ventana de corte negociada; se migran al final, cuando el procedimiento está rodado y las sorpresas ya han salido en cargas donde no dolían. Entre medias va el grueso de aplicaciones internas. Cada lote migrado enseña algo del siguiente, y ese aprendizaje acumulado es lo que convierte una migración arriesgada en una serie de pasos aburridos, que es exactamente lo que quieres.
Lo que conviene dejar para más adelante son los sistemas con muchas dependencias, los que manejan datos sensibles y los que tienen licencias atadas a hardware concreto. Y hay cosas que quizá no deban migrarse nunca: equipos al final de su vida útil que es mejor jubilar, o software heredado que sale más barato reemplazar que mover.
Las estrategias de migración, en lenguaje claro
Existen varias formas de migrar cada carga de trabajo, y rara vez se usa una sola para todo. Las cuatro que cubren la práctica totalidad de los casos son rehost o lift-and-shift (mover la máquina tal cual, rápido pero arrastra ineficiencias), replatform (pequeños ajustes al migrar, como pasar la base de datos a un servicio gestionado), refactor (rediseñar la aplicación para aprovechar la nube de verdad, caro pero transformador) y retire (descubrir que algo ya no lo usa nadie y apagarlo, la estrategia más rentable y la más olvidada). La decisión correcta se toma carga a carga con la información de la auditoría; una migración típica de pyme acaba siendo mayoritariamente rehost, con un puñado de replatform y algún refactor solo donde de verdad compensa. Las repasamos una a una:
- Rehost (lift-and-shift): mover la máquina tal cual a la nube. Es lo más rápido y lo menos arriesgado, pero no aprovecha las ventajas de la nube ni reduce coste por sí solo.
- Replatform: mover haciendo pequeños ajustes, como pasar la base de datos a un servicio gestionado. Algo más de esfuerzo, bastante más beneficio en mantenimiento.
- Refactor: rediseñar la aplicación para que sea nativa de la nube. Es lo más costoso y solo merece la pena cuando la aplicación es estratégica y va a seguir creciendo.
- Retire / retain: apagar lo que ya no se usa y dejar en local lo que de momento no tiene sentido mover.
Para la mayoría de PYMEs lo sensato es una mezcla: rehost para ganar terreno rápido y replatform donde el ahorro y la fiabilidad lo justifiquen. La elección de la estrategia y el dimensionamiento de recursos es justo donde un partner con experiencia en migración y gestión de Cloud y AWS evita sustos caros.
Pruebas, ventana de corte y verificación
Una migración no termina cuando los datos están copiados, sino cuando has comprobado que todo funciona igual o mejor que antes. Lo correcto es levantar el entorno nuevo en paralelo, probarlo con datos reales y medir rendimiento antes de cambiar nada de cara al usuario.
La ventana de corte (el momento en que el tráfico pasa del sistema antiguo al nuevo) se planifica para el horario de menor actividad, con un plan de marcha atrás escrito de antemano. Si algo no cuadra en la verificación posterior, debe ser posible volver al sistema original sin drama. Verificar incluye comprobar rendimiento, integridad de los datos, copias de seguridad funcionando y monitorización activa desde el primer minuto.
Los errores típicos que salen caros
- Migrar sin dimensionar: replicar en la nube el tamaño de los servidores físicos sin medir el uso real lleva a pagar de más cada mes, indefinidamente.
- No prever el coste de salida: sacar datos de la nube (egreso) tiene precio. Si no se contempla, una futura migración o copia masiva se convierte en una factura sorpresa.
- Hacerlo todo de golpe: el «big bang» maximiza el riesgo. Por fases se aprende y se corrige sobre la marcha.
- Olvidar las copias de seguridad y la monitorización: estar en la nube no es un backup. Hay que configurarlas explícitamente.
Cómo se ve una migración sin parada en la práctica
Un ejemplo real de nuestro trabajo reciente (anonimizado): la migración del motor de un clúster de bases de datos en producción sin parar el servicio. En lugar de un gran corte, los nodos con el motor nuevo se incorporaron al clúster existente uno a uno, verificando la réplica en cada paso, durante semanas y coordinado con otra migración que corría en paralelo. El usuario final no vio nada.
Esa es la idea que intentamos transmitir en todo este artículo: una migración bien hecha es aburrida. La ventana de corte no se gana la noche del corte, se gana en las semanas de pruebas anteriores. Cuando alguien te proponga «lo movemos todo el sábado por la noche» como plan completo, desconfía.
Y el destino importa tanto como el viaje: en nuestro caso de migración con escalado automático, el resultado fue un 30% menos de coste de infraestructura y capacidad para absorber el triple de tráfico escalando en segundos.
Preguntas frecuentes
¿Cuánto tiempo tarda migrar a la nube?
Depende del tamaño y la complejidad. Una web o un servicio aislado puede moverse en días; un parque con dependencias y datos críticos se hace por fases a lo largo de semanas o meses. La auditoría inicial es lo que permite dar un plazo realista en lugar de una promesa.
¿Migrar a la nube siempre sale más barato?
No automáticamente. La nube ahorra cuando se dimensiona bien y se aprovechan servicios gestionados; si se replica el sobredimensionamiento del local, puede salir más cara. El ahorro real viene de pagar por lo que se usa, no de migrar por migrar.
¿Habrá cortes de servicio durante la migración?
Con un enfoque por fases y entornos en paralelo, el corte se reduce a una ventana breve y planificada, normalmente en horario de baja actividad. Con un plan de marcha atrás preparado, el riesgo de una caída prolongada se minimiza.
¿Necesito un equipo interno para mantenerlo después?
No es imprescindible. Muchas PYMEs prefieren delegar la gestión continua (monitorización, copias, optimización de coste, seguridad) en un proveedor gestionado y centrar a su equipo en el negocio. La migración es solo el principio; lo que marca la diferencia es la operación del día a día.
El siguiente paso
Migrar bien es planificar por fases, medir antes de mover y tener siempre forma de volver atrás. Si te estás planteando dar el salto y quieres un diagnóstico honesto de tu situación antes de mover nada, cuéntanos tu caso y te ayudamos a trazar un plan por fases sin sorpresas.
¿Tu movimiento no es al cloud sino dentro del CPD? Si vienes de VMware, tienes la guía completa en migrar de VMware a Proxmox.