Migrar servidores locales a la nube: cuándo conviene y cómo se hace
La pregunta rara vez llega como "queremos migrar a la nube". Llega como un servidor que ya tiene ocho años, una sala de servidores que se calienta demasiado, una cotización de renovación de hardware que asusta, o un ERP al que hay que acceder desde tres ciudades distintas.
Migrar puede resolver todo eso. También puede salir más caro que quedarse, si se hace sin evaluar. Esta guía explica cómo distinguir un caso del otro.
Cuándo conviene migrar
- El hardware está al final de su vida útil y la renovación implica una inversión grande de una sola vez.
- Hay usuarios distribuidos en varias ubicaciones o trabajando de forma remota habitual.
- La continuidad depende de un solo equipo físico sin redundancia ni plan de recuperación.
- La demanda es variable y hoy se paga capacidad ociosa todo el año.
- No hay quien administre el equipamiento físico de forma consistente.
Cuándo no conviene, o conviene solo en parte
Hay casos donde migrar todo es la decisión equivocada, y conviene un esquema híbrido o quedarse donde se está:
- Aplicaciones antiguas que el proveedor no soporta fuera de un servidor local, o que dependen de licencias atadas al hardware.
- Sistemas que mueven volúmenes grandes de datos contra equipos en planta, donde la latencia y el costo de transferencia pesan.
- Faenas o sucursales con conectividad inestable, donde depender de internet para operar es un riesgo mayor que el que se quiere resolver.
- Hardware recién renovado, todavía en garantía y correctamente dimensionado.
El modelo híbrido —parte en la nube, parte local— es una respuesta legítima y frecuente, no un paso intermedio a medias.
Qué hay que evaluar antes de mover nada
- Inventario real. Qué servidores hay, qué corre en cada uno y quién lo usa. Casi siempre aparecen servicios que nadie recordaba.
- Dependencias. Qué aplicación habla con cuál, qué integraciones existen y qué se rompe si algo cambia de dirección IP o de nombre.
- Licenciamiento. Qué licencias se pueden trasladar y cuáles hay que comprar de nuevo. Es la fuente más común de sorpresas de costo.
- Conectividad. Ancho de banda, estabilidad y qué pasa con la operación si el enlace se cae.
- Identidad y accesos. Cómo se autentican hoy los usuarios y cómo lo harán después.
- Respaldo y vuelta atrás. Cómo se respalda en el destino y qué se hace si la migración falla a mitad de camino.
- Costo mensual proyectado. La nube cambia una inversión puntual por un gasto recurrente. Hay que saber cuál será antes de firmar.
Errores que encarecen una migración
- Mover los servidores tal cual, con el mismo dimensionamiento sobredimensionado que tenían en local, y pagar por eso todos los meses.
- Migrar todo en un solo fin de semana, sin una etapa de prueba ni una ruta de reversa.
- Asumir que el proveedor de nube respalda tus datos. La responsabilidad del respaldo sigue siendo de la empresa.
- Dejar el servidor antiguo encendido "por si acaso" durante meses, pagando dos infraestructuras a la vez.
- No documentar la nueva configuración, y quedar dependiendo de quien hizo la migración.
Cómo trabajamos esto en Mater TI
Partimos por el levantamiento: qué hay, qué depende de qué, y qué justifica moverse. De ahí sale una recomendación que puede perfectamente ser migrar solo una parte, o no migrar todavía.
Cuando la migración procede, trabajamos por etapas, con respaldo previo y una ruta de vuelta atrás definida antes de empezar. Al terminar dejamos la administración de identidades, los accesos remotos, el respaldo y la documentación en orden, para que la empresa no quede dependiendo de una sola persona que sabe cómo funciona.
Somos Microsoft Solutions Partner y Google Cloud Partner, y trabajamos tanto entornos en la nube como esquemas híbridos con infraestructura local.