«Migramos a la nube» se ha convertido en una frase tan frecuente en los comités de dirección como vaga en su contenido. Una pyme de 40 empleados que mueve su servidor de ficheros a OneDrive no ha hecho lo mismo que una empresa industrial que traslada su ERP a Azure con alta disponibilidad y recuperación ante desastres. Llamar a ambas cosas «migración cloud» genera confusión, expectativas mal calibradas y, en el peor caso, proyectos fallidos con facturas inesperadas. Este artículo desmonta el proceso en sus partes reales: qué se mueve, en qué orden, qué puede salir mal y qué ahorro es legítimo esperar.
¿Qué significa realmente «migrar a la nube»?
El término engloba al menos cuatro movimientos distintos que conviene separar desde el principio:
- Lift-and-shift (rehosting): se toman las máquinas virtuales tal como están y se trasladan a un proveedor cloud (AWS EC2, Azure VMs, Google Compute Engine). Es la opción más rápida pero la que menos ventajas cloud aprovecha.
- Replatforming: se ajusta la aplicación para usar servicios gestionados del proveedor (base de datos administrada, balanceadores, autoescalado) sin reescribir el código.
- Refactoring / re-architecting: se rediseña la aplicación como servicios nativos cloud (microservicios, serverless, contenedores). Mayor inversión, mayor ganancia a largo plazo.
- SaaS replacement: se retira una aplicación propia y se sustituye por un servicio en la nube ya existente (por ejemplo, abandonar un servidor de correo Postfix y pasarse a Microsoft 365 o Google Workspace).
Para la mayoría de pymes en España, el 80 % de los proyectos que se llaman «migración cloud» son en realidad una combinación de SaaS replacement (correo, ofimática, videollamadas) y replatforming del ERP o de las aplicaciones de negocio críticas. El lift-and-shift puro suele ser un paso intermedio, no un destino.
Los modelos de nube y qué responsabilidades quedan en tu empresa
Uno de los errores más repetidos es asumir que «estar en la nube» exime de responsabilidades operativas. La realidad es que el modelo de responsabilidad compartida varía según la capa que contrates:
| Capa | IaaS (ej. Azure VM) | PaaS (ej. Azure App Service) | SaaS (ej. Microsoft 365) |
|---|---|---|---|
| Hardware físico | Proveedor | Proveedor | Proveedor |
| Red y virtualización | Proveedor | Proveedor | Proveedor |
| Sistema operativo | Cliente | Proveedor | Proveedor |
| Middleware y runtime | Cliente | Proveedor | Proveedor |
| Aplicación | Cliente | Cliente | Proveedor |
| Datos y accesos | Cliente | Cliente | Cliente |
| Copias de seguridad | Cliente | Compartida | Cliente |
El punto más crítico: los datos siempre son responsabilidad del cliente, en cualquier modelo. Un proveedor SaaS que cierra o sufre un incidente no tiene obligación de devolverte tus datos en un formato utilizable si no has contratado explícitamente la exportación. Esta es la base de por qué la estrategia de respaldo debe diseñarse antes, no después, de la migración.
Las 6 fases de una migración cloud bien ejecutada
Fase 1: Inventario y clasificación de cargas de trabajo
Antes de mover nada, hay que saber qué se tiene. Eso implica inventariar todas las aplicaciones, servidores y dependencias, y clasificar cada carga de trabajo según tres variables: criticidad para el negocio, compatibilidad técnica con la nube y coste de migración estimado. Herramientas como Azure Migrate, AWS Migration Evaluator o incluso un inventario manual en una hoja de cálculo estructurada sirven para este fin. El resultado es una matriz que decide qué se mueve primero, qué se retira y qué se queda on-premise por razones técnicas, regulatorias o de coste.
Fase 2: Diseño de la arquitectura destino
Una vez clasificadas las cargas, se diseña la arquitectura en la nube: qué regiones usar (esto tiene implicaciones en latencia y en cumplimiento del RGPD sobre localización de datos), cómo se estructura la red virtual, qué servicios gestionados sustituyen a qué componentes actuales, y cuál es la estrategia de identidad (integración con Active Directory, SSO, MFA). Esta fase también define el modelo de gobierno cloud: políticas de etiquetado, límites de gasto, alertas de coste y quién puede aprovisionar recursos.
Fase 3: Prueba de concepto y migración piloto
Ninguna migración de producción debería ejecutarse sin haber migrado antes un entorno no crítico. El piloto valida que las aplicaciones funcionan en el entorno cloud, que los tiempos de respuesta son aceptables, que las integraciones con terceros siguen operativas y que el equipo interno conoce los procedimientos de operación. Una semana de piloto puede evitar semanas de incidencias en producción.
Fase 4: Migración de producción por oleadas
Las cargas de trabajo se migran en oleadas, empezando por las menos críticas. Para cada oleada se define una ventana de migración (normalmente fuera de horario de negocio), un plan de rollback claro y un conjunto de comprobaciones post-migración (smoke tests) que confirman que la aplicación está operativa antes de dar por cerrada la ventana. En aplicaciones con base de datos activa, la técnica habitual es la replicación continua: se mantiene la base origen sincronizada con el destino hasta el momento del corte, minimizando el tiempo de parada real.
Fase 5: Optimización y ajuste de costes
La factura cloud sorprende cuando no se gestiona activamente. El primer mes post-migración suele ser el más caro porque los tamaños de instancia se definen conservadoramente. La optimización implica ajustar el dimensionado (rightsizing), activar el autoescalado donde proceda, eliminar recursos huérfanos y aprovechar los modelos de compra por reserva (Reserved Instances en AWS, Azure Reserved VM Instances) que pueden reducir la factura de cómputo entre un 30 % y un 60 % frente a los precios bajo demanda, según los compromisos de 1 o 3 años.
Fase 6: Operación continua y mejora
La migración no termina el día que se apaga el servidor on-premise. La operación cloud requiere monitorización continua, gestión de actualizaciones de seguridad (especialmente en modelos IaaS), revisión periódica de costes y evolución de la arquitectura conforme cambia el negocio. En Summum Sistemas acompañamos a las empresas tanto en el proyecto de migración a la nube como en la operación continuada posterior.
Riesgos reales que los proyectos cloud subestiman
El coste de salida (egress) que nadie menciona en la oferta
Los grandes proveedores cloud cobran por los datos que salen de su plataforma (egress), pero no por los que entran. Para aplicaciones que mueven grandes volúmenes de datos hacia el exterior (exportaciones a clientes, integraciones con sistemas on-premise que no se migraron, backups descargados localmente), este coste puede ser significativo y no aparece en las estimaciones iniciales. AWS, Azure y Google Cloud publican sus tarifas de transferencia de datos, y deben incorporarse al TCO (coste total de propiedad) antes de tomar la decisión.
El vendor lock-in técnico
Usar servicios propietarios de un proveedor (funciones serverless, bases de datos NoSQL propietarias, servicios de mensajería específicos) aumenta la dependencia. Si el día de mañana quieres cambiar de proveedor o recuperar la operación on-premise, la portabilidad será costosa. La decisión de usar servicios propietarios frente a servicios estándar (contenedores Docker, bases de datos PostgreSQL, Kubernetes) debe tomarse de forma consciente, evaluando el beneficio inmediato frente al coste de migración futuro.
El cumplimiento normativo de los datos
El Reglamento General de Protección de Datos (RGPD) exige que las transferencias internacionales de datos personales a países fuera del Espacio Económico Europeo cuenten con garantías adecuadas. Los grandes proveedores cloud (AWS, Azure, Google Cloud) ofrecen regiones en la Unión Europea y cláusulas contractuales estándar, pero es el cliente quien debe verificar que los datos se almacenan y procesan en las regiones correctas y que el contrato con el proveedor cumple los requisitos de encargado del tratamiento según el artículo 28 del RGPD. La Agencia Española de Protección de Datos (AEPD) ha publicado guías específicas sobre computación en la nube que conviene consultar antes de migrar datos de carácter personal.
La continuidad durante la propia migración
El período de transición es el momento de mayor riesgo: los datos pueden existir en dos lugares a la vez, las copias de seguridad pueden no cubrir el estado intermedio y los equipos operan sobre una arquitectura que conocen a medias. Un plan de contingencia documentado, con responsables claros y criterios de rollback explícitos, no es un documento para auditorías: es lo que permite dormir tranquilo la noche de la migración.
¿Cuánto ahorra realmente una pyme al migrar a la nube?
La respuesta honesta es: depende de dónde viene. Una empresa que tiene servidores físicos propios con menos de cinco años de vida y una utilización alta probablemente no ahorre dinero en cómputo puro al migrar a IaaS. El cloud le aportará otras ventajas (elasticidad, resiliencia, acceso remoto), pero no reducción de factura de infraestructura.
Por contra, una empresa con servidores antiguos cuyo mantenimiento es caro, con una infraestructura sobredimensionada para cubrir picos que ocurren dos veces al año, o con costes elevados de sala de servidores (climatización, SAIs, vigilancia), suele ver una reducción de costes operativos real al migrar.
Los ahorros más sólidos y consistentes vienen de tres vectores:
- Sustitución de aplicaciones on-premise por SaaS: el coste de licencias, actualizaciones, soporte y administración de aplicaciones propias suele superar con claridad el coste del equivalente SaaS cuando se contabiliza el tiempo interno dedicado.
- Eliminación de hardware obsoleto: no renovar servidores cuya vida útil ha llegado a su fin y cuyo mantenimiento escala en precio.
- Reducción del tiempo de recuperación ante desastres: no es un ahorro directo en la cuenta de resultados cotidiana, pero el coste de una parada de 8 horas en los sistemas críticos de una empresa mediana supera con frecuencia el coste anual de un plan de continuidad en la nube bien diseñado.
Si necesitas una estimación realista para tu caso concreto, el punto de partida es un análisis de viabilidad de migración cloud que parta de tu inventario real, no de promedios de sector.
Nube pública, privada e híbrida: cuál encaja con tu empresa
La nube pública (AWS, Azure, Google Cloud) es la opción mayoritaria para pymes porque elimina la gestión de infraestructura física y ofrece escala bajo demanda. La nube privada (infraestructura dedicada, gestionada on-premise o en un colocation) tiene sentido cuando hay requisitos regulatorios muy estrictos, volúmenes de datos que hacen ineficiente la nube pública o necesidades de latencia ultrabaja. El modelo híbrido combina ambos: mantiene on-premise lo que no puede o no debe moverse (por coste, regulación o latencia) y traslada a la nube pública lo demás.
Para la mayoría de pymes españolas con entre 20 y 200 empleados, el modelo híbrido con Microsoft Azure como nube pública y Microsoft 365 como capa de productividad es la arquitectura de referencia que más agilidad operativa y menor fricción de adopción ofrece, especialmente cuando ya existe Active Directory en el entorno.
Preguntas frecuentes
¿Cuánto tiempo tarda una migración cloud completa?
Depende del alcance. Una migración de correo y ofimática a Microsoft 365 para una empresa de 50 usuarios puede completarse en 2 a 4 semanas, incluyendo la formación. Una migración de ERP on-premise a una plataforma cloud con integración de datos históricos, formación y estabilización post-go-live raramente se cierra en menos de 3 meses y puede extenderse a 6 en entornos complejos. La planificación realista del proyecto es uno de los factores que más influye en el éxito: la precipitación es la causa nº 1 de incidencias graves en producción durante migraciones.
¿Puedo migrar a la nube si tengo datos sensibles o regulados?
Sí, con las cautelas adecuadas. Los sectores con regulaciones específicas (salud, finanzas, datos de menores, defensa) tienen requisitos concretos sobre dónde y cómo se almacenan los datos. Los grandes proveedores cloud ofrecen regiones dentro de la Unión Europea y contratos de encargado del tratamiento conformes con el RGPD. Para sectores con regulación adicional (como el Esquema Nacional de Seguridad, obligatorio para entidades que tratan datos de las administraciones públicas), es necesario verificar que el proveedor cloud y la configuración elegidos cuentan con las certificaciones correspondientes.
¿Qué pasa si el proveedor cloud tiene una caída?
Los grandes proveedores publican SLA de disponibilidad generalmente superiores al 99,9 % para sus servicios, pero ninguno garantiza el 100 %. Una arquitectura bien diseñada distribuye las cargas críticas entre zonas de disponibilidad (o incluso entre regiones) para que la caída de un centro de datos no deje sin servicio a toda la empresa. El diseño para la resiliencia es una decisión de arquitectura, no una característica automática de contratar cloud: hay que pedirla y pagarla explícitamente.
¿Tiene sentido migrar a la nube si mi conexión a internet no es fiable?
Este es un punto de partida legítimo que muchas empresas en entornos rurales o con conectividad limitada deben evaluar. La dependencia de la conectividad es real en un entorno 100 % cloud. Las soluciones habituales incluyen: doble línea de internet (fibra principal + 4G/5G como respaldo), arquitecturas con caché local para las aplicaciones más críticas, y un análisis honesto de si el tiempo medio de caída de la conexión es comparable o inferior al tiempo medio de incidencias del servidor on-premise que se quiere sustituir. En muchos casos, la conectividad en España ha mejorado lo suficiente para que este argumento ya no sea decisivo, pero hay que verificarlo con datos reales antes de comprometerse.
Conclusión: la migración cloud es un proyecto de negocio, no solo de TI
Los proyectos de migración a la nube que fracasan tienen casi siempre el mismo patrón: se diseñan como proyectos técnicos sin implicar a las personas que usan las aplicaciones, sin asignar un responsable de negocio claro y sin establecer criterios objetivos de éxito más allá de «que funcione». Los que tienen éxito empiezan por definir qué problema de negocio se resuelve y trabajan hacia atrás para elegir la arquitectura que mejor lo resuelve al menor riesgo razonable.
En Summum Marketing llevamos desde 2007 acompañando a pymes y empresas medianas en proyectos de transformación tecnológica. Desde Summum Sistemas gestionamos migraciones cloud con un método estructurado que minimiza el riesgo operativo y maximiza el retorno real. Si estás evaluando dar el paso, el primer diagnóstico no cuesta nada: cuéntanos tu situación y te decimos con honestidad si tiene sentido, cuándo y cómo.