"Migrar todo a la nube" se volvió un disco rayado en muchas reuniones de directorio: alguien escuchó que "todo el mundo ya lo hizo", encargó el proyecto completo de una vez, y un año después la factura de la nube cuesta más que el servidor que reemplazó. La respuesta opuesta también es común: la empresa se paraliza, decide no tocar nada, y el sistema más importante sigue corriendo en una máquina que ya nadie sabe reparar.
Las dos respuestas parten del mismo error: tratar la decisión como una elección única, para toda la empresa. Una encuesta de 2023 del Cetic.br con empresas brasileñas ya mostraba que no es así como ocurre la decisión en la práctica: el 53% de las empresas pagaba por correo en la nube, un servicio sencillo de cambiar; solo el 33% pagaba por capacidad de procesamiento en la nube, y apenas el 24% por una plataforma para alojar sistemas propios en desarrollo. Esa distancia entre los números no es atraso — es selección. Cada empresa ya decide, sistema por sistema, qué vale la pena mover.
Quien decide no es solo quien firma el contrato de TI. Es el dueño o director que aprueba la inversión, y es el responsable de TI que va a sostener la decisión después. Para los dos, la pregunta correcta nunca es "vamos a la nube o no" — es "este sistema específico gana, pierde, o solo funciona si se rehace antes de subir".
Lo que cambia de un sistema a otro
La misma encuesta del Cetic.br muestra la diferencia por sector de actividad: entre las empresas de información y comunicación, el 57% ya pagaba por capacidad de procesamiento en la nube en 2023; en el sector de alojamiento y alimentación, la proporción era del 23%, y en la industria, del 27%. No es que un sector "entienda más" de tecnología — es que los sistemas que usa cada uno tienen perfiles distintos de dependencia, actualización e importancia para la operación.
Un sistema gana en la nube cuando el uso varía a lo largo del mes (un pico de ventas a fin de año, una nómina procesada una vez por período), cuando personas en distintas ubicaciones necesitan acceder al mismo sistema, o cuando el fabricante ya entrega la versión en la nube como estándar — el correo y las herramientas de oficina son el ejemplo más simple. También ayuda cuando el proveedor de nube tiene centro de datos en Brasil: Azure, de Microsoft, mantiene una región en São Paulo, lo que acerca el sistema a quien lo usa desde aquí.
Un sistema funciona mejor dentro de la empresa cuando se comunica en tiempo real con un equipo físico local — una máquina de producción, una balanza, un torniquete —, cuando la conexión hasta el proveedor de nube es lenta o inestable, o cuando el costo mensual de operarlo fuera supera el costo de mantenerlo dentro. Ese cálculo hay que hacerlo, no suponerlo.
Y existe un tercer grupo, el más fácil de ignorar: sistemas que solo suben después de actualizarse o reescribirse. La documentación de migración de Microsoft para Azure trata la evaluación de compatibilidad — versión del sistema, de la base de datos, de las bibliotecas usadas — como un paso anterior a cualquier decisión de mover, y recomienda cambiar la estructura de un sistema solo cuando existe una razón de negocio clara, porque ese cambio exige un esfuerzo de desarrollo y prueba considerable. Un sistema que el propio fabricante ya dejó de actualizar no es candidato a "subir tal cual": necesita antes un paso de corrección.
Por qué decidir todo de una vez no resuelve
La forma común de tratar esta decisión es elegir un lado y aplicarlo a todo. Por un lado, la empresa contrata la migración completa porque escuchó que reduce costos — y descubre, meses después, que el sistema que corría sin costo variable en la sala de servidores ahora genera una factura que sube con el uso, sin que nadie haya calculado antes cuánto costaría eso al volumen real de la empresa.
Por el otro lado, la empresa que se resiste a cualquier cambio mantiene un sistema antiguo corriendo en una máquina física cada vez más difícil de reemplazar, repitiendo que "el fabricante dijo que no funciona en la nube" — sin comprobar si esa frase, escuchada hace algunos años, sigue siendo cierta hoy.
Las dos posturas comparten el mismo punto ciego: ninguna hizo el relevamiento sistema por sistema. La pregunta "qué cambia para la empresa" — en tiempo de acceso, en dependencia de una persona específica, en capacidad de recuperarse después de una falla — nunca llegó a hacerse para cada sistema en particular.
El tamaño del problema de decidir mal aparece en números de infraestructura más amplios. En el relevamiento más reciente del Uptime Institute sobre interrupciones de centros de datos, publicado en mayo de 2026, el 57% de las empresas afectadas por una interrupción reportó pérdidas superiores a US$ 100 mil, y una de cada cinco (20%) reportó pérdidas superiores a US$ 1 millón. El dato no es específico de la nube — es sobre el costo de una decisión de infraestructura mal dimensionada, esté dentro o fuera de la empresa.
Lo que tiene que existir en la práctica
Un inventario de lo que tiene la empresa, sistema por sistema. Sin saber qué existe — versión, fabricante, quién depende de quién —, cualquier decisión de mover es una apuesta a ciegas. Es el primer paso antes de cualquier propuesta de nube.
Un criterio técnico por sistema, no solo un criterio financiero. Latencia hasta el usuario, dependencia de un equipo físico local, si el fabricante sostiene una versión en la nube — cada respuesta cambia el resultado para ese sistema específico.
Migración por etapas, empezando por lo más simple. Sistemas de prueba y de uso interno primero; el sistema que sostiene la operación principal, solo después de que el proceso ya se validó en algo menos crítico.
Estimación del costo mensual antes de mover, no después. Lo que un sistema cuesta hoy, quieto en una sala, hay que compararlo con lo que va a costar corriendo por uso — sin eso, el ahorro que promete la nube es solo una suposición.
Un plan para lo que todavía no sube. Un sistema sin versión en la nube sostenida por el fabricante entra en una lista con plazo — actualizar, reemplazar o reescribir —, en vez de quedar olvidado hasta que se rompa.
Un único responsable siguiendo toda la decisión. Sin alguien dueño del resultado, cada sistema se decide de forma aislada por quien compró ese proyecto en su momento, y nadie vuelve a revisar la elección después.
Así es como trabaja Skills IT: con el relevamiento de cada sistema antes de cualquier propuesta, el criterio técnico por carga de trabajo y la estimación de costo mensual presentada antes de cualquier cambio.
La ganancia de decidir sistema por sistema
La ganancia no es "ahorrar con la nube" ni "mantener todo como está" — las dos son efectos posibles, no el objetivo. La ganancia real es que cada sistema queda en el lugar que mejor sostiene el negocio: lo que necesita acceso desde cualquier lugar tiene acceso desde cualquier lugar; lo que necesita respuesta inmediata sigue cerca de donde se usa; y lo que necesita una reforma tiene una reforma agendada, en vez de convertirse en un problema descubierto el día que se rompe.
El efecto financiero aparece en la previsibilidad: sin migrar por moda ni frenar por miedo, el costo mensual de cada sistema es una cuenta conocida, calculada antes — no una sorpresa después. El efecto operativo aparece en el momento de la falla: cuando el relevamiento ya existe, el equipo sabe exactamente qué revisar en vez de reconstruir el mapa desde cero bajo presión.
Todavía hay una ganancia para quien decide el presupuesto: una propuesta de nube que llega sin ese relevamiento es una propuesta a medias. El director que pide "muéstrame sistema por sistema, qué cambia y cuánto cuesta" está pidiendo exactamente lo que debería haberse hecho antes de firmar cualquier contrato. Por eso, en Skills IT, la primera entrega de un proyecto de nube es ese relevamiento — no la cotización de precio.
Una hoja de ruta para empezar
- Liste todos los sistemas que sostienen la operación, con fabricante y versión. Sin esa lista, la siguiente decisión no tiene base.
- Marque, junto a cada uno, si depende de otro sistema o de un equipo físico local. Eso es lo que decide si puede moverse solo o solo en grupo.
- Pregúntele al fabricante, por escrito, si existe una versión en la nube sostenida — y desde cuándo. "No funciona en la nube", escuchado hace tres años, puede que ya no sea cierto.
- Calcule el costo mensual proyectado de cada sistema fuera de la empresa, antes de decidir. Compárelo con el costo de mantenerlo dentro, incluyendo el mantenimiento del equipo actual.
- Empiece la migración por un sistema de bajo riesgo, no por el más importante. Lo que se aprende con el primer sistema abarata y reduce el riesgo de los siguientes.
- Defina qué se queda afuera por ahora — y por cuánto tiempo. Un sistema que no sube hoy necesita una fecha de revisión, no un "nunca más se habla de esto".
