Cómo migrar tu sitio de otro hosting a una VPS Hostini
Guía técnica para migrar un sitio WordPress, PHP o estático desde hosting compartido (Hostgator, Locaweb, Kinghost) hacia una VPS Hostini sin downtime.
Migrar un sitio desde hosting compartido a una VPS es un upgrade común: sales de un entorno con recursos compartidos, reglas opacas de CPU/memoria y paneles genéricos hacia una máquina dedicada donde controlas el stack completo. La ganancia de rendimiento es real, pero el proceso de migración tiene trampas — un DNS mal configurado tira el sitio, una base de datos exportada mal corrompe datos, y archivos faltantes rompen el tema de WordPress.
Este tutorial cubre el camino completo para migrar desde proveedores como Hostgator, Locaweb, Kinghost, HostMídia o similares hacia una VPS Hostini con Ubuntu 24.04. El foco está en sitios PHP/MySQL (WordPress, Magento, Laravel, sitios estáticos con formularios), pero el proceso aplica a cualquier stack web. Reserva entre 2 y 4 horas para la ejecución completa en un primer intento, y lee el tutorial entero antes de empezar — algunos pasos necesitan prepararse en paralelo.
La estrategia general es: subir el sitio a la VPS en paralelo al antiguo, validar todo vía archivo hosts local, y solo entonces cambiar el DNS. Así nunca te quedas con el sitio fuera de línea y tienes rollback inmediato en caso de que algo salga mal.
Prerrequisitos
VPS Hostini aprovisionada con Ubuntu 24.04 LTS y acceso SSH como root. Acceso al panel del hosting antiguo (cPanel, Plesk o panel propietario) con permiso para crear backups y exportar la base de datos. Acceso al panel de tu registrador de dominio (Registro.br, GoDaddy, etc) para cambiar los nameservers o registros A. Cliente SSH local (Terminal en Linux/macOS, o Windows Terminal con OpenSSH).
Anota los datos de la VPS antes de empezar — los vas a usar varias veces:
45.xxx.xxx.xxx root 22 Ubuntu 24.04 LTS Inventario del sitio actual
Antes de tocar cualquier cosa, mapea lo que existe en el hosting antiguo. Que falte un archivo de configuración o una tabla de la base de datos en medio de la migración cuesta horas de retrabajo.
Lista todos los dominios, subdominios y aplicaciones hospedadas. En cPanel, esto aparece en “Dominios” y “Subdominios”. Anota también la versión de PHP que cada aplicación utiliza — sitios legados pueden necesitar PHP 7.4 u 8.0, mientras que WordPress reciente corre en PHP 8.2+.
Identifica las bases de datos activas. En phpMyAdmin, anota el nombre de cada base y el tamaño aproximado. Bases superiores a 1 GB necesitan exportación por línea de comandos — phpMyAdmin se traba con archivos grandes.
Anota credenciales externas que usa el sitio: APIs de pago, SMTP, integraciones con CRM. Estas credenciales van a necesitar ser revalidadas en el destino — algunas APIs bloquean el acceso cuando el IP de origen cambia.
Backup completo del origen
El backup es el punto de no retorno. Verifica cada archivo generado antes de proseguir.
Conéctate vía SSH al hosting antiguo (si tienes acceso) y genera un archivo comprimido del directorio público:
cd ~
tar czf site-backup.tar.gz public_html/Esto crea un archivo único conteniendo toda la estructura del sitio. En hostings con cPanel, el directorio por defecto es public_html — en otros paneles puede ser httpdocs, www o similar.
Exporta la base de datos vía mysqldump:
mysqldump -u usuario_db -p nombre_de_la_base > base.sqlSi el hosting no permite mysqldump directo, usa phpMyAdmin: selecciona la base, ve a “Exportar”, elige formato SQL y marca “Añadir DROP TABLE” — esto garantiza que la reimportación funcione incluso si la base de destino ya tiene tablas vacías.
Confirma que site-backup.tar.gz y base.sql no estén truncados. Un ls -lh revela el tamaño — si base.sql tiene 0 bytes o es mucho menor de lo esperado, la exportación falló silenciosamente (común cuando el tiempo de ejecución de PHP se agota en bases grandes).
Descarga los archivos a tu computadora local con scp (o vía el administrador de archivos del panel si no tienes SSH):
scp [email protected]:~/site-backup.tar.gz ./
scp [email protected]:~/base.sql ./Preparación de la VPS Hostini
Con el backup en mano, instala el stack mínimo en la VPS antes de subir los archivos. Para WordPress y la mayoría de los sitios PHP, esto significa nginx, PHP-FPM y MySQL.
Conéctate a la VPS y actualiza el sistema:
ssh [email protected]
apt update && apt upgrade -yInstala el stack web completo:
apt install -y nginx mysql-server php8.3-fpm php8.3-mysql \
php8.3-curl php8.3-gd php8.3-mbstring php8.3-xml php8.3-zip \
certbot python3-certbot-nginx unzipEste conjunto cubre el 95% de los sitios PHP en producción. Si tu CMS exige extensiones específicas (imagick, redis, memcached), instálalas junto.
Configura MySQL con contraseña fuerte:
mysql_secure_installationResponde “Y” en todas las opciones de seguridad. Anota la contraseña de root de MySQL — la vas a necesitar.
Transferencia de los archivos
Envía los archivos desde tu computadora local a la VPS:
scp site-backup.tar.gz [email protected]:/var/www/
scp base.sql [email protected]:/root/En conexiones lentas, considera comprimir el .sql antes de enviar: gzip base.sql reduce el archivo entre un 70-80% en bases con datos de texto.
En la VPS, extrae el sitio en el directorio web:
cd /var/www/
tar xzf site-backup.tar.gz
mv public_html tusitio.com
chown -R www-data:www-data tusitio.com
chmod -R 755 tusitio.comCrea la base de datos e importa el dump:
mysql -u root -pDentro del prompt de MySQL:
CREATE DATABASE tusitio CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
CREATE USER 'tusitio_app'@'localhost' IDENTIFIED BY 'contrasena_fuerte_aqui';
GRANT ALL PRIVILEGES ON tusitio.* TO 'tusitio_app'@'localhost';
FLUSH PRIVILEGES;
EXIT;Importa el dump:
mysql -u root -p tusitio < /root/base.sqlActualiza las credenciales de la base de datos en el archivo de configuración del sitio. Para WordPress, edita wp-config.php:
nano /var/www/tusitio.com/wp-config.phpAjusta DB_NAME, DB_USER y DB_PASSWORD con los valores creados en el paso anterior. Para Laravel u otros frameworks, edita el .env correspondiente.
Configuración de nginx
Crea el archivo de configuración del sitio:
nano /etc/nginx/sites-available/tusitio.comPega la configuración base:
server {
listen 80;
server_name tusitio.com www.tusitio.com;
root /var/www/tusitio.com;
index index.php index.html;
location / {
try_files $uri $uri/ /index.php?$args;
}
location ~ \.php$ {
include snippets/fastcgi-php.conf;
fastcgi_pass unix:/run/php/php8.3-fpm.sock;
}
location ~ /\.ht {
deny all;
}
}Activa el sitio y prueba la configuración:
ln -s /etc/nginx/sites-available/tusitio.com /etc/nginx/sites-enabled/
nginx -t
systemctl reload nginxEl nginx -t valida la sintaxis antes del reload — ejecútalo siempre. Un error de sintaxis en un archivo de config tira todos los sitios servidos por nginx.
Validación antes del DNS
Edita /etc/hosts en tu computadora (o C:\Windows\System32\drivers\etc\hosts en Windows) y añade una línea mapeando el dominio al IP de la VPS. Así solo tu navegador resuelve el dominio a la nueva VPS — los visitantes siguen viendo la versión antigua. Esto permite probar todo sin exponer la migración.
Añade en el archivo hosts:
45.xxx.xxx.xxx tusitio.com www.tusitio.com
Abre http://tusitio.com en el navegador. Si el sitio carga correctamente, navega por todas las páginas principales, inicia sesión en el panel admin (si es CMS) y prueba formularios. Errores visuales en esta etapa indican archivos faltantes — verifica permisos en /var/www/tusitio.com/wp-content/uploads/ o equivalente.
HTTPS antes de que apunte el DNS
Genera el certificado SSL vía Let’s Encrypt. Como el DNS aún apunta al hosting antiguo, usa el modo manual de validación por DNS:
certbot certonly --manual --preferred-challenges dns \
-d tusitio.com -d www.tusitio.comCertbot te pedirá crear registros TXT en tu DNS. Créalos en el panel del registrador, espera la propagación (generalmente 1-5 minutos), y confirma en certbot.
Actualiza nginx para usar SSL. Edita el archivo de configuración y reemplaza el bloque server por:
server {
listen 443 ssl http2;
server_name tusitio.com www.tusitio.com;
ssl_certificate /etc/letsencrypt/live/tusitio.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/tusitio.com/privkey.pem;
root /var/www/tusitio.com;
index index.php index.html;
location / {
try_files $uri $uri/ /index.php?$args;
}
location ~ \.php$ {
include snippets/fastcgi-php.conf;
fastcgi_pass unix:/run/php/php8.3-fpm.sock;
}
}
server {
listen 80;
server_name tusitio.com www.tusitio.com;
return 301 https://$host$request_uri;
}Recarga nginx: systemctl reload nginx.
Cambio del DNS
Con todo validado, es momento de apuntar el dominio a la VPS. Accede al panel del registrador (Registro.br para .com.br, o el que corresponda) y modifica el registro A del dominio al IP de la VPS.
Si es posible, baja el TTL del registro A a 300 segundos algunas horas antes del cambio. Esto reduce el tiempo de propagación — en vez de horas, el cambio aparece en minutos para la mayoría de los visitantes.
Quita la entrada del /etc/hosts local para probar la resolución real. Usa herramientas como dig tusitio.com +short (Linux/macOS) para verificar que el IP correcto se está propagando.
Verificación
Después de la propagación del DNS, valida el entorno en producción:
curl -I https://tusitio.com
La respuesta debe mostrar HTTP/2 200 y headers de SSL válidos. Verifica también en SSL Labs (ssllabs.com/ssltest/) que el grado del certificado sea A o A+.
Monitorea el sitio durante las primeras 48 horas: los logs de nginx en /var/log/nginx/access.log revelan errores 500, y Google Search Console muestra si hay caída anormal de tráfico (generalmente no la hay, si la migración se hizo correctamente).
Resolución de problemas
El sitio muestra “Error establishing a database connection”
Confirma que MySQL está corriendo: systemctl status mysql. Si está activo, verifica que las credenciales en wp-config.php (o equivalente) coincidan con las de la base de datos creada. Contraseñas con caracteres especiales a veces necesitan ser escapadas.
Las imágenes no aparecen o error 403
Permisos incorrectos en el directorio de uploads. Ejecuta:
chown -R www-data:www-data /var/www/tusitio.com
find /var/www/tusitio.com -type d -exec chmod 755 {} \;
find /var/www/tusitio.com -type f -exec chmod 644 {} \;
Error 502 Bad Gateway
PHP-FPM no está respondiendo. Verifica con systemctl status php8.3-fpm. Confirma también que el fastcgi_pass en la config de nginx apunta al socket correcto de la versión instalada.
Próximos pasos
Con el sitio migrado y estable, considera añadir capas de robustez a tu VPS:
- Configura backups automáticos diarios para evitar pérdida en caso de falla de hardware.
- Añade monitoreo de uptime (UptimeRobot, BetterUptime) para ser alertado si el sitio cae.
- Habilita firewall con
ufwpermitiendo solo los puertos 22, 80 y 443. - Configura renovación automática del certificado SSL vía cron:
certbot renew --quietsemanal. - Considera usar una CDN (Cloudflare gratuito) frente a la VPS para acelerar la entrega y reducir carga.
Si estás migrando varios sitios a la vez o tienes requisitos de alta disponibilidad, una VPS Hostini ofrece snapshots automáticos, IPs adicionales y protección DDoS incluida — útil para evitar dolores de cabeza con ataques volumétricos que tiran hostings compartidos.
Preguntas frecuentes
¿Cuánto tiempo tarda la migración completa?
Para un WordPress típico de hasta 5 GB con base de datos MySQL pequeña (< 500 MB), el proceso lleva entre 2 y 4 horas — incluyendo backup, transferencia, instalación del stack y ajuste de DNS. Sitios más grandes o con varias aplicaciones pueden requerir una ventana de mantenimiento planificada.
¿Voy a perder posicionamiento en Google durante la migración?
No, siempre que mantengas las mismas URLs, redirijas correctamente cualquier path que cambie y configures HTTPS en la nueva VPS antes de apuntar el DNS. Google recupera el ranking en pocos días si el contenido permanece idéntico y el servidor responde rápido.
¿Necesito apagar el sitio antiguo antes de subir el nuevo?
No. La práctica correcta es dejar el sitio antiguo en línea mientras subes la copia funcional a la VPS, validas vía archivo hosts o subdominio temporal y solo entonces cambias el DNS. Mantén el hosting antiguo activo durante 48-72h después de la propagación como seguridad.
¿Cómo manejo los correos electrónicos que estaban en el hosting compartido?
Una VPS no incluye servicio de email por defecto. La recomendación es migrar los correos a un proveedor dedicado (Google Workspace, Zoho, Microsoft 365) antes de cambiar el DNS. Evita montar un servidor SMTP propio en una VPS nueva — la entregabilidad es baja por reputación de IP.
¿Qué hago si el sitio usa funciones SMTP de PHP para enviar correos?
Configura PHP para enviar vía SMTP autenticado de un proveedor transaccional (Amazon SES, Brevo, Mailgun, Postmark). Plugins como WP Mail SMTP en WordPress hacen esto sin alterar código. Evita la función mail() nativa en una VPS — casi nunca entrega.
¿Y si no tengo acceso SSH en el hosting antiguo?
Usa el administrador de archivos del panel para crear un archivo .tar.gz del public_html y descargarlo vía HTTPS, y exporta la base de datos vía phpMyAdmin como SQL crudo. Funciona pero es más lento — en sitios grandes, pide acceso SSH temporal al soporte del hosting antiguo.