Una migración grande de homelab casi nunca empieza pareciendo grande. Empieza con algo inocente: cambiar un servidor por otro, mover unos discos, pasar varios servicios a un nodo nuevo, consolidar máquinas, actualizar almacenamiento o limpiar una arquitectura que se fue llenando de parches.
Luego tiras de un hilo y aparece la realidad. Ese contenedor usa una base de datos que vive en otro sitio. Ese servicio tiene un volumen montado por red. El DNS depende justo del nodo que quieres apagar. El reverse proxy apunta a nombres que ya no recuerdas por qué elegiste. Y las fotos familiares, que en teoría estaban “bien cubiertas”, tienen una ruta rara que nadie debería tocar con sueño.
Ahí es donde una migración deja de ser una tarde entretenida y se convierte en un problema doméstico. No porque sea técnicamente imposible, sino porque el homelab ya no es solo laboratorio. Hay cosas que usa la casa. Hay servicios que no apetece perder. Hay datos que no admiten bromas.
Yo antes migraba demasiado por impulso. Tenía una idea clara en la cabeza, abría una ventana de mantenimiento mental y empezaba. Funcionaba muchas veces, claro. Hasta que no funcionaba. Y cuando no funcionaba, el coste no era solo técnico. Era reconstruir contexto, recordar decisiones viejas y explicar por qué algo que ayer funcionaba hoy no abre.
Ahora lo planteo de otra forma. Una migración grande no es “mover servicios”. Es reducir incertidumbre antes de tocar nada.
Qué considero una migración grande#
No toda mudanza merece ceremonia. Si muevo un contenedor de pruebas, cambio una ruta temporal o levanto una VM nueva para cacharrear, no necesito montar un plan solemne. El problema aparece cuando la migración toca alguna de estas piezas:
- DNS interno.
- Firewall o VPN.
- Reverse proxy.
- Almacenamiento compartido.
- Backups.
- Fotos, documentos o contraseñas.
- Home Assistant si controla cosas reales.
- Servidores donde viven varios servicios a la vez.
- Bases de datos compartidas.
- Nodos Proxmox o NAS que concentran demasiadas dependencias.
Si una de esas piezas entra en juego, bajo el ritmo. La tentación es hacer justo lo contrario porque ya estás motivado y tienes tiempo. Mala combinación. Motivación, cafeína y acceso root son un trío con historial.
Mi filtro rápido es este: si algo sale mal, ¿afecta solo a mis juguetes o afecta a la casa? Si afecta a la casa, plan.
La foto inicial importa más que la herramienta#
Antes de mover nada, necesito una foto honesta del estado actual. No una documentación perfecta. Eso no existe en un homelab vivo. Me basta con un inventario útil.
Para cada servicio apunto:
- Dónde corre.
- Qué datos guarda.
- Qué base de datos usa.
- Qué nombres DNS tiene.
- Qué puerto o proxy lo expone.
- Qué otros servicios necesita.
- Cómo se hace backup.
- Cómo se restaura.
- Qué pasa si está caído unas horas.
Esto parece trabajo administrativo, y lo es un poco. Pero ahorra una cantidad absurda de nervios. El día de la migración no quiero descubrir que un servicio dependía de una carpeta montada desde un NAS que ya he apagado. Quiero saberlo antes.
También separo servicios por importancia. No todo merece el mismo cuidado.
Nivel 0: red mínima, acceso, DNS básico y rutas para poder administrar.
Nivel 1: datos familiares, contraseñas, backups, domótica importante y almacenamiento principal.
Nivel 2: servicios que uso mucho pero pueden caer un rato, como paneles, media, RSS o automatizaciones no críticas.
Nivel 3: laboratorio, pruebas y cosas que no deberían condicionar una migración.
El error es tratar todo como producción o todo como laboratorio. Las dos opciones son cómodas y falsas.
Mi mapa de dependencias#
El mapa de dependencias es donde una migración empieza a enseñar los dientes. No hace falta una herramienta compleja. Una tabla o un diagrama simple sirven.
Lo que busco no es belleza. Busco respuestas rápidas:
- Si apago este nodo, ¿qué se cae?
- Si muevo este volumen, ¿quién lo usa?
- Si cambio el DNS, ¿qué servicios dejan de resolver?
- Si el reverse proxy no arranca, ¿qué queda accesible por IP o VPN?
- Si la base de datos tarda más en volver, ¿qué servicios pueden esperar?
En mi caso, el DNS y el almacenamiento suelen ser los dos puntos que más respeto me dan. El DNS porque cuando falla parece que falla todo. El almacenamiento porque un error pequeño puede convertirse en una tarde muy larga.
También miro las dependencias humanas. Parece una tontería, pero no lo es. ¿Alguien en casa usa ese servicio a diario? ¿Hay una app en móviles que apunta a un nombre interno? ¿Hay una automatización que dispara algo visible? ¿Hay un backup que corre por la noche y puede pillarme en mitad del cambio?
La infraestructura no vive sola. Vive pegada a hábitos.
Backups antes de tocar, pero backups que pueda leer#
Antes de una migración grande quiero tres cosas: copia reciente, restauración conocida y acceso independiente.
Copia reciente significa que los datos importantes tienen backup de hace poco. No “creo que sí”. No “el job suele ir bien”. Lo miro.
Restauración conocida significa que sé cómo sacar los datos del backup. Un backup cifrado cuyo password está dentro del gestor de contraseñas que depende del servidor que voy a apagar es una broma mala. Todo lo necesario para recuperar lo crítico debe estar disponible fuera del sistema que migro.
Acceso independiente significa que no necesito que media plataforma esté viva para recuperar. Si todo depende del mismo nodo, la misma VPN, el mismo DNS y el mismo proxy, no tengo plan de recuperación. Tengo una pila muy ordenada hasta que deja de estarlo.
Para datos familiares soy especialmente pesado. Fotos, documentos y contraseñas van con más respeto que un dashboard. Si una app se rompe, se reinstala. Si pierdes fotos, no hay apt install que arregle eso.
La ventana de mantenimiento realista#
En casa no planifico ventanas como en empresa, pero sí elijo bien el momento. Una migración grande no se hace cuando todo el mundo necesita internet, cuando hay automatizaciones importantes corriendo o cuando yo estoy cansado.
Mi ventana ideal tiene estas condiciones:
- Nadie depende de los servicios en ese momento.
- Tengo al menos el doble del tiempo que creo necesitar.
- Tengo luz mental para tomar decisiones.
- No hay backups críticos a medio camino.
- Puedo parar sin dejarlo todo peor.
El doble del tiempo no es pesimismo. Es experiencia. La migración técnica puede durar una hora. La comprobación, los pequeños ajustes y el “por qué demonios esto no resuelve ahora” ocupan otra.
También decido de antemano qué significa parar. Si a determinada hora no está estable, vuelvo atrás o dejo un estado mínimo funcional. No quiero estar improvisando a la una de la mañana porque ya he cruzado demasiados puentes.
Orden de migración#
El orden manda. Mover primero lo cómodo suele ser tentador, pero no siempre es lo correcto.
Yo suelo ir así.
Primero preparo destino. Sistema actualizado, red clara, almacenamiento montado, monitorización básica y acceso probado. El destino tiene que estar aburrido antes de recibir servicios.
Después migro piezas no críticas. Sirven como prueba del camino: permisos, rutas, DNS, proxy, certificados, logs, backups. Si algo falla aquí, aprendo sin romper la casa.
Luego migro servicios con datos, pero de uno en uno. App, datos, base de datos, proxy, prueba, backup. No mezclo cinco servicios a la vez salvo que sean realmente inseparables.
Dejo lo crítico para cuando el proceso ya ha demostrado que funciona. DNS, contraseñas, fotos, documentos y automatizaciones familiares merecen el menor heroísmo posible.
Al final limpio referencias antiguas. Pero no borro demasiado rápido. Mantener el origen apagado unos días antes de destruir nada me ha salvado más de una vez. Una cosa es que el servicio arranque. Otra es que hayas recordado todos los casos raros.
Pruebas después de cada bloque#
Una migración sin pruebas es mudarse de casa sin abrir las cajas. Puede parecer que todo llegó bien hasta que necesitas algo.
Tengo una lista pequeña de comprobaciones:
- El servicio abre desde LAN.
- El servicio abre desde VPN si aplica.
- El login funciona.
- Los datos recientes están.
- Los trabajos programados siguen activos.
- Los backups corren en el nuevo sitio.
- Los logs no muestran errores repetidos.
- El móvil o cliente real conecta, no solo el navegador del servidor.
Esto último es importante. Muchas veces probamos desde el sitio más cómodo, que también es el menos representativo. Si una app la usa alguien desde el móvil, la pruebo desde el móvil. Si un servicio depende de DNS interno, pruebo con el nombre final. Si algo se expone detrás del proxy, no me vale que el puerto local responda.
También me gusta dejar una nota de “cosas raras vistas”. No todo merece resolverse en caliente, pero sí merece quedar apuntado. La memoria durante una migración es poco fiable. Crees que recordarás ese warning. No lo harás.
Rollback sin drama#
El rollback hay que pensarlo antes, no cuando la migración está ardiendo.
Para mí un rollback decente responde a tres preguntas:
- ¿Qué tengo que hacer para volver al estado anterior?
- ¿Qué datos podrían haberse modificado en el destino?
- ¿Cuánto tiempo puedo tardar en decidir volver?
La parte difícil no es técnica. Es emocional. Cuesta admitir que toca volver atrás, sobre todo cuando llevas horas. Pero un rollback temprano suele ser mucho más barato que una huida hacia delante.
En servicios con bases de datos, el rollback exige cuidado. Si levantas la app en el destino y empieza a escribir datos nuevos, volver al origen puede implicar pérdida o mezcla. Por eso intento hacer cortes claros: paro origen, copio, levanto destino, pruebo, decido. Si necesito coexistencia, la diseño, no la improviso.
En servicios menos delicados, puedo permitir más flexibilidad. Pero con datos familiares prefiero ser aburrido.
DNS, proxy y certificados: los sospechosos habituales#
En casi todas las migraciones hay tres piezas que dan guerra aunque el servicio esté bien: DNS, reverse proxy y certificados.
El DNS falla por caché, por resolutores distintos, por nombres internos duplicados o porque un cliente sigue usando el servidor viejo. El reverse proxy falla por headers, puertos, redes Docker, certificados o nombres mal apuntados. Los certificados fallan por renovaciones, rutas, permisos o validaciones que dependían de una IP antigua.
Mi forma de bajar riesgo es simple. No cambio todo a la vez.
Si puedo, mantengo el nombre DNS final y cambio solo el destino. Si puedo, mantengo el proxy estable y cambio el backend. Si tengo que cambiar proxy y backend, lo hago con servicios no críticos primero. Y si los certificados son internos, compruebo renovación y no solo validez actual.
El peor escenario es tocar DNS, proxy, certificados, almacenamiento y versión de la app el mismo día. Eso no es una migración. Es un escape room autoalojado.
Qué hago con el servidor viejo#
Cuando todo parece migrado, no destruyo el origen al momento. Lo dejo apagado o aislado unos días, según el caso. Si algo no aparece, puedo volver a mirar. Si una app tenía una ruta olvidada, todavía existe. Si un volumen no se copió bien, tengo margen.
Eso sí, tampoco conviene dejar cementerios eternos. Un servidor viejo encendido “por si acaso” se convierte en dependencia fantasma. Nadie sabe si se puede apagar, nadie recuerda qué corre y un año después está sosteniendo algo ridículo.
Mi punto medio:
- Lo apago cuando el destino lleva unos días estable.
- Lo mantengo disponible un tiempo razonable.
- Documento qué queda pendiente.
- Borro o reutilizo solo cuando estoy seguro.
El homelab se ensucia por acumulación, no por una mala decisión aislada. Cada migración debe dejar menos deuda, no más.
Lo que haría distinto#
Si empezara otra vez, documentaría antes. No con una wiki enorme ni con diagramas perfectos. Con notas pequeñas y actualizadas. Servicio, datos, backup, dependencia, cómo restaurar.
También separaría mejor laboratorio y producción doméstica. Cuando todo convive, migrar da miedo porque no sabes qué cosa experimental está pegada a algo importante. Un laboratorio puede romperse. La parte que usa la casa tiene que ser más aburrida.
Y tendría menos servicios. Esto cuesta admitirlo, porque montar servicios es divertido. Pero cada cosa que añades algún día se migra, se actualiza, se rompe o se queda vieja. El coste aparece después, no cuando haces el deploy.
Una migración grande bien hecha no debería sentirse heroica. Debería sentirse controlada. Un poco tensa, sí, porque tocar infraestructura siempre tiene su punto. Pero no como caminar a oscuras por tu propio rack.
Para mí la señal buena es esta: puedo explicar qué voy a tocar, qué se puede romper, cómo lo pruebo y cómo vuelvo atrás. Si no puedo explicarlo, todavía no estoy listo para migrar.
Y si aun así decido hacerlo, al menos sé que estoy jugando con fuego. Que en homelab a veces también pasa. Pero mejor saber dónde está la gasolina.