Migración a la nube: trasladar lo existente sin romperlo todo

Una migración a la nube rara vez se rompe durante la copia. Se rompe en el momento en que uno cree haber terminado. En julio de 2026, el disco de nuestro servidor, que ejecuta una docena de servicios, entre ellos el CRM de Palmora Property, un portal inmobiliario que operamos para nuestro cliente, estaba lleno, y sus bases de datos en peligro: el propio CRM guardaba allí las fotos de los inmuebles. Las pasamos a un almacenamiento de objetos sin perder un archivo; la trampa estaba en unas claves de acceso que no llegaban hasta la aplicación.

Migrar, aquí, es trasladar lo que ya funciona (aplicaciones, datos, archivos, nombres de dominio) a un gran proveedor, a otro alojamiento o de vuelta a un servidor propio. Este es el método que aplicamos, carga por carga, para equipos de 20 a 500 personas. Supone que la base de infraestructura que acogerá esas cargas ya existe.

En resumen

• Inventaríe también lo que vive en el lado de sus usuarios: sesión, aplicación instalada, notificaciones.
• Elija una estrategia por carga de trabajo, y modernice después de la migración, no durante.
• Copie, pruebe, compare, y solo entonces purgue.
• Escriba las condiciones de la vuelta antes de empezar, y conserve el camino antiguo mientras dure la prueba.
• Un híbrido buscado no es un fracaso.

¿Qué hay que inventariar antes de migrar?

La guía de migración de Google Cloud divide una migración en cuatro fases: evaluar, planificar, desplegar, optimizar. La primera sirve para «understand your app and environment inventory, identify app dependencies and requirements, perform total cost of ownership calculations, and establish app performance benchmarks», es decir, comprender el inventario de aplicaciones y entorno, identificar dependencias y requisitos, calcular el coste total de propiedad y fijar referencias de rendimiento.

Las dependencias deciden el orden. Para la guía de planificación de Microsoft, «dependencies between workloads cause service disruptions if not migrated together», y cada lote debe llevarse lo que necesitan sus aplicaciones, «including supporting infrastructure such as load balancers, DNS records, or caching layers», es decir, también equilibradores de carga, registros DNS o capas de caché.

Inventaríe también lo que sus usuarios guardan de su lado. Para un navegador, otra dirección es otra aplicación: cuando Challenge Us, una aplicación de retos en grupo que hemos desarrollado, cambió de dirección en septiembre de 2026, la sesión, los ajustes, la aplicación instalada y las notificaciones se quedaban en la antigua.

¿Qué estrategia para cada carga de trabajo?

La guía de AWS sobre las grandes migraciones ordena las opciones en siete estrategias, las «7 Rs»:

• Retire: retirar o archivar lo que ya no sirve.
• Retain: conservar en su sitio, por ahora o para siempre.
• Rehost: rehospedar sin cambiar nada, el «lift and shift».
• Relocate: transferir numerosos servidores a la versión en la nube de su plataforma.
• Repurchase: sustituir por otra versión u otro producto.
• Replatform: trasladar con un poco de optimización de paso.
• Refactor or re-architect: revisar la arquitectura para aprovechar las funciones propias de la nube.

Para una gran migración, AWS desaconseja la refactorización, «because it involves modernizing the application during the migration», y recomienda «rehosting, relocating, or replatforming the application and then modernizing the application after the migration is complete»: rehospedar, reubicar o cambiar de plataforma primero, y modernizar una vez terminada la migración.

Las tres migraciones que hemos llevado a cabo encajan en estas casillas: la sincronización diaria de Palmora Property, rehospedada en nuestro servidor sin cambiar sus pasos; el almacenamiento de los archivos de su CRM, cambiado de plataforma mediante la configuración, sin tocar el código; las páginas de Challenge Us, trasladadas a otro alojamiento sin reescribirlas. No hemos llevado a cabo ninguna migración a AWS, Google Cloud o Azure: sus guías nos sirven aquí de vocabulario común, sea cual sea el destino.

¿Por qué copiar en lugar de mover?

Copiar mantiene intacto el original mientras la copia no haya demostrado su valía: la vuelta atrás cabe entonces en una línea de configuración. Para los archivos del CRM de Palmora Property, tras un reconocimiento en solo lectura, pusimos cuatro salvaguardas:

• Un espacio de almacenamiento aparte: el de las imágenes del sitio se purga de sus archivos huérfanos, y en un espacio común esa limpieza habría borrado los del CRM.
• Una clave de acceso dedicada, limitada a ese espacio, revocable sin tocar el sitio.
• Archivos que siguen siendo privados, servidos por el CRM tras su propia autenticación.
• Una copia de seguridad de cada archivo de configuración, con el valor antiguo conservado como comentario: es la vuelta atrás.

Este CRM es Twenty: lo tenemos en producción desde principios de 2025 y contribuimos al proyecto. Sabe guardar sus archivos en un almacenamiento compatible con S3, es decir, que habla la misma interfaz que el servicio de almacenamiento de Amazon: lo comprobamos en su código. La trampa estaba en otra parte: la configuración de los contenedores solo transmitía una parte de los ajustes del almacenamiento, sin las claves de acceso. Hubo que añadirlas al servicio principal y al servicio de tareas en segundo plano.

¿Cómo verificar antes de cambiar y antes de purgar?

Antes del cambio, se probó el acceso al nuevo almacenamiento en lectura y escritura, la copia terminó sin errores y se validó la nueva configuración. Después del cambio, tres pruebas, y una cuarta tras la purga:

1. 01Lectura

   Una ficha con fotos se abre, servida por el nuevo almacenamiento.

2. 02Escritura

   Una imagen añadida llega al nuevo almacenamiento, y la carpeta antigua no se mueve.

3. 03Integridad

   La comparación de ambos lados no encuentra ninguna diferencia. Es esta prueba la que autoriza la purga.

4. 04Prueba final

   Vaciada la carpeta antigua, cualquier imagen que siga mostrándose procede necesariamente del nuevo almacenamiento.

Un límite: la comparación se basaba en los nombres y tamaños de los archivos, en un solo sentido, sin huella del contenido. Muestra que no falta nada, no que cada byte sea idéntico.

¿Cómo cambiar con un camino de vuelta?

La vuelta atrás se decide antes de empezar. Microsoft lo escribe con todas las letras: «Always establish rollback criteria and procedures before initiating any migration or deployment.» Sus desencadenantes son medibles, como «CPU usage limits, response time thresholds, or error rates», es decir, límites de uso del procesador, umbrales de tiempo de respuesta o tasas de error, y el procedimiento se prueba: «Verify that the rollback procedure restores the system to a stable, known-good state.»

Para un nombre de dominio, todo depende del orden de los gestos. Cuando Challenge Us cambió de dirección, una redirección habría congelado la aplicación: su service worker, el pequeño programa que la sirve desde la caché del navegador, nunca se actualiza a través de una redirección. Las dos direcciones sirvieron, pues, la misma versión, y la antigua solo propuso mudarse una vez lista la nueva.

Cuando Challenge Us cambió después de alojamiento, la operación se hizo en cuatro tiempos.

Nuestra regla desde entonces: conservar el registro y pasar por una regla de enrutamiento, o eliminarlo y vincular el nombre a continuación, nunca lo uno sin lo otro.

¿Cuánto tiempo conservar el camino antiguo?

Una migración no siempre va hacia la nube. Desde el 23 de julio de 2026, la sincronización diaria que alimenta el sitio de Palmora Property a partir de su CRM se ejecuta en nuestro propio servidor, y ya no en un servicio de integración continua en línea. El CRM es local, las cachés viven en disco, los pasos y el horario no han cambiado, y un bloqueo impide que se solapen dos ejecuciones.

El camino antiguo se ha quedado, como respaldo manual. Pero un respaldo envejece: su caché está congelada desde julio, volvería a verificar miles de objetos y podría tardar horas. En Challenge Us, la dirección antigua no se cortará nunca: no cuesta nada, y es ella la que trae de vuelta las aplicaciones ya instaladas. Conserve, por tanto, el camino antiguo mientras alguien lo use, y compruebe de vez en cuando que sigue funcionando.

¿Cuándo purgar, y qué medir después?

La purga llega al final, después de la comparación, y con precauciones: una ruta exacta, y la verificación de que la carpeta contiene lo que se espera. Después, la vuelta sigue siendo posible pero cambia de naturaleza: alrededor de una hora de copia, la configuración restaurada, un reinicio. Nuestro artículo sobre lo que de verdad falla en las copias de seguridad de un servidor propio lo recuerda: una copia solo vale si se sabe restaurarla.

Después, mida.

Challenge Us mide, por su parte, quién sigue abriendo la aplicación por la dirección antigua.

Mantener una parte en su sitio: ¿es el híbrido un fracaso?

No, si es buscado. AWS hace de «Retain» una estrategia en sí misma, y cita, entre sus casos de refactorización, una base cuyas tablas, «such as customer information, patient, or patient diagnosis tables», se quedan en las instalaciones propias por razones de seguridad y cumplimiento. Microsoft pide documentar por qué un componente se queda en su sitio, y limitar la situación intermedia: «Minimize split-environment operation time.»

Estos dos proyectos de clientes son híbridos, por elección. El CRM de Palmora Property se ejecuta en nuestro servidor, sus archivos viven en un almacenamiento de objetos, y una tarea semanal de limpieza sigue por ahora en el servicio de integración continua. Challenge Us cambió de alojamiento para sus páginas, pero su base de datos, sus cuentas y sus funciones de servidor no se han movido. Para lo que viene, nuestro análisis de la dependencia europea de la nube estadounidense explica lo que el derecho europeo cambia en los costes de cambiar de proveedor.

La lista de control antes del cambio

• La copia ha terminado sin errores, y el original está intacto.
• Los nuevos ajustes llegan a todos los servicios afectados, no solo al primero.
• La lectura y la escritura están probadas en el nuevo destino.
• Las condiciones de la vuelta están escritas, con el nombre de quien decide.
• El camino antiguo sigue abierto, y usted sabe durante cuánto tiempo.
• Una señal avisará si el nuevo camino deja de funcionar.

Por dónde empezar

Enumere lo que debe moverse, con una estrategia y su condición de vuelta para cada línea. Empiece por una carga cuya vuelta sea sencilla, por ejemplo unos archivos. Si sus herramientas deben abandonar sus suscripciones por un servidor propio, nuestra salida del SaaS las traslada una por una, con datos verificados y vuelta atrás prevista. Si el destino es un gran proveedor o una nube europea, escríbanos qué debe moverse y adónde quiere llevarlo.

Preguntas frecuentes

Fuentes

1. La guía de migración de Google Cloud (nueva pestaña)docs.cloud.google.com
2. La guía de planificación de Microsoft (nueva pestaña)learn.microsoft.com
3. La guía de AWS sobre las grandes migraciones (nueva pestaña)docs.aws.amazon.com