Sistemas · Linux · VPS

Migración de una VPS Ubuntu 20.04 a 22.04 paso a paso

En este artículo vamos a ver cómo actualizar una VPS con Ubuntu 20.04 LTS a Ubuntu 22.04 LTS de forma ordenada, minimizando el riesgo de caída y dejando preparado un plan de reversión por si algo falla. La idea no es lanzar un do-release-upgrade a ciegas, sino seguir un procedimiento profesional: inventario, copias, validación de dependencias, actualización, comprobaciones posteriores y recomendaciones operativas.

Antes de empezar

Esta guía está pensada para una VPS de producción o preproducción con acceso por SSH y permisos de sudo. Si alojas varias webs, bases de datos, colas, procesos con pm2, contenedores Docker o repositorios de terceros, debes tratar la migración como un pequeño proyecto de sistemas, no como una simple actualización de paquetes.

  • Confirma que el proveedor de la VPS permite hacer snapshot antes de tocar nada.
  • Programa una ventana de mantenimiento y avisa a los usuarios si el servicio es crítico.
  • Haz primero la prueba en una VPS de staging o clonada.
  • No actualices si no tienes copia de los datos, de la configuración y de las bases de datos.
  • Ten documentado qué servicios deben arrancar al volver: web, BD, cola, workers, cron y firewall.

Por qué esta guía aporta valor

Una migración de servidor es útil cuando va más allá del comando de actualización. La parte delicada es operativa: copias, repositorios externos, validación de servicios, rollback y monitorización posterior. Esas comprobaciones son las que separan una actualización segura de una guía que sólo repite do-release-upgrade.

Si la VPS aloja aplicaciones Angular SSR, después de migrar conviene revisar también SEO en Angular Universal: códigos de estado, sitemap, canonical y HTML renderizado en servidor deben seguir funcionando cuando Nginx, Node.js y certificados SSL ya estén sobre el nuevo sistema.

1. Qué debes revisar antes de migrar

El primer paso consiste en saber exactamente qué estás ejecutando. Hay que comprobar versión del sistema, kernel, espacio libre, memoria, interfaces de red y servicios con fallo. Si ya existen errores antes de la migración, al actualizar tendrás más variables y diagnosticar será bastante peor.

Recomendación práctica: si el disco está muy justo, amplíalo antes. La actualización puede descargar cientos de paquetes y generar logs, cachés y kernels adicionales. Hacer un cambio mayor con menos de 2 o 3 GB libres es mala idea.

2. Inventario completo del servidor

Este punto suele omitirse y luego se paga caro. Necesitas una foto del estado actual: paquetes instalados, servicios habilitados, tareas programadas y puertos abiertos. Cuando algo deje de funcionar en 22.04, este inventario te permitirá comparar y recuperar mucho más rápido.

Además del inventario técnico, anota manualmente al menos estos elementos:

  • Dominios alojados y vhosts de Nginx o Apache.
  • Versiones de PHP, Node.js, Python, Java o cualquier runtime instalado.
  • Bases de datos activas y tamaño aproximado de cada una.
  • Repositorios APT externos: Docker, NodeSource, MongoDB, Elastic, PostgreSQL PGDG, etc.
  • Dependencias antiguas o software fuera de soporte.

3. Copias de seguridad obligatorias

Antes de migrar, la copia más importante es el snapshot del proveedor. Si el arranque falla, si se rompe el servicio SSH o si el sistema queda inconsistente, el snapshot es la salida más rápida. Aun así, conviene hacer también copias a nivel de fichero y de base de datos.

Si tu VPS usa MySQL, MariaDB, PostgreSQL o Redis, realiza copias explícitas y comprueba que se generan sin error:

Importante: no des por buena una copia sólo porque el comando terminó. Verifica tamaño, fecha y posibilidad real de restauración. Una copia corrupta vale cero.

4. Revisión de repositorios externos y paquetes retenidos

Muchas migraciones fallan por un motivo muy concreto: el sistema base sube a 22.04 pero el servidor depende de repositorios de terceros que sólo estaban preparados para 20.04. Antes de continuar, revisa qué fuentes APT tienes activas y qué paquetes están en hold.

Qué debes hacer aquí:

  • Identificar ficheros dentro de /etc/apt/sources.list.d/.
  • Comprobar si cada proveedor soporta Ubuntu 22.04 Jammy.
  • Desactivar temporalmente repositorios que no estén soportados.
  • Revisar paquetes retenidos con apt-mark showhold.

Si por ejemplo dependes de una versión antigua de PHP, MongoDB o Node.js, valida antes si seguirá funcionando en 22.04. No esperes a descubrir incompatibilidades después del reinicio.

5. Deja Ubuntu 20.04 completamente actualizado

No se debe saltar desde un sistema parcialmente actualizado. Primero hay que llevar 20.04 a su último estado estable, limpiar paquetes obsoletos y reiniciar para arrancar con el kernel más reciente disponible dentro de esa rama.

Tras el reinicio, vuelve a entrar por SSH y confirma que todo sigue operativo: web, certificados, base de datos, cron, workers y firewall.

6. Configura el sistema para recibir releases LTS

Ubuntu utiliza update-manager-core para gestionar este salto de versión. Debes asegurarte de que la política esté en Prompt=lts, especialmente si el servidor no recibe notificaciones de releases normales o si el fichero fue modificado anteriormente.

Consejo: si estás conectado por SSH, ejecuta la actualización dentro de tmux o screen. Si se corta tu terminal local, la sesión seguirá viva.

7. Lanzar la migración a Ubuntu 22.04

El comando principal es sudo do-release-upgrade. Durante la ejecución, Ubuntu suele hacer varias preguntas importantes:

  1. Confirmación de inicio de la actualización.
  2. Aviso por usar SSH y apertura temporal de un puerto alternativo.
  3. Detección de servicios que deberán reiniciarse.
  4. Preguntas sobre ficheros de configuración modificados en /etc.
  5. Eliminación de paquetes obsoletos al final del proceso.

En los conflictos de configuración no hay una respuesta universal. Si personalizaste un fichero como sshd_config, nginx.conf, php.ini o un archivo de repositorio, lo prudente es comparar cambios y no sobrescribir automáticamente sin saber qué contiene tu versión actual.

No cierres la sesión, no reinicies manualmente a mitad y no lances otra actualización en paralelo. Si la conexión SSH se cae, vuelve a entrar y comprueba si el proceso sigue dentro de tmux.

8. Qué revisar durante las preguntas del instalador

  • Si abre un puerto SSH temporal, toma nota por si debes reconectar.
  • Si aparecen paquetes de terceros sin soporte, acepta deshabilitarlos y revísalos después.
  • Si pregunta por reiniciar servicios automáticamente, normalmente conviene aceptar.
  • Si un fichero de configuración fue muy personalizado, guarda tu versión y compara antes de reemplazarla.
  • Cuando ofrezca eliminar paquetes obsoletos, revisa la lista y asegúrate de que no estás borrando algo crítico.

9. Reinicio y validación básica tras la migración

Una vez termine la actualización, reinicia si el asistente no lo hace por ti. El primer arranque es clave: comprueba versión, kernel, paquetes pendientes y errores del boot actual.

El objetivo aquí es confirmar dos cosas: que realmente estás en 22.04 y que el sistema no ha quedado con fallos silenciosos.

10. Validación de servicios de la web y del stack de aplicaciones

En una VPS de hosting o aplicaciones, el sistema operativo es sólo una parte. Después toca revisar cada servicio real del negocio. Empieza por los demonios principales:

Después valida las versiones instaladas. En Ubuntu 22.04 cambian librerías, OpenSSL, PHP base, Python del sistema y, según tu instalación, también algunos nombres de servicios.

Y por último comprueba conectividad local, sockets en escucha y firewall:

11. Validaciones funcionales que deberías hacer como mínimo

  • Abrir la web principal por HTTP y HTTPS y revisar códigos de respuesta.
  • Comprobar certificados TLS y renovación automática con Certbot si la usas.
  • Entrar en la zona de administración o login.
  • Probar subida de ficheros, formularios y envío de correo.
  • Ejecutar consultas reales contra la base de datos.
  • Verificar workers, colas, procesos PM2 y cron jobs.
  • Revisar logs de Nginx, Apache, PHP-FPM, MySQL, PostgreSQL y aplicación.

Si usas Node.js o Docker, presta mucha atención a librerías nativas y a cambios en OpenSSL. Hay aplicaciones que arrancan pero fallan en tiempo de ejecución por módulos compilados contra versiones antiguas.

12. Problemas típicos después de pasar a 22.04

  • Repositorios APT externos deshabilitados o apuntando todavía a focal.
  • Cambio de versión de PHP y módulos no instalados en la nueva rama.
  • Servicios que no arrancan por ficheros de configuración heredados.
  • Aplicaciones Node incompatibles con la versión disponible en el servidor.
  • Contenedores o imágenes antiguas que dependen de librerías del host.
  • Reglas de firewall o puertos distintos a los esperados.
  • Jobs de cron que dependen de rutas o binarios ya inexistentes.

La recomendación aquí es simple: no intentes corregir todo a la vez. Prioriza acceso SSH, red, web frontal, base de datos y, después, procesos secundarios.

13. Plan de rollback

Si la migración deja la VPS inestable y el tiempo de recuperación es alto, lo correcto es volver atrás. El método más rápido suele ser restaurar el snapshot del proveedor. Si el sistema arranca pero faltan configuraciones o datos, puedes restaurar backups parciales.

En entornos serios, el rollback no debería improvisarse. Debes decidirlo antes de migrar: si en X minutos no se recuperan SSH, web y base de datos, se restaura snapshot.

14. Recomendaciones finales

  • No migres una VPS crítica sin snapshot previo y sin copia externa.
  • Si puedes, clona la máquina y ensaya el procedimiento completo.
  • Documenta cada cambio de repositorio y cada fichero de configuración tocado.
  • Usa tmux para la sesión de actualización por SSH.
  • Verifica servicios, logs y funcionamiento real de la aplicación después del reboot.
  • Mantén un criterio de rollback claro y ejecutable.

Migrar de Ubuntu 20.04 LTS a 22.04 LTS no suele ser complicado cuando el servidor está ordenado, pero se vuelve delicado si acumula repositorios externos, software heredado o configuraciones sin documentar. Precisamente por eso conviene tratar esta tarea como una operación de sistemas paso a paso y no como una simple actualización de escritorio.