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. Una vez tengas ese inventario, toca comparar AWS, Azure y Google Cloud en coste, integración y soberanía del dato.
- 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, lo más caro) 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.
Una migración bien hecha es aburrida, y la ventana de corte sale bien gracias a las semanas de pruebas anteriores. Cuando alguien te proponga «lo movemos todo el sábado por la noche» como plan completo, desconfía.
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.
El siguiente paso
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.