Área de cliente
Linux•29 de agosto de 2026• 12 vistas

Migrar un sitio de un alojamiento compartido a un VPS (2026)

Migrar un sitio de un alojamiento compartido a un VPS (2026)

¿Por qué migrar a un VPS?

El alojamiento compartido es adecuado para sitios con poco tráfico y proyectos que no necesitan control sobre el entorno del servidor. Algunas necesidades superan ese marco: una versión de PHP específica que no está disponible, acceso root requerido por una dependencia del sistema, rendimiento afectado por los vecinos del nodo compartido, o la necesidad de alojar varios proyectos con configuraciones aisladas. La migración a un VPS responde a esos casos concretos, sin que el alojamiento compartido resulte inadecuado para los usos que cubre.

Paso 1: Inventario antes de migrar

Haz el inventario completo antes de tocar nada. Una migración fallida casi siempre viene de un elemento olvidado en esta etapa.

Archivos y directorios

  • Directorio web principal (a menudo public_html/, www/ o htdocs/)
  • Archivos de configuración fuera de la raíz web (archivos .env, configuraciones de la aplicación)
  • Archivos subidos por los usuarios (a menudo en una subcarpeta uploads/ o storage/)
  • Crons configurados en el alojamiento compartido (listarlos desde el panel de control del proveedor actual)

Base de datos

  • Nombre de la base, nombre de usuario, contraseña (disponibles en el panel o en el archivo de configuración de la aplicación)
  • Versión de MySQL/MariaDB usada en el alojamiento compartido (comprobar la compatibilidad con la versión de destino)

Correo

  • Los buzones alojados en el proveedor de alojamiento compartido no migran automáticamente al VPS
  • Listar las direcciones de correo activas y decidir: migrarlas al VPS (Postfix/Dovecot), trasladarlas a un servicio externo, o dejarlas en el proveedor actual con los registros MX sin cambios

DNS y TTL

Antes de cualquier migración, baja el TTL del registro A del dominio a 300 segundos (5 minutos). Esto reduce el retardo de propagación durante el cambio final.

Localiza el registro A en la zona DNS del dominio (normalmente en el panel del registrador o del proveedor actual) y modifica el valor TTL:

; Antes de la migración: TTL habitual (a menudo 3600 o 86400)
misitio.es.  3600  IN  A  1.2.3.4

; Cambiar a 300 al menos 24h antes del cambio
misitio.es.  300   IN  A  1.2.3.4

Espera al menos la duración del TTL antiguo tras la modificación antes de proceder al cambio, para que la propagación sea efectiva.

Paso 2: Preparar el VPS

Instala y asegura el VPS antes de transferir los datos. No migres a un servidor sin configurar.

  • Seguridad básica (SSH por clave, UFW, actualizaciones): Checklist de seguridad VPS
  • Acceso SSH por clave: Guía clave SSH
  • Instalación de la pila web (Nginx + PHP-FPM + MariaDB): Guía Nginx + PHP-FPM
  • Crear el directorio de destino: sudo mkdir -p /var/www/misitio.es
  • Comprobar que la versión de PHP instalada en el VPS es compatible con la aplicación

Paso 3: Transferir los archivos

Con rsync (acceso SSH disponible en el alojamiento compartido)

rsync es el método recomendado: transfiere solo los archivos modificados, admite la reanudación en caso de interrupción y conserva los permisos. Fuente: man rsync

Desde el VPS (tirando de los archivos del alojamiento compartido):

rsync -avz --progress \
  [email protected]:/home/usuario/public_html/ \
  /var/www/misitio.es/

O desde una máquina local (si hay acceso SSH a ambos servidores):

rsync -avz --progress \
  [email protected]:/home/usuario/public_html/ \
  [email protected]:/var/www/misitio.es/

Opciones utilizadas:

  • -a: modo archivo (conserva permisos, marcas de tiempo, enlaces simbólicos)
  • -v: detallado (muestra los archivos transferidos)
  • -z: compresión durante la transferencia
  • --progress: muestra el progreso

Sin acceso SSH en el alojamiento compartido (SFTP o descarga manual)

Si el alojamiento compartido no ofrece acceso SSH, usa un cliente SFTP (FileZilla, Cyberduck) para descargar los archivos localmente y luego enviarlos al VPS:

# Desde la máquina local hacia el VPS
rsync -avz --progress /ruta/local/public_html/ \
  usuario@ip-vps:/var/www/misitio.es/

Ajustar los permisos

sudo chown -R www-data:www-data /var/www/misitio.es
sudo find /var/www/misitio.es -type d -exec chmod 755 {} \;
sudo find /var/www/misitio.es -type f -exec chmod 644 {} \;

Paso 4: Exportar e importar la base de datos

Exportación desde el alojamiento compartido

Si el alojamiento compartido ofrece acceso SSH:

mysqldump -u usuario_bd -p nombre_bd > export-$(date +%F).sql

Sin acceso SSH, usa phpMyAdmin (disponible en la mayoría de los alojamientos compartidos): Exportar > Formato SQL > Descargar.

Fuente: dev.mysql.com: mysqldump

Transferir el archivo de exportación al VPS

scp export-$(date +%F).sql usuario@ip-vps:/home/usuario/

Crear la base de datos en el VPS

sudo mariadb -u root
CREATE DATABASE nombre_bd CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
CREATE USER 'usuario_bd'@'localhost' IDENTIFIED BY 'contrasena_segura';
GRANT ALL PRIVILEGES ON nombre_bd.* TO 'usuario_bd'@'localhost';
FLUSH PRIVILEGES;
EXIT;

Importar los datos

mariadb -u usuario_bd -p nombre_bd < /home/usuario/export-$(date +%F).sql

Paso 5: Reconfigurar la aplicación en el VPS

Archivo de configuración de la aplicación

Actualiza los parámetros de conexión a la base de datos en el archivo de configuración de la aplicación (.env, wp-config.php, config.php según el framework):

  • Host de la base: localhost (la base está en el mismo servidor)
  • Nombre de la base, usuario y contraseña: los creados en el paso anterior

Rutas absolutas

Comprueba y actualiza todas las rutas absolutas codificadas en la configuración. En un alojamiento compartido, las rutas suelen empezar por /home/usuario/public_html/; en el VPS empiezan por /var/www/misitio.es/.

URL en la base de datos (si aplica)

Algunas aplicaciones (en particular WordPress) guardan la URL del sitio en la base de datos. Si la URL cambia durante la migración, actualiza esos valores. Para WordPress, usa WP-CLI:

sudo -u www-data wp search-replace 'http://antiguo-dominio.es' 'https://misitio.es' \
  --path=/var/www/misitio.es

Para las demás aplicaciones, consulta la documentación del framework correspondiente.

Vhost Nginx

Crea el vhost Nginx para el sitio. Para un sitio PHP genérico:

server {
    listen 80;
    server_name misitio.es www.misitio.es;
    root /var/www/misitio.es;
    index index.php index.html;

    location / {
        try_files $uri $uri/ /index.php?$query_string;
    }

    location ~ \.php$ {
        include snippets/fastcgi-php.conf;
        fastcgi_pass unix:/run/php/php8.4-fpm.sock;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        include fastcgi_params;
    }
}
sudo ln -s /etc/nginx/sites-available/misitio.es /etc/nginx/sites-enabled/
sudo nginx -t && sudo systemctl reload nginx

Para WordPress: Guía WordPress en VPS (vhost específico con gestión de enlaces permanentes).

Paso 6: Probar el sitio antes del cambio de DNS

Nunca cambies el DNS sin haber comprobado que el sitio funciona en el VPS. Modifica el archivo hosts local para forzar la resolución hacia la nueva IP, sin tocar el DNS público.

Modificar el archivo hosts local

En Linux o macOS:

sudo nano /etc/hosts

En Windows: C:\Windows\System32\drivers\etc\hosts (abrir como administrador)

Añade la línea:

ip-del-vps  misitio.es www.misitio.es

El navegador resuelve ahora misitio.es hacia el VPS, sin que los demás usuarios se vean afectados.

Puntos a comprobar

  • La página de inicio y las páginas internas se muestran correctamente
  • Los formularios de contacto funcionan (envío de correo)
  • Acceso al área de administración
  • Archivos subidos accesibles (imágenes, documentos)
  • Redirecciones activas (301, 302)
  • Sin errores en los registros de Nginx: sudo tail -f /var/log/nginx/error.log

Eliminar la entrada hosts tras las pruebas

# Eliminar la línea añadida en /etc/hosts
sudo nano /etc/hosts

Paso 7: Emitir el certificado SSL

Emitir el certificado Let's Encrypt antes del cambio de DNS no es posible (Certbot debe resolver el dominio hacia el VPS). Emite el certificado justo después del cambio, mientras el TTL bajo sigue activo.

sudo certbot --nginx -d misitio.es -d www.misitio.es

Guía completa: Guía Certbot de OuiHeberg.

Paso 8: Cambiar el DNS

Una vez validadas las pruebas, modifica el registro A del dominio para que apunte a la IP del VPS:

; Antes
misitio.es.  300  IN  A  1.2.3.4   (IP antigua del compartido)

; Después
misitio.es.  300  IN  A  5.6.7.8   (nueva IP del VPS)

Con el TTL a 300 segundos, la propagación es efectiva en 5 a 10 minutos para la mayoría de los resolutores DNS. Vigila los registros de Nginx durante ese periodo para confirmar que el tráfico llega al VPS:

sudo tail -f /var/log/nginx/access.log

Una vez confirmada la propagación, sube de nuevo el TTL a un valor estándar (3600 o 86400):

misitio.es.  3600  IN  A  5.6.7.8

Paso 9: Periodo de solapamiento

Mantén el alojamiento compartido activo durante 1 o 2 semanas tras el cambio. Este periodo permite:

  • Recuperar archivos olvidados en el inventario inicial
  • Comprobar que los correos alojados en el compartido siguen llegando (si los MX no han cambiado)
  • Disponer de un punto de retorno rápido en caso de problema crítico

No elimines los datos del alojamiento compartido antes de confirmar que todo funciona correctamente en el VPS.

Errores frecuentes

Los correos se quedan en el proveedor antiguo

Si el dominio tenía buzones en el alojamiento compartido, los registros MX siguen apuntando al proveedor antiguo tras el cambio del registro A. Suele ser intencionado (mantener el correo en el proveedor actual durante la transición), pero comprueba que lo sea. Decide explícitamente la estrategia de correo antes del cambio de DNS.

Los crons dejan de ejecutarse

Las tareas programadas configuradas en el panel del compartido no migran automáticamente. Vuelve a crearlas en el crontab del VPS:

crontab -e

Lista los crons del proveedor antiguo desde su panel de control antes de la migración (paso de inventario).

El certificado SSL no se emite de inmediato

Certbot no puede emitir un certificado para un dominio que aún no apunta al VPS. Emite el certificado justo después del cambio de DNS, mientras el TTL bajo sigue activo. Entre el cambio y la emisión del certificado, el sitio es accesible solo por HTTP.

Las rutas absolutas en la base de datos

Algunas aplicaciones guardan rutas absolutas en la base (ruta a los archivos subidos, URL de las imágenes). Esas rutas deben actualizarse tras la migración. Usa la función de buscar y reemplazar de la aplicación o un script SQL:

UPDATE wp_options SET option_value = REPLACE(option_value,
  '/home/antiguo/public_html',
  '/var/www/misitio.es')
WHERE option_value LIKE '%/home/antiguo/public_html%';

Preguntas frecuentes

¿Cuánto dura una migración?

Para un sitio estándar (unos cientos de MB, una base de datos de tamaño razonable), la migración técnica lleva de 1 a 3 horas. La preparación (inventario, bajada del TTL, configuración del VPS) representa la mayor parte del tiempo. El cambio de DNS en sí lleva menos de 10 minutos con un TTL de 300 segundos.

¿Se puede migrar sin interrupción del servicio?

Sí, si se sigue el procedimiento en orden: el sitio sigue activo en el compartido durante toda la preparación y las pruebas. La única interrupción potencial es la ventana entre el cambio de DNS y la emisión del certificado SSL (unos minutos). Con un TTL de 300 segundos, esa ventana es corta.

¿Hay que avisar a los visitantes?

Para un sitio con poco tráfico, no. Para una tienda en línea o una aplicación con usuarios conectados (sesiones activas), planifica la migración fuera de las horas punta y muestra una página de mantenimiento durante el cambio.

¿Qué hacer si el sitio no funciona después del cambio?

Vuelve a poner el registro A en la IP antigua del compartido (el TTL de 300 segundos permite una marcha atrás rápida). Diagnostica el problema en el VPS sin presión y relanza el cambio una vez resuelto. Precisamente por eso el alojamiento compartido debe permanecer activo durante el periodo de solapamiento.

¿Aún no lo tienes claro? Nuestro artículo VPS o alojamiento compartido detalla los casos en que migrar merece la pena.

¿Migras varios sitios al mismo VPS? Prepara la estructura de directorios y el aislamiento de antemano: configuración multisitio con Nginx.

Volver a la documentación