En el primer capítulo contamos por qué no montamos Ansible para una mudanza que ocurre una vez cada mucho tiempo. Este segundo cierra el tramo que más pesaba: la nube de archivos y la conversación en casa nueva.
No hace falta una lista de puertos ni de versiones para entender lo que cambió. Hace falta la sensación de que el servicio que usamos cada día —archivos, calendario, notas, llamadas— ya no cuelga del servidor viejo, y que la mudanza se hizo con un agente como herramienta, no como espectáculo.
Primero lo visible, luego lo delicado
Empezamos por el blog y las páginas estáticas. Parece lo fácil, y lo es a medias: sirve para probar el VPS nuevo de Time4VPS, el certificado, el flujo de publicar… sin tocar aún el corazón de los datos. Cuando eso se siente aburrido (en el buen sentido), llega el momento de Nextcloud.
Aquí el criterio fue distinto al de un “big bang” de madrugada. Primero se dejó lista la casa en el servidor nuevo —contenedores, base de datos moderna, proxy— sin volcar todavía los gigas de archivos. Solo cuando esa casa respondía, se cerró la antigua en mantenimiento, se copió el contenido y se abrió de nuevo ya en la IP nueva. El correo sigue, de momento, en el buzón de siempre: otra pieza, otro ritmo.
Ese orden lo marca una conversación con el agente más que un playbook: ¿qué se puede romper hoy y qué no? Hermes no sustituye el juicio; acelera el trabajo sucio y mantiene el hilo cuando la sesión se alarga.
Lo que no se ve y sí importa
Una mudanza de nube no termina cuando el login vuelve a ser verde. Hay que reponer aplicaciones que vivían solo en la máquina vieja, alinear secretos que no se pueden inventar de nuevo, y aceptar que un salto de versión grande se hace después de tener una copia fuera del servidor.
Ahí entra la parte menos glamurosa y más útil: copias cifradas hacia almacenamiento externo, en un ritmo semanal que no dispare la factura. No es un producto de marketing; es poder dormir si un upgrade sale mal. Con esa red, subimos de generación el propio Nextcloud y dejamos listas las llamadas de Talk con un backend de alto rendimiento: la diferencia entre “vale para dos” y “vale para una reunión de verdad”.
Nada de esto es magia. Es muchas microdecisiones —¿ahora o después?, ¿este aviso es ruido o fuego?— hechas en diálogo con un agente que puede entrar al servidor, comprobar, deshacer y seguir sin que tengas que reabrir veinte pestañas de documentación.
Por qué sigue ganando el agente en lo que “pasa una vez”
Si midieras esta mudanza en horas de calendario, un humano disciplinado también la termina. La diferencia es otra:
- El mapa cambia a mitad de camino (un aviso de integridad, una app que no arranca, un chequeo del panel que se cuelga). Un playbook rígido se vuelve deuda; un agente reencamina.
- El valor no está en repetir el mismo despliegue cien veces. Está en no dejar la mudanza a medias porque el fin de semana se comió el ánimo.
- El servidor viejo puede quedarse un tiempo como red de seguridad. Eso solo se disfruta si la casa nueva ya es el sitio por defecto.
Ansible y compañía siguen teniendo sentido en flotas y en fábricas de entornos. Para un hogar digital en un VPS de Time4VPS, el agente es la herramienta que encaja con la frecuencia real del trabajo.
Qué queda y qué no prometemos
Queda correo en el tramo largo, afinados menores y, con el tiempo, un Hermes de operaciones en la propia máquina. No prometemos cero avisos en el panel de administración: prometemos servicio usable, con camino de vuelta y sin convertir la privacidad en un producto de terceros.
Lo que no vas a encontrar aquí
No hay recetas de firewall, ni capturas de secretos, ni la lista exacta de contenedores. Quien necesite reproducir un stack empresarial tiene otros textos. Este cierra una historia humana: mudamos la nube a casa nueva con un agente como herramienta, en un proveedor que elegimos a sabiendas, y seguimos siendo dueños de los datos.
Si el primer capítulo era el porqué, este es el ya está el grueso hecho. El resto es continuidad —no un segundo proyecto de automatización para justificar el primero.