La calculadora del proveedor estima cuánto cuesta vivir en la nube, no cuánto cuesta llegar. Las partidas que un presupuesto serio no omite.
Casi todos los presupuestos de migración a la nube empiezan en la calculadora del proveedor: se cargan los servidores actuales, se eligen instancias parecidas y sale una cifra mensual. Esa cifra suele estar razonablemente bien. Lo que falla es todo lo demás, porque la calculadora estima cuánto cuesta operar en la nube, no cuánto cuesta llegar.
Este artículo no te va a dar un precio, porque no existe un precio de catálogo para mover una operación que no conocemos. Te va a dar la lista de partidas que un presupuesto serio tiene que incluir y las preguntas que conviene hacerle a cualquier proveedor que te cotice una migración.
¿De qué depende el costo de migrar a la nube?
Más que de la cantidad de servidores, depende de cuatro variables:
- Cuántas aplicaciones hay y cuánto se conocen. Una aplicación documentada y con su equipo disponible se migra en una fracción del tiempo que una heredada de un proveedor que ya no existe.
- Qué estrategia se elige para cada una: moverla tal cual, adaptarla o reconstruirla.
- Cuántas dependencias tiene con sistemas que no se van a mover: el ERP en el servidor de la oficina, la integración con el banco, el reloj control de una sucursal.
- Cuánta interrupción tolera el negocio durante el cambio. No es lo mismo un corte de domingo que una migración sin ventana de mantención.
La primera de esas variables es la que más sorprende. En casi cualquier operación con algunos años hay servidores que nadie sabe para qué existen, tareas programadas que alguien configuró y olvidó, y aplicaciones que dependen de una carpeta compartida que no aparece en ningún diagrama. Cada una de esas sorpresas, descubierta durante el corte y no antes, es una noche larga y una partida que no estaba presupuestada.
Las partidas que un presupuesto serio tiene que incluir
- Inventario y diagnóstico: qué hay, qué depende de qué y qué se puede apagar. Es la fase que más se recorta y la que más caro sale saltarse.
- Diseño de la arquitectura destino: redes, identidades, cuentas, respaldos y seguridad, antes de mover el primer servidor.
- La migración misma, aplicación por aplicación, cada una con su estrategia.
- Pruebas: funcionales, de rendimiento y del plan de reversa.
- Operación en paralelo: durante semanas o meses pagas los dos ambientes, el viejo y el nuevo. Pocas cotizaciones lo dicen en voz alta.
- Transferencia de datos: la carga inicial y, ojo, el tráfico de salida posterior, que los proveedores cloud cobran aparte.
- Licencias: no todas las licencias de tus servidores se pueden llevar a la nube en las mismas condiciones. Revisa cada contrato antes de asumirlo.
- Capacitación del equipo que va a operar el ambiente nuevo.
No todas estas partidas pesan lo mismo en cada caso, pero todas tienen que aparecer, aunque sea con valor cero y una explicación. Una cotización que omite la operación en paralelo o las licencias no es más barata: solo traslada ese costo a una conversación incómoda unos meses después.
La calculadora del proveedor te dice cuánto cuesta vivir en la nube. Nadie te cotiza la mudanza.
Rehost, replatform o refactor: la decisión que más mueve el presupuesto
Para cada aplicación hay tres caminos, y el presupuesto total depende sobre todo de cómo se repartan:
- Rehost, o moverla tal cual: la aplicación pasa a una máquina virtual en la nube sin cambios. Es lo más rápido y barato de migrar, y suele ser lo más caro de operar, porque no aprovecha nada de lo que la nube hace bien.
- Replatform, o adaptarla: cambios acotados para usar servicios administrados, como pasar la base de datos a un servicio gestionado. Equilibra esfuerzo y beneficio.
- Refactor, o reconstruirla: rediseñarla para la nube. Es lo que más cuesta y solo se justifica en las aplicaciones que el negocio va a seguir evolucionando.
Un error frecuente es aplicar la misma estrategia a todo el inventario. Lo razonable suele ser mover casi todo tal cual primero, para salir del data center, y reservar el refactor para las pocas aplicaciones que de verdad lo pagan.
También conviene decidir el orden. Empezar por una aplicación de bajo riesgo pero representativa permite probar la arquitectura, las herramientas y el procedimiento de corte con algo que, si falla, no detiene el negocio. Lo crítico va después, cuando el equipo ya hizo el recorrido completo al menos una vez.
Los costos que aparecen después del corte
Una migración bien presupuestada puede igual terminar con una factura mensual que sorprende. Las causas se repiten:
- Servidores dimensionados como estaban en el data center, que en la nube se pagan por hora aunque estén ociosos.
- Ambientes de prueba y desarrollo encendidos las 24 horas.
- Respaldos y snapshots que se acumulan sin política de retención.
- Tráfico de salida que nadie midió antes de migrar.
- Nadie a cargo de revisar la factura cada mes.
Por eso el presupuesto tiene que incluir, además de la migración, una práctica de control de costos desde el primer mes: etiquetas por proyecto, alertas de gasto y una revisión mensual con alguien que tenga autoridad para apagar cosas.
Ninguna de estas causas es un problema técnico difícil. Son problemas de responsabilidad: la nube cobra por lo que está encendido, y en un data center propio nadie tenía el hábito de apagar cosas porque el servidor ya estaba pagado. Ese cambio de hábito es parte de la migración tanto como mover los datos.
Datos personales en la nube: qué cambia con la Ley 21.719
Si tus sistemas tratan datos de clientes, trabajadores o pacientes, hay una variable más. La Ley 21.719, que moderniza la protección de datos personales en Chile, se publicó en diciembre de 2024 y entra en plena vigencia el 1 de diciembre de 2026. Crea una Agencia de Protección de Datos Personales con facultades para fiscalizar y sancionar, y regula, entre otras materias, las transferencias internacionales de datos y los deberes de seguridad.
Para una migración, eso se traduce en preguntas que conviene responder en el diseño y no después: en qué país quedan físicamente los datos, qué garantías ofrece el proveedor cloud para esa transferencia, quién tiene acceso y cómo queda registrado, y qué pasa si hay una filtración.
No es un motivo para no migrar. Bien hecha, una migración puede dejar los datos mejor protegidos que en un servidor en la oficina. Pero sí es un motivo para que la seguridad y el cumplimiento estén en el presupuesto desde la primera versión.
Qué pedirle a quien te cotiza una migración
- Que el diagnóstico venga antes del precio total, o que el precio total venga como rango con sus supuestos escritos.
- Que cada aplicación tenga su estrategia declarada: tal cual, adaptada o reconstruida.
- Que el costo de operar en paralelo aparezca como partida propia.
- Que haya un plan de reversa probado para cada corte, no solo escrito.
- Que la estimación del costo mensual en la nube incluya el tráfico de salida y los respaldos.
- Que esté claro quién opera el ambiente nuevo al día siguiente del corte.
Y una pregunta más, sobre el plazo: ¿cómo se reparte la migración en el tiempo? Una migración por oleadas, con cortes pequeños y frecuentes, cuesta algo más en coordinación, pero cada oleada deja aprendizajes que abaratan la siguiente y reduce el tamaño de lo que puede salir mal en un solo fin de semana.
Si una cotización no responde estas preguntas, no significa que el proveedor sea malo, pero sí que el riesgo de las partidas que faltan queda de tu lado.
Si estás evaluando migrar, empieza por un diagnóstico de 45 minutos sin costo: dos ingenieros senior revisan contigo tu inventario y te dicen qué partidas van a mover tu presupuesto. En implementación y migración está cómo planificamos las migraciones, con plan de reversa incluido, y en cloud y DevOps cómo operamos y optimizamos el ambiente una vez que estás arriba.