Migración de datos a la nube sin sorpresas: orden, coste y qué se queda en casa

Una migración de datos a la nube casi nunca falla por la tecnología. Falla porque se empezó a mover antes de saber qué había, porque nadie decidió qué significaba «terminado» o porque la factura mensual, que no existía en el servidor propio, aparece en el tercer mes y nadie la había presupuestado. La mudanza en sí es la parte más previsible del proyecto. Lo difícil es todo lo demás.

Esta guía recorre el proceso en orden: qué inventariar, qué estrategia aplicar a cada sistema, cómo secuenciar las fases, cuánto cuesta tenerlo funcionando después y qué conviene dejar fuera de la nube. Está pensada para quien aprueba el proyecto o responde de él, no para quien lo configura.

¿Qué significa migrar datos a la nube y por qué no es copiar archivos?

Migrar es mover un dato desde un entorno que tú operas (un servidor en la oficina, un centro de datos alquilado) a una infraestructura que opera otro y a la que accedes por contrato. Hasta aquí, sencillo. La confusión viene de creer que el dato viaja solo.

En la práctica se mueven cuatro cosas distintas, y cada una tiene su propio riesgo:

• El contenido: bases de datos, ficheros, copias de seguridad, histórico.
• La lógica que lo rodea: procedimientos almacenados, tareas programadas, scripts que alguien escribió hace ocho años y que nadie recuerda.
• Los accesos: quién entra, desde dónde, con qué permisos. En un servidor propio esto suele estar implícito en la red de la oficina; en la nube hay que declararlo.
• Las conexiones: el ERP que lee de esa base, el cuadro de mando que se alimenta cada noche, la hoja de cálculo que alguien conecta por ODBC y que sostiene un informe mensual.

Si solo mueves el contenido y olvidas las otras tres capas, el día del corte descubres que lo que se rompe es justo lo que sostenía la operación.

¿Qué hay que inventariar antes de mover nada?

El inventario es la fase que más se salta y la que más ahorra. No hace falta una herramienta cara: hace falta una tabla y dos semanas de preguntar a la gente correcta. Para cada sistema, anota como mínimo:

1. Qué contiene y quién responde de ello. Un dueño con nombre y apellido, no «informática». 2. Cuánto pesa y cuánto crece. El tamaño actual y el ritmo de crecimiento deciden el coste de almacenamiento y el tiempo de la carga inicial. 3. Quién y qué lo consulta. Aplicaciones, informes, integraciones, usuarios con acceso directo. Aquí aparecen las dependencias ocultas. 4. Qué requisitos legales tiene. Datos personales, datos de salud, información sujeta a conservación obligatoria. Esto condiciona la región donde se aloja y cómo se cifra. La base está en consultoría RGPD e IA. 5. Cuánto tiempo puede estar parado. El negocio sabe la respuesta aunque informática no la tenga escrita: ¿una hora sin facturar es un problema o una hora sin el cuadro de mando es solo una molestia? 6. Si se sigue usando de verdad. Casi toda empresa descubre en este paso bases de datos que nadie ha consultado en dos años.

Migrar datos muertos cuesta dinero cada mes y amplía la superficie de riesgo. El inventario es el momento barato de decidir qué se archiva, qué se borra con respaldo y qué se migra.

Y un detalle: los datos defectuosos se mudan igual de defectuosos. Si ya sabes que hay duplicados o campos sin sentido, mídelos antes del traslado con los criterios de calidad de datos; después nadie querrá reabrir el asunto.

¿Qué estrategia aplicar a cada sistema?

No existe una única forma de migrar y no todo se trata igual. Las estrategias habituales, de menos a más esfuerzo, son estas:

| Estrategia | En qué consiste | Cuándo encaja | Riesgo principal | |---|---|---|---| | Trasladar tal cual | Mover el sistema sin cambiarlo, solo a otra infraestructura | Aplicación estable, plazo corto, poco margen para tocar nada | Heredas todos los problemas y pagas la nube sin aprovechar sus ventajas | | Trasladar con ajustes | Mismo sistema, pero usando servicios gestionados (por ejemplo, base de datos administrada) | Quieres quitarte parches y copias de seguridad manuales | Pequeñas incompatibilidades que solo aparecen en pruebas | | Rediseñar | Reescribir parte del sistema para que aproveche el entorno nuevo | Sistema que ya era un problema y tiene sentido modernizar | Proyecto largo; el alcance se hincha fácil | | Sustituir | Abandonar el sistema y usar uno nuevo ya existente | La función es estándar y no diferencia a la empresa | Migración de datos al formato nuevo, que es otro proyecto | | Retirar | Archivar o borrar | El sistema ya no se usa | Descubrir tarde que alguien lo necesitaba una vez al año |

La tentación habitual es mezclar mudanza y modernización: «ya que movemos, lo rehacemos». Es el atajo más seguro hacia un proyecto de doce meses. Separa los dos movimientos: primero se traslada con los ajustes mínimos y se estabiliza; después, midiendo costes reales, se decide qué rediseñar.

¿En qué orden se hacen las fases?

La secuencia que mejor funciona es la que reduce el riesgo en cada paso y permite parar sin daño:

1. Inventario y decisiones de alcance. Lo descrito arriba. Termina con una lista priorizada y una estrategia por sistema. 2. Cimientos de la nube. Cuentas, redes, permisos, cifrado, etiquetado de costes y alertas de gasto. Se hace antes de subir un solo dato, porque ordenar un entorno ya poblado es mucho más caro. 3. Piloto con algo que no duela. Un sistema pequeño, preferiblemente interno, que no pare la facturación si sale mal. Sirve para afinar el procedimiento y para medir velocidades reales de transferencia. 4. Carga inicial y sincronización. Se copia el grueso del dato y se mantiene sincronizado con el origen mientras este sigue funcionando. Aquí se descubre cuánto tarda de verdad. 5. Pruebas con usuarios reales. No solo comprobar que las cifras coinciden. Que alguien de administración haga su cierre mensual contra el entorno nuevo y compare. 6. Corte. Una ventana pactada, con plan de marcha atrás escrito y probado. Se elige un momento de poca actividad, no el último día del trimestre. 7. Convivencia y apagado. El sistema antiguo se mantiene en solo lectura un tiempo definido de antemano. Apagar el servidor viejo es parte del proyecto: si queda encendido «por si acaso», has duplicado el coste.

La pregunta útil antes del corte no es «¿saldrá bien?», sino «si no sale bien a las diez de la noche, ¿quién decide volver atrás y cuánto se tarda?». Si nadie sabe contestarla, no estáis listos.

¿Cuánto cuesta de verdad una migración a la nube?

Aquí están las sorpresas más frecuentes, y casi todas tienen la misma causa: se presupuesta la mudanza y se olvida la vida posterior. Un presupuesto honesto separa tres bloques:

• Coste del proyecto (una vez): inventario, diseño, trabajo de migración, pruebas, formación. Depende del número de sistemas y de su complejidad, no del volumen en terabytes.
• Coste recurrente (cada mes): almacenamiento, cómputo, copias de seguridad, red, licencias, monitorización. Es la cifra que la dirección debe aprobar como gasto fijo nuevo.
• Coste de mantener y gobernar (continuo): alguien que revise los gastos, ajuste recursos, aplique cambios de seguridad y atienda incidencias.

Las partidas recurrentes que menos se anticipan:

• Salida de datos. Mover información hacia dentro suele ser barato; sacarla, para otros sistemas o para cambiar de proveedor, puede no serlo. Pregúntalo por escrito antes de firmar.
• Entornos de prueba que nadie apaga. Uno creado para un piloto y olvidado cobra todos los meses.
• Recursos sobredimensionados. Se contrata «por si acaso» más capacidad de la necesaria y el ahorro prometido no llega.

Para no llevarse sorpresas, cada recurso debe llevar etiqueta de proyecto y de responsable, y debe existir una alerta cuando el gasto se desvíe de lo previsto. Y compara siempre con el coste total del entorno propio, incluida la electricidad, la renovación de equipos y las horas de quien lo vigila. La nube no siempre sale más barata; a veces sale igual, con menos riesgo y más flexibilidad, y eso ya es un argumento válido si se plantea con franqueza. La lógica general de cómo se presupuestan estos proyectos está en cuánto cuesta un proyecto de IA, y casi todo se aplica igual aquí.

¿Qué conviene dejar en casa?

No todo tiene que irse, y quien te asegure lo contrario te vende algo. Hay cuatro situaciones en las que mantener un sistema en local es una decisión razonable:

• Requisitos legales o contractuales de ubicación. Hay clientes y sectores que exigen que cierto dato no salga de determinado ámbito. Si el contrato lo dice, se cumple.
• Latencia con maquinaria local. Un sistema que controla una línea de producción y responde en milisegundos no debería depender de la conexión a internet.
• Hardware amortizado y estable. Un servidor que funciona, está pagado y lo mantiene alguien competente no necesita jubilarse porque sí.
• Cargas muy predecibles y constantes. La elasticidad de la nube es una ventaja cuando la demanda varía. Si la carga es plana todo el año, la ventaja económica se reduce.

La respuesta habitual en empresas medianas es un modelo mixto: lo que cambia, crece o se consulta desde fuera, a la nube; lo estable, sensible o ligado al entorno físico, se queda. Esa frontera debe quedar escrita y revisarse cada año. Si además estás decidiendo dónde alojar el almacén analítico, la comparación está en data warehouse para empresas medianas.

¿Cómo saber si la migración ha salido bien?

«Funciona» no es un criterio. Define antes del corte criterios medibles y revísalos a los treinta días:

• Los totales de las tablas clave coinciden con el origen (recuento de filas, sumas de importes).
• Los procesos críticos, como el cierre mensual, se completan igual de rápido o mejor, y el sistema antiguo está apagado o archivado según lo previsto.
• El gasto del mes está dentro del rango presupuestado, y cada euro está asignado a un proyecto.
• Se ha hecho, al menos una vez, una restauración de copia de seguridad en el entorno nuevo, para comprobar que se puede recuperar y no solo que se guarda.

Una copia que nunca se ha restaurado es una suposición.

Preguntas frecuentes

¿Cuánto tarda una migración de datos a la nube?

Depende del número de sistemas y de sus dependencias, no solo del volumen. Una base de datos aislada y bien conocida puede moverse en semanas. Un conjunto de sistemas entrelazados, con integraciones y usuarios por todas partes, se mide en trimestres. La fase que más se subestima es el inventario inicial y las pruebas con usuarios reales.

¿Es seguro tener los datos en la nube?

Puede serlo tanto o más que en un servidor propio, siempre que se configure bien: cifrado, permisos mínimos, registro de accesos y copias verificadas. La seguridad es una responsabilidad compartida: el proveedor protege la plataforma y tú, tus accesos y tus datos.

¿Se puede migrar sin parar el negocio?

En la mayoría de casos sí, manteniendo el origen y el destino sincronizados hasta el corte, que se reduce a una ventana corta pactada. Lo que casi nunca es posible es un corte sin ninguna interrupción para todos los sistemas. Conviene que el negocio sepa de antemano cuál será esa ventana y qué no funcionará durante ella.

Si estás valorando mover tus datos y no tienes claro ni qué sistemas hay, ni cuáles dependen de cuáles, ni cuánto sumará la factura mensual, el primer paso no es elegir proveedor: es ese inventario. Es parte de lo que hacemos en la auditoría, con tus sistemas reales y sin compromiso de continuar, y si prefieres plantearlo antes en una conversación, hablemos.