Migrar a la nube: qué decidir antes de mover el primer servidor

Una migración a la nube se encarece cuando se plantea como un traslado de servidores. Las decisiones que fijan la factura y el riesgo se toman antes de mover nada: qué cargas existen, cuál conviene rehacer, cuál basta con apagar. Este es el orden que seguimos con empresas medianas que salen de un centro de datos propio o de un proveedor de hosting.

El inventario decide más que el proveedor

No se puede migrar lo que no se conoce. El primer entregable de cualquier migración es una lista de cargas de trabajo con cinco datos por cada una: qué hace y quién la usa, de qué depende (bases de datos, ficheros compartidos, integraciones con el ERP), qué disponibilidad necesita, qué sensibilidad tienen sus datos y cuánto cuesta hoy entre hardware, licencias y horas de mantenimiento.

Con esa lista, cada carga recibe una de seis decisiones.

En la práctica, el ejercicio suele descubrir cargas que nadie usa desde hace meses y que se apagan antes de empezar. Es el ahorro más barato de toda la migración.

La factura sube cuando se copian los servidores tal cual

Copiar cada máquina virtual del centro de datos a una máquina virtual en la nube es el camino más rápido y el más caro a los seis meses. Las máquinas llegan con el tamaño que tenían, dimensionadas para un pico que ocurre dos veces al año. En la nube, ese tamaño se paga por hora.

Lo que cambia la factura es aprovechar lo que ya viene gestionado. Una base de datos en Azure SQL o Amazon RDS elimina el servidor que había que parchear y del que había que hacer copias a mano. Un proceso nocturno arranca en una función de Azure Functions o AWS Lambda, ejecuta su script en Python y se apaga, sin máquina encendida el resto del día. Y una aplicación empaquetada en Docker se despliega igual en un servidor pequeño que en un servicio de contenedores, sin depender de cómo esté configurada la máquina.

El proceso de carga del almacén de datos de Grupo Pomona Iberia tiene esa forma: un ETL en Python que se ejecuta cada madrugada, lee Excel, carpetas de SharePoint y los ERPs de cuatro empresas, y deja los datos listos en Power BI antes de que llegue la dirección. Ese trabajo dura minutos al día. Es el tipo de carga que conviene ejecutar como tarea programada y no como servidor permanente.

Los cimientos van antes que la primera carga

Antes de migrar nada hay que montar la red, la identidad y las copias. Parece burocracia y es lo que evita que el primer traslado acabe en incidente.

Red: una red virtual con subredes separadas para lo que se expone a internet y lo que no, y una VPN entre la nube y las oficinas para todo lo que sigue en local. En Pomona, la conexión permanente con los ERPs se resolvió con una VPN y acceso directo por SQL, y ese es el mismo tipo de enlace que una migración necesita para mover datos sin cortar el servicio.

Identidad y accesos: quién puede crear recursos y quién puede ver datos, con autenticación en dos pasos y permisos por grupo en lugar de por persona. Cifrado en reposo y en tránsito activado por defecto. Copias de seguridad automáticas, con una restauración de prueba hecha antes de migrar la primera base de datos.

Coste: etiquetas en cada recurso (proyecto, entorno, responsable) y alertas de presupuesto desde el primer día. Sin etiquetas, la factura de la nube es un número único que nadie puede explicar a final de mes.

Un piloto de bajo riesgo enseña más que el plan

La primera carga que se mueve debería ser visible y poco crítica: una herramienta interna, la web corporativa, un entorno de pruebas. Si algo falla, nadie deja de facturar. Si sale bien, el equipo ha aprendido el procedimiento con una carga que perdona errores.

A partir del piloto, el resto se mueve por oleadas ordenadas por riesgo. Para cada carga el guion es el mismo: preparar el entorno, migrar los datos (casi siempre la parte lenta), desplegar, probar, redirigir el tráfico, vigilar una o dos semanas y apagar el entorno antiguo. Conviene presupuestar que durante ese periodo se pagan los dos entornos a la vez. Es el coste de migrar sin cortes.

Apagar lo antiguo es el paso que más se retrasa. Mientras el servidor viejo siga encendido por si acaso, la migración no ha terminado y se paga doble.

Azure o AWS: la respuesta está en lo que la empresa ya usa

Para una empresa que trabaja con Microsoft 365, Business Central y Power BI, Azure es la opción natural. La identidad ya está en Entra ID, y los servicios de datos y de IA se integran con lo que el equipo ya conoce. Para una empresa cuyo producto es software propio, con contenedores y servicios expuestos a clientes, AWS es una base igual de sólida y en la que también construimos.

Lo que conviene evitar es repartir cargas entre dos proveedores sin una razón concreta. Cada nube exige su propia red, su identidad y su monitorización, y mantener dos duplica el trabajo de operación. Multi-nube tiene sentido por exigencia normativa o por un servicio concreto que solo existe en uno de ellos. En el resto de casos es complejidad sin retorno.

Por dónde empezar esta semana

• Listar las diez cargas de trabajo más importantes con dependencias, sensibilidad de datos y coste mensual actual.
• Marcar las que nadie usa y apagarlas antes de contratar nada.
• Elegir un piloto visible y poco crítico, y fijar con qué se medirá su éxito.
• Activar etiquetas de coste y alertas de presupuesto en la cuenta de nube desde el primer recurso.
• Hacer una restauración de prueba de las copias actuales; si falla en local, fallará en la nube.

Si el caso encaja, en LakeTab lo revisamos en una primera llamada de 60 minutos.