Migrar servicios en un homelab parece una tarea mecánica hasta que la haces con algo que importa. Copias datos, levantas contenedores, apuntas DNS al servidor nuevo y listo. Esa es la versión bonita. La real suele incluir volúmenes que no estaban documentados, bases de datos con permisos raros, rutas absolutas, certificados que vivían en otro sitio, clientes que siguen apuntando al servidor viejo y un momento incómodo en el que ya no sabes si apagar o rezar.
He aprendido a tratar las migraciones domésticas como una mudanza pequeña, no como un comando. Si muevo un servicio que usa la casa, quiero saber qué llevo, qué dejo atrás, cómo pruebo que funciona y cómo vuelvo al estado anterior si algo sale mal. No hace falta montar una consultora. Hace falta no improvisar con datos reales.
La buena noticia es que una migración bien preparada no tiene por qué dar miedo. La mala es que casi todo el trabajo importante ocurre antes de tocar el servicio.
Primero decido si merece la pena migrar#
No todo lo que se puede mover debe moverse. Esta pregunta ahorra dolores: ¿por qué estoy migrando?
Puede haber motivos buenos. El servidor viejo se queda corto, el almacenamiento está mal planteado, quiero separar producción y laboratorio, necesito menos consumo, voy a retirar hardware, o quiero meter el servicio en una arquitectura más limpia. También hay motivos flojos. “Ya que estoy”, “me apetece ordenarlo” o “el servidor nuevo está vacío”. Estos últimos son peligrosos porque no tienen un final claro.
Antes de migrar, intento escribir una frase simple: “Muevo este servicio de A a B para conseguir X”. Si no puedo completar esa frase, probablemente estoy buscando entretenimiento con riesgo.
En casa, el tiempo también cuenta. Migrar algo un miércoles por la noche porque te entró la inspiración puede acabar en una sesión absurda hasta la una. Si el servicio guarda fotos, documentos, contraseñas, DNS o domótica, elijo una ventana tranquila y asumo que puede fallar. El cansancio es un mal operador de sistemas.
Inventario antes de tocar nada#
La migración empieza con inventario. No con copiar datos. No con apagar contenedores. Inventario.
Para cada servicio apunto:
- Dónde corre ahora.
- Cómo arranca.
- Qué puertos usa.
- Qué dominios o nombres internos resuelve.
- Qué volúmenes guarda.
- Qué base de datos usa.
- Qué otros servicios necesita.
- Qué usuarios o dispositivos se conectan.
- Cómo se hace backup.
- Cómo comprobaré que está vivo después.
Esto parece obvio hasta que descubres que un servicio usa una carpeta montada por NFS, un token guardado en un .env, una base de datos compartida y una regla de firewall que escribiste hace cuatro meses. El inventario no es burocracia. Es una linterna.
Para servicios Docker Compose, guardo el compose.yaml, el .env saneado, la lista de volúmenes y las rutas reales. Para VMs o LXCs, apunto disco, red, recursos, snapshots y dependencias. Si el servicio está en Kubernetes, necesito manifests, secretos, PVCs, ingress y storage class. Si no sé nombrar esas piezas, todavía no migro.
Clasifico datos y configuración#
No todos los archivos tienen el mismo valor. En una migración separo tres cosas:
- Configuración, que define cómo arranca el servicio.
- Datos, que son lo que no quiero perder.
- Estado desechable, como cachés, temporales o índices reconstruibles.
Esta separación evita mover basura y reduce miedo. Por ejemplo, en Paperless-ngx me importan documentos, base de datos, media y configuración. Los índices pueden reconstruirse. En Immich, me importan biblioteca, base de datos y configuración de almacenamiento. En un dashboard simple, quizá solo necesito un archivo de configuración y listo.
Cuando no haces esta clasificación, acabas copiando todo a lo bruto. Funciona, pero arrastras errores, permisos raros, logs antiguos y rutas que no deberían sobrevivir. A veces interesa una migración limpia: instalar el servicio nuevo, restaurar solo datos importantes y dejar atrás la mugre.
Mi preferencia actual es no migrar sistemas como fósiles completos salvo que necesite conservar exactamente el entorno. Si puedo reconstruir limpio y restaurar datos, mejor.
Backup justo antes, aunque ya tenga backups#
Antes de migrar hago una copia específica. No me vale solo confiar en el backup programado de anoche. Quiero una foto mental y técnica del punto exacto desde el que parto.
La copia puede ser un snapshot, un dump de base de datos, una exportación de configuración, una copia de volúmenes o una combinación. Lo importante es que sepa restaurarla. No basta con tener un archivo grande llamado backup. Tiene que haber una ruta de vuelta.
También guardo metadatos: versión de la imagen, versión de la base de datos, rutas, variables de entorno y comandos de arranque. Muchas migraciones fallan no porque falten datos, sino porque restauras datos buenos en una versión incompatible o con una configuración distinta.
Si el servicio usa base de datos, paro escrituras antes de copiar o uso un método consistente. Copiar una base de datos viva como si fuera una carpeta normal es una forma muy barata de fabricar corrupción. A veces sale bien. Esa no es una estrategia.
Bajo el TTL de DNS antes de la migración#
Si el servicio se accede por nombre, DNS importa. Mucho. Un error típico es cambiar la IP y luego esperar que todo el mundo obedezca al instante. No siempre pasa.
Antes de migrar, bajo el TTL del registro interno o externo si puedo. No hace falta hacerlo con días de margen para un homelab, pero sí conviene pensar en cachés. También reviso si hay clientes configurados con IP fija. Siempre hay alguno. Una app móvil, un bookmark antiguo, una integración de Home Assistant, un script que apunta directo al servidor viejo porque un día tenías prisa.
Durante la migración, prefiero mantener el nombre del servicio estable. Que cambie el servidor por debajo, no la forma en que los usuarios llegan. Si además puedo dejar una redirección temporal o una página de mantenimiento, mejor.
En servicios internos, usar nombres claros ayuda mucho. paperless.mi-homelab.local o vault.mi-homelab.local son más fáciles de mover que una colección de IPs pegadas en configuraciones. Ya sé que parece una obviedad. También sé cuántas veces se ignora.
Levanto el destino sin apagar el origen#
Siempre que puedo, preparo el servidor nuevo antes de tocar el viejo. Paquetes, Docker, carpetas, usuarios, permisos, red, firewall, proxy, certificados y monitorización básica. El objetivo es que el corte real sea corto.
Me gusta poder arrancar el servicio nuevo en modo aislado, con otro puerto, otro nombre temporal o detrás de una entrada DNS de prueba. Así valido que la aplicación levanta, que ve la base de datos, que monta los volúmenes y que no hay errores obvios.
No siempre se puede hacer una prueba completa con datos reales sin parar el origen, sobre todo si hay escrituras. Pero sí puedo comprobar mucho antes: versión correcta, permisos de carpetas, acceso al almacenamiento, conectividad entre servicios, logs limpios y healthcheck básico.
Esto reduce la migración a una fase final más pequeña: parar escrituras, copiar delta o restaurar último backup, arrancar destino, probar, cambiar DNS o proxy.
Hago una lista de pruebas, no una sensación#
Después de migrar, “parece que funciona” no vale. Necesito pruebas concretas. No tienen que ser muchas, pero sí representar el uso real.
Para cada servicio defino antes cómo validar:
- Login con usuario normal.
- Lectura de datos existentes.
- Escritura o subida de un dato nuevo.
- Tarea programada crítica.
- Backup posterior a la migración.
- Acceso desde la red que lo usará de verdad.
En Paperless, subiría un documento de prueba y comprobaría OCR. En Vaultwarden, login, desbloqueo, sincronización y prueba de backup. En Immich, ver fotos antiguas, subir una nueva y comprobar jobs. En Home Assistant, miraría automatizaciones básicas y acceso desde móvil. En DNS, resolvería nombres desde clientes reales, no solo desde el servidor.
La prueba buena es la que detecta fallos incómodos. Una pantalla de login no demuestra mucho. Muchas apps arrancan con media configuración rota y solo fallan cuando tocas una función concreta.
Mantengo el servidor viejo en cuarentena#
Cuando el servicio nuevo funciona, no borro el viejo al instante. Lo dejo apagado o aislado durante unos días, según el tipo de servicio. Eso me da una salida si aparece un fallo raro.
La cuarentena tiene reglas. El origen no debe seguir recibiendo escrituras. Si puede confundirse con el servicio nuevo, lo paro. Si necesito conservarlo encendido para consultar algo, bloqueo acceso normal o cambio puertos. Lo que no quiero es una situación de doble vida, donde algunos clientes escriben en el nuevo y otros en el viejo.
Pasados unos días, cuando backups nuevos han corrido y no hay quejas, retiro el origen. Entonces sí limpio DNS, proxy, reglas de firewall, monitorización, jobs de backup y documentación. La limpieza es parte de la migración. Si no, el homelab se llena de fantasmas.
El rollback se decide antes, no durante el susto#
Rollback no significa “ya veremos”. Significa saber qué condición me hace volver atrás y cómo lo haré.
Antes de empezar, defino algo así:
- Si el servicio nuevo no arranca en 30 minutos, vuelvo al origen.
- Si los datos restaurados no cuadran, vuelvo al origen.
- Si una función crítica falla y no tiene arreglo rápido, vuelvo al origen.
- Si el problema aparece después de cambiar DNS, revierto DNS y proxy.
También decido qué datos se perderían si vuelvo atrás. Esto importa. Si durante una hora el servicio nuevo acepta escrituras y luego vuelvo al viejo, esas escrituras pueden quedar colgadas. Para servicios importantes, reduzco esa ventana o bloqueo escrituras hasta estar seguro.
En casa no hace falta un plan militar. Pero cuando algo falla, pensar se vuelve más difícil. Tener una decisión escrita baja el pulso.
Cuidado con los permisos y usuarios#
Una migración aparentemente perfecta puede romperse por permisos. Contenedores que esperan UID y GID concretos, carpetas copiadas como root, servicios que antes escribían en un volumen local y ahora en NFS, bases de datos que no aceptan conexiones desde la nueva IP, scripts con rutas antiguas.
Por eso no copio solo archivos. Reviso propiedad, permisos, usuario del contenedor y método de montaje. Si uso NFS o SMB, compruebo que el servicio puede escribir de verdad. No solo leer. Muchos fallos aparecen cuando la aplicación intenta generar miniaturas, mover archivos, crear logs o escribir una migración de base de datos.
También vigilo los relojes. Parece una tontería hasta que tokens, certificados o sesiones empiezan a fallar por desajustes de hora. NTP funcionando en origen y destino. Aburrido, necesario.
No migro diez cosas a la vez#
La tentación de aprovechar una tarde y mover media infraestructura es fuerte. Mala idea. Cada servicio tiene sus rarezas y las dependencias se cruzan justo cuando menos apetece.
Prefiero migraciones pequeñas y ordenadas. Primero servicios secundarios. Luego una pieza importante. Después descanso. Si hay que mover varios servicios relacionados, dibujo el orden. Base de datos, almacenamiento, aplicación, proxy, DNS, backups, monitorización. No todo a la vez.
También intento no mezclar cambios. Migrar servidor, cambiar versión, cambiar base de datos y reorganizar dominios en la misma operación es pedir confeti técnico. Si algo falla, no sabes qué lo causó. Mejor mover primero manteniendo versiones y comportamiento. Luego mejoras.
Esta regla suena lenta. En realidad ahorra tiempo. Lo que mata una migración no es ir despacio, es depurar tres cambios simultáneos a medianoche.
Después actualizo documentación y backups#
La migración no termina cuando la web carga. Termina cuando la documentación apunta al sitio correcto y los backups protegen el nuevo estado.
Reviso:
- Inventario actualizado.
- Runbook del servicio cambiado.
- Jobs de backup apuntando al servidor nuevo.
- Monitorización revisada.
- DNS viejo eliminado.
- Reglas de firewall viejas quitadas.
- Volúmenes antiguos marcados para borrar.
Este paso da pereza porque ya has conseguido lo visible. Precisamente por eso conviene hacerlo antes de cantar victoria. Si no, dentro de tres meses buscarás un backup en el servidor viejo o mirarás una alerta de un host que ya no existe.
Me gusta dejar una nota breve de la migración: fecha, origen, destino, versión, incidencias y cosas pendientes. No es literatura. Es munición para el futuro.
Mi checklist práctica#
La versión corta de mi proceso queda así:
- Confirmar por qué migro.
- Inventariar servicio, datos y dependencias.
- Hacer backup específico y comprobar que puedo restaurar.
- Preparar servidor destino.
- Bajar TTL o revisar DNS.
- Probar destino con nombre temporal si es posible.
- Parar escrituras en origen.
- Copiar datos finales o restaurar backup.
- Arrancar destino.
- Pasar pruebas funcionales concretas.
- Cambiar DNS o proxy.
- Mantener origen en cuarentena.
- Actualizar backups, documentación y monitorización.
- Retirar origen cuando haya confianza.
No es sofisticado. Esa es la gracia. Las migraciones domésticas buenas suelen ser aburridas. Pocas sorpresas, pasos claros y una salida si algo se tuerce.
La migración perfecta no existe#
Siempre aparece algo. Un permiso raro, una dependencia olvidada, un cliente con caché, un volumen más grande de lo esperado, una app que cambia comportamiento al detectar otra URL. La meta no es evitar cualquier fallo. Es evitar quedarte sin mapa.
Migrar servicios entre servidores en casa debería servir para simplificar, no para añadir otra capa de misterio. Si después de mover algo entiendes peor tu homelab, la migración no ha terminado. Falta limpiar, documentar o deshacer alguna decisión.
Mi regla final es bastante simple: no migres nada que no sepas restaurar. Y si no sabes restaurarlo, el problema no es la migración. El problema ya estaba ahí, esperando el momento perfecto para recordártelo.