Por qué muchas empresas están volviendo del cloud al servidor propio (y qué dice eso de cómo llegaron)

El ciclo que los profesionales de IT conocen bien

Hace unos años, la recomendación casi universal era migrar al cloud. Escalabilidad infinita, sin hardware que mantener, paga solo lo que consumes. El mensaje era tan limpio que muchas empresas lo compraron sin hacer demasiadas preguntas. Ahora, algunos de esos mismos equipos están deshaciendo parte de ese camino.

No es una tendencia masiva, pero sí un patrón que los consultores de infraestructura ven con regularidad: empresas que, después de varios años en la nube, deciden mover cargas de trabajo críticas de vuelta a servidores propios. Y casi siempre por la misma razón: los números no cuadran.

Lo interesante no es el movimiento en sí, sino lo que revela sobre cómo se tomó la decisión original.

El problema no es el cloud. Es la arquitectura que nadie diseñó

Cuando una empresa acaba pagando el doble de lo previsto por su infraestructura cloud, la culpa rara vez es del proveedor. La causa más frecuente es que nadie dimensionó correctamente el coste real desde el principio.

Hay una parte de ese coste que los presupuestos iniciales casi nunca incluyen: las tarifas de extracción de datos, conocidas en inglés como data transfer fees o egress fees. Mover datos dentro del cloud es barato o gratuito. Sacarlos, ya sea para enviarlos a otro proveedor, a una sede, o simplemente para hacer una copia de seguridad local, puede disparar la factura de forma considerable.

Algunos profesionales lo describen con una metáfora bastante precisa: entrar es sencillo, salir es caro por diseño. No es un accidente. Los proveedores de cloud tienen un incentivo estructural para que tus datos permanezcan dentro de su plataforma. Las empresas que no planificaron esto desde el inicio se encuentran, meses o años después, con que migrar a otro entorno cuesta más de lo que esperaban gastarse en toda la infraestructura.

Esto no significa que el cloud sea una trampa. Significa que hay que leer la letra pequeña antes de firmar, y calcular el coste de salida igual que calculas el de entrada.

¿Estás realmente en el cloud?

Hay otra confusión que aparece con frecuencia y que complica todavía más el diagnóstico. Muchas empresas creen que están en el cloud porque usan correo electrónico y videoconferencias a través de una plataforma de suscripción. Y técnicamente no están equivocadas: esos servicios son cloud. Pero al mismo tiempo, siguen teniendo un servidor físico en el armario del pasillo, una base de datos corriendo en local, y una unidad de archivos que solo funciona cuando estás en la oficina.

Eso no es una arquitectura cloud. Es una mezcla de capas que fue creciendo sin un plan claro, y que a menudo cuesta más que cualquiera de las dos opciones puras porque combina las complejidades de ambas.

El punto de partida para tomar cualquier decisión sensata sobre infraestructura es tener claridad sobre qué componentes están realmente en la nube, cuáles siguen siendo locales, y por qué. Sin ese mapa, es imposible calcular costes reales ni comparar alternativas.

SharePoint no es un servidor de archivos

Un ejemplo concreto de arquitectura mal planificada es el uso de herramientas de colaboración genéricas para casos de uso que requieren soluciones específicas. Plataformas diseñadas para compartir documentos y gestionar proyectos no están pensadas para actuar como repositorios de archivos de alto volumen o con requisitos de acceso muy específicos.

Cuando una empresa fuerza ese uso, los problemas de rendimiento, los límites de almacenamiento y las dificultades de integración con otros sistemas aparecen tarde o temprano. La solución no es abandonar el cloud: es usar la herramienta adecuada para cada función, ya sea una solución de almacenamiento en red dentro del entorno del proveedor o una plataforma especializada en gestión de archivos corporativos.

La moraleja es que una migración al cloud no es trasladar lo que tienes a otro sitio. Es rediseñar cómo funciona tu infraestructura. Si no se hace ese trabajo, los problemas que tenías antes aparecen en otro formato y con otro precio.

El coste real: cómo calcularlo antes de decidir

Para evaluar honestamente si el cloud, on-premise o un modelo híbrido es la opción correcta, hay que poner sobre la mesa todos los componentes del coste, no solo los más visibles.

• Licencias y suscripciones mensuales: el coste más evidente, pero no el único.
• Transferencia de datos: cuántos datos mueves fuera del entorno cloud cada mes, y a qué precio por gigabyte según tu contrato.
• Mantenimiento on-premise: si mantienes hardware local, incluye amortización del equipo, consumo eléctrico, refrigeración y tiempo de administración.
• Coste de rediseño: migrar mal y luego corregir es más caro que diseñar bien desde el principio. Este coste suele ignorarse hasta que aparece.
• Dependencia de proveedor: valora cuánto te costaría cambiar de proveedor o recuperar tus datos si decidieras hacerlo en el futuro.

Una empresa que hizo la transición al cloud principalmente orientada al ahorro, y que luego tuvo que revertir parte de esa decisión, suele encontrarse con que el coste de la marcha atrás supera con creces lo que habría costado planificar bien desde el inicio. Este patrón se repite con suficiente frecuencia como para tomárselo en serio.

Cómo protegerte del lock-in antes de firmar

Una vez que tus datos están en una plataforma, el proveedor tiene una posición de ventaja. No por mala fe necesariamente, sino por la lógica económica del modelo. Por eso, las condiciones del contrato importan tanto como el precio mensual.

Algunos aspectos que conviene revisar antes de comprometerse con cualquier proveedor de cloud:

• Política de egreso de datos: qué cuesta extraer tus datos, en qué formatos y con qué plazos. Si no está claro en el contrato, pídelo por escrito.
• Portabilidad: en qué formatos se exportan los datos y si son compatibles con otras plataformas o con infraestructura propia.
• Localización de datos: dónde se almacenan físicamente tus datos, especialmente relevante cuando se manejan datos de clientes o información sensible. El RGPD establece obligaciones concretas sobre transferencias internacionales y contratos de procesamiento que deben estar cubiertos explícitamente.
• SLA y soporte: qué nivel de servicio garantiza el proveedor y qué compensaciones existen si no se cumple.

No se trata de desconfiar de los proveedores, sino de entender que sus intereses y los tuyos no siempre coinciden perfectamente. Leer el contrato con atención es parte del trabajo.

Las alternativas que pocas veces se consideran

La conversación sobre infraestructura tiende a plantearse en términos binarios: cloud o servidor propio. Pero hay opciones intermedias que en muchos casos ofrecen mejor equilibrio entre coste, control y complejidad.

Cloud híbrido bien diseñado: no mezclar capas por acumulación histórica, sino definir conscientemente qué cargas van al cloud público, cuáles se mantienen en local y cómo se comunican entre sí. Requiere trabajo inicial, pero el coste operativo suele ser más predecible.

Colocation: tu hardware, en un centro de datos con conectividad, refrigeración y seguridad física profesionales. Pagas por espacio y ancho de banda, pero el equipo es tuyo. Elimina la gestión física sin el lock-in de los grandes proveedores cloud.

Edge computing: procesar los datos cerca de donde se generan, reduciendo la dependencia de la conectividad y el coste de transferencia. Relevante si trabajas con grandes volúmenes de datos o si tienes requisitos de latencia bajos.

Ninguna de estas opciones es universalmente mejor. La correcta depende del volumen de datos, el presupuesto, los requisitos de disponibilidad y el perfil de tu equipo técnico.

Los ciclos existen, pero no tienes que repetirlos

Hay una observación que circula entre profesionales de IT con cierta ironía: estas decisiones son cíclicas. Durante unos años, la industria se entusiasma con el cloud. Luego vienen las facturas reales, las migraciones inversas y el redescubrimiento de las virtudes del hardware propio. Y en unos años más, el ciclo vuelve a empezar con nuevas promesas.

El humor es comprensible, pero la conclusión práctica no debería ser el cinismo. Debería ser que las decisiones de infraestructura tomadas sin análisis real tienen un coste concreto, y ese coste lo acaba pagando la empresa.

Lo que diferencia a las organizaciones que navegan bien estos ciclos de las que los sufren no es haber acertado con la tecnología del momento. Es haber construido una arquitectura con criterios claros: coste total calculado con egreso incluido, dependencia de proveedor evaluada, y capacidad de cambiar de dirección sin que eso suponga una crisis.

Qué hacer si reconoces este patrón en tu empresa

Si al leer esto has identificado que tu infraestructura actual es esa mezcla incómoda de herramientas cloud, servidores locales y soluciones que nadie diseñó del todo, el primer paso no es migrar nada. Es auditar lo que tienes.

• Mapea todos los componentes de tu infraestructura: qué es cloud, qué es local, qué es una zona gris.
• Calcula el coste real de cada capa, incluyendo transferencia de datos, licencias, mantenimiento y tiempo de gestión interna.
• Identifica cuáles de esos componentes tienen alternativas más eficientes para tu caso concreto.
• Revisa los contratos con tus proveedores actuales: política de egreso, portabilidad de datos, condiciones de cancelación.

Con ese diagnóstico sobre la mesa, la decisión entre cloud, on-premise o híbrido deja de ser una cuestión de moda tecnológica y se convierte en un cálculo con números reales.

La pregunta que vale la pena hacerse no es si el cloud es mejor o peor que tener un servidor. Es si la arquitectura que tienes ahora mismo está tomada con criterio, o fue creciendo sin que nadie la diseñara del todo.