Qué Considerar al Migrar a Otro Proveedor de Alojamiento Web

Migrar un sitio web a un nuevo proveedor de alojamiento es una de las operaciones de infraestructura de mayor riesgo que puede realizar el propietario de un sitio. Realizada correctamente, resulta en cero pérdida de datos, tiempo de inactividad insignificante y un rendimiento notablemente mejor. Realizada de forma descuidada, produce bases de datos dañadas, fallos de DNS, caídas en el posicionamiento SEO y horas de trabajo de recuperación de emergencia.

Esta guía cubre cada fase crítica de una migración de alojamiento — desde la auditoría previa a la migración y la validación de compatibilidad, pasando por la mecánica del cambio de DNS, hasta el monitoreo posterior a la migración — con la profundidad técnica necesaria para ejecutarla sin incidentes.

Fase 1: Audita tu entorno de alojamiento actual antes de tocar nada

El fallo de migración más común se debe a omitir una auditoría exhaustiva del entorno existente. Antes de evaluar un nuevo proveedor, necesitas un inventario preciso de lo que realmente estás ejecutando.

Perfilado de tráfico y recursos

Extrae al menos 90 días de datos de recursos del servidor — no solo conteos de páginas vistas. Las métricas que importan son:

• Conexiones concurrentes máximas — no el tráfico promedio, sino el pico máximo que tu servidor debe manejar
• Consumo de memoria por trabajador PHP o proceso de aplicación
• Patrones de I/O de disco — especialmente relevante si ejecutas una aplicación con uso intensivo de base de datos como WooCommerce o un CRM personalizado
• Utilización de ancho de banda — totales de transferencia mensual versus el límite de tu plan actual

Si tu alojamiento actual proporciona cPanel o Plesk, estos datos son accesibles en las secciones de uso de recursos o AWStats. En un Linux VPS, ejecuta lo siguiente para capturar una instantánea de referencia:

vmstat 1 10
iostat -x 1 5
free -m
df -h

Esta salida te indica si tu cuello de botella es CPU, RAM o disco — lo que determina directamente si necesitas un plan compartido más grande, un VPS, o un Servidor Dedicado.

Inventario del stack de software

Documenta cada componente de tu stack con números de versión exactos:

• Versión de PHP (p. ej., 8.1, 8.2) y extensiones activas (mbstring, curl, gd, imagick, redis)
• Versión de MySQL o MariaDB y motor de almacenamiento (InnoDB vs. MyISAM importa para las herramientas de migración)
• Software del servidor web: Apache, Nginx, LiteSpeed, o una combinación de proxy inverso
• Cualquier módulo compilado, reglas .htaccess personalizadas, o bloques de ubicación nginx.conf
• Tareas cron — expórtalas desde crontab -l y documéntalas por separado
• Tipo de certificado SSL e emisor (Let’s Encrypt, CA comercial, wildcard)

Omitir incluso una extensión PHP en el servidor de destino puede romper silenciosamente funcionalidades que solo se manifiestan bajo acciones específicas del usuario — un error notoriamente difícil de rastrear después de la migración.

Fase 2: Evalúa y selecciona el nivel de alojamiento correcto

Elegir el nivel de alojamiento incorrecto es un error estructural que obliga a una segunda migración en cuestión de meses. Mapea los resultados de tu auditoría a la clase de infraestructura correcta.

Comparación de niveles de alojamiento

Regla de decisión clave: Si tu aplicación requiere una configuración específica de pool PHP-FPM, conexiones de socket Redis, reescrituras personalizadas de Nginx, o cualquier proceso daemon, el alojamiento compartido es arquitectónicamente incompatible. Necesitas como mínimo un VPS con acceso root.

Para sitios WordPress o Joomla con tráfico moderado, un VPS con cPanel proporciona la interfaz familiar del panel de control manteniendo el aislamiento y el rendimiento de una máquina virtual.

Criterios de evaluación de proveedores

Más allá de las afirmaciones de marketing, evalúa a los proveedores en estos factores técnicos verificables:

• SLA de disponibilidad con cláusulas de penalización económica — un SLA del 99.9% sin compensación no tiene valor
• Clasificación de nivel del centro de datos (Tier III o Tier IV para cargas de trabajo en producción)
• Redundancia de red — BGP multi-homing, múltiples proveedores upstream
• Tipo de almacenamiento — NVMe SSD versus SATA SSD versus disco giratorio (las diferencias de latencia son significativas)
• Política de copias de seguridad — frecuencia, período de retención, si las copias de seguridad se almacenan fuera del sitio
• SLA de tiempo de respuesta del soporte — distingue entre el tiempo de primera respuesta y el tiempo de resolución

Fase 3: Crea y verifica una copia de seguridad completa

Ninguna migración debe comenzar sin una copia de seguridad verificada y restaurable. “Verificada” significa que realmente has probado la restauración — no solo confirmado que existe un archivo de copia de seguridad.

Qué debe incluir una copia de seguridad completa

• Archivos del directorio raíz web — todo el directorio raíz del documento, incluyendo archivos ocultos como .htaccess y .env
• Todas las bases de datos — exportadas como volcados .sql, no solo una copia de archivos del directorio de la base de datos
• Datos de correo electrónico — si usas Alojamiento de Correo Electrónico vinculado a tu dominio, exporta los buzones antes de cualquier cambio de DNS
• Tareas cron — crontab -l > crontab_backup.txt
• Certificados SSL y claves privadas — si usas un certificado comercial, exporta la cadena completa
• Archivos de configuración del servidor — /etc/nginx/, /etc/apache2/, /etc/php/, configuraciones personalizadas de my.cnf

Realizando una exportación de base de datos

Para MySQL/MariaDB, usa mysqldump con opciones que preserven la fidelidad completa:

mysqldump 
  --single-transaction 
  --routines 
  --triggers 
  --events 
  --set-gtid-purged=OFF 
  -u root -p your_database_name > database_backup_$(date +%F).sql

El indicador --single-transaction es crítico para las tablas InnoDB — toma una instantánea consistente sin bloquear las tablas, lo que significa que tu sitio en vivo continúa atendiendo solicitudes durante el volcado.

Verificando la integridad de la copia de seguridad

# Check the SQL dump is not truncated
tail -5 database_backup_2024-01-15.sql

# Verify file count in web root backup
tar -tzf webroot_backup.tar.gz | wc -l

# Test restoration to a local or staging environment
mysql -u root -p test_restore_db < database_backup_2024-01-15.sql

Una copia de seguridad que no has probado restaurar no es una copia de seguridad — es una falsa sensación de seguridad.

Fase 4: Valida la compatibilidad en el servidor de destino

Antes de transferir datos de producción, configura el nuevo entorno y valida la compatibilidad usando un enfoque de staging.

Verificación de versión y extensiones PHP

# On the destination server
php -v
php -m | grep -E 'mbstring|curl|gd|imagick|redis|zip|intl|opcache'

Compara esta salida con tu inventario de la Fase 1. Cualquier extensión faltante debe instalarse antes de la migración, no después.

Verificación de compatibilidad de base de datos

Si migras de MySQL 5.7 a MySQL 8.0 (un escenario común), ten en cuenta estos cambios que rompen la compatibilidad:

• El charset utf8mb3 está obsoleto; las columnas pueden necesitar declaraciones de charset explícitas
• El comportamiento de GROUP BY cambió — las consultas que funcionaban en 5.7 pueden fallar en 8.0 sin ajuste del modo ONLY_FULL_GROUP_BY
• NO_ZERO_DATE está habilitado por defecto en modo estricto, lo que rechaza campos de fecha que contienen 0000-00-00

Prueba tu volcado SQL contra la versión MySQL de destino antes de cambiar el tráfico de producción.

Traducción de configuración del servidor web

Si migras de Apache a Nginx (un escenario frecuente al moverse a un VPS optimizado para rendimiento), tus reglas .htaccess no se traducen automáticamente. Conversiones comunes:

Redirección .htaccess de Apache:

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

Equivalente en Nginx en bloque server:

server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://$host$request_uri;
}

Omitir esta traducción es una de las causas más comunes de errores 404 y bucles de redirección después de la migración.

Fase 5: Ejecuta la migración minimizando el tiempo de inactividad

Elige la ventana de migración estratégicamente

Analiza tus registros de Google Analytics o del servidor para identificar tu ventana de menor tráfico — típicamente entre las 02:00 y las 05:00 en la zona horaria de tu audiencia principal, un martes o miércoles. Evita los viernes; si algo sale mal, tus opciones de soporte se reducen significativamente durante el fin de semana.

El flujo de trabajo de migración con staging primero

1. Apunta un subdominio al nuevo servidor (p. ej., staging.example.com) usando un registro A, sin tocar el DNS de producción
2. Transfiere todos los archivos y bases de datos al nuevo servidor
3. Actualiza la cadena de conexión de base de datos de la aplicación para apuntar a la nueva base de datos
4. Modifica tu archivo /etc/hosts local para resolver el dominio de producción a la IP del nuevo servidor — esto te permite probar la configuración de producción completa sin afectar a los usuarios en vivo:

# Add to /etc/hosts on your local machine
203.0.113.50  example.com www.example.com

1. Ejecuta una prueba funcional completa — cada formulario, flujo de pago, sistema de inicio de sesión, endpoint de API y carga de medios
2. Ejecuta benchmarks de rendimiento usando ab (Apache Benchmark) o wrk:

ab -n 1000 -c 50 https://example.com/

1. Solo después de pasar todas las pruebas, procede al cambio de DNS

Configuración del certificado SSL

Asegúrate de que tu certificado SSL esté instalado y validado en el nuevo servidor antes del cambio de DNS. Si usas Let’s Encrypt:

certbot --nginx -d example.com -d www.example.com

Si usas un certificado comercial de un proveedor como los disponibles a través de Certificados SSL, instala la cadena de certificados completa (certificado + CA intermedia + CA raíz) para evitar errores de validación de cadena en clientes más antiguos.

Fase 6: Cambio de DNS — El paso técnicamente más delicado

La propagación de DNS es ampliamente malentendida. La cifra de 48 horas es un límite del peor caso, no una duración típica. En la práctica, la mayoría de los resolvers respetan el valor TTL del registro que se está cambiando.

Reducción de TTL previa al cambio

Al menos 24–48 horas antes de la ventana de migración, reduce el TTL en tus registros A y registros CNAME a 300 segundos (5 minutos):

example.com.    300  IN  A  203.0.113.50
www.example.com. 300 IN  A  203.0.113.50

Esto significa que después de actualizar el registro a la nueva IP, el valor en caché anterior expira en 5 minutos para la mayoría de los resolvers — no en 48 horas. Esta es la técnica de mayor impacto para minimizar la ventana de propagación de DNS.

Actualizaciones de servidores de nombres vs. registros A

Existen dos enfoques distintos para el cambio de DNS:

• Cambiar solo los registros A (manteniendo los mismos servidores de nombres autoritativos): La propagación sigue el TTL del registro. El enfoque más rápido si tu registrador de dominio permite la gestión directa de registros.
• Cambiar los servidores de nombres (apuntar al DNS del nuevo host): Los TTL de los servidores de nombres son típicamente de 24–48 horas y no están bajo tu control directo. Este enfoque tarda más.

Prefiere las actualizaciones de registros A cuando sea posible. Gestiona el DNS de tu dominio a través de tu panel de control de Registro de Dominio para un control directo a nivel de registro.

Mantener el servidor antiguo activo durante la propagación

No canceles ni apagues el plan de alojamiento antiguo inmediatamente después del cambio de DNS. Mantenlo en funcionamiento durante un mínimo de 72 horas. Durante la propagación, una parte de tus usuarios seguirá resolviendo a la IP antigua — esas solicitudes deben continuar siendo atendidas. Apagar el servidor antiguo prematuramente crea una interrupción real para esos usuarios.

Fase 7: Monitoreo y validación post-migración

Monitoreo de disponibilidad y rendimiento

Configura el monitoreo externo de disponibilidad inmediatamente después del cambio de DNS — no después de que creas que la propagación está completa. Herramientas a implementar:

• UptimeRobot o Better Uptime — verificaciones HTTP(S) cada 1–5 minutos desde múltiples ubicaciones geográficas
• Google Search Console — observa los informes de Cobertura y Core Web Vitals en busca de anomalías en los 7 días posteriores a la migración
• New Relic o Datadog — monitoreo de rendimiento a nivel de aplicación si tu aplicación lo justifica

Identificación y resolución de errores post-migración

Ejecuta un rastreo del nuevo sitio inmediatamente usando Screaming Frog o un espejo wget:

wget --spider --recursive --no-verbose --output-file=crawl_log.txt https://example.com
grep -i "broken|404|error" crawl_log.txt

Problemas comunes post-migración y sus causas:

Corrección de URLs codificadas en bases de datos WordPress

Un problema frecuente y sutil: WordPress almacena la URL del sitio en la base de datos, y muchos temas y plugins almacenan URLs absolutas en datos serializados. Después de migrar a un nuevo dominio o protocolo, ejecuta:

wp search-replace 'http://old-domain.com' 'https://new-domain.com' 
  --all-tables 
  --precise 
  --report-changed-only

El indicador --precise maneja correctamente los datos serializados de PHP, que el reemplazo de cadenas simple rompe.

Fase 8: Cancela el plan de alojamiento antiguo

Cancela el plan antiguo solo después de confirmar todas las siguientes condiciones:

• La propagación de DNS está completa (verifica con dig +trace example.com desde múltiples ubicaciones)
• El monitoreo de disponibilidad muestra 100% de disponibilidad durante al menos 72 horas consecutivas
• No se detectaron errores 404 ni enlaces rotos en los registros de rastreo
• La entrega de correo electrónico funciona correctamente en el nuevo servidor
• Los análisis muestran patrones de tráfico normales sin caídas anómalas
• Tienes una copia local de todos los archivos de copia de seguridad independiente de cualquiera de los dos proveedores de alojamiento

Lista de verificación técnica de puntos clave

Úsala como tu lista de verificación de ejecución de migración:

Pre-migración

• [ ] Exportada la línea base de uso de recursos de 90 días (CPU, RAM, I/O, ancho de banda)
• [ ] Documentado el stack de software completo con números de versión exactos
• [ ] TTL de DNS reducido a 300 segundos al menos 24 horas antes del cambio
• [ ] Creada y probada la copia de seguridad completa (archivos + bases de datos + tareas cron + correo electrónico)
• [ ] Validada la versión PHP y todas las extensiones requeridas en el servidor de destino
• [ ] Traducidas las reglas .htaccess al formato Nginx si se cambia de servidor web
• [ ] Certificado SSL instalado y validado en el nuevo servidor antes del cambio de DNS

Durante la migración

• [ ] Archivos transferidos usando rsync con verificación de suma de comprobación (rsync -avz --checksum)
• [ ] Base de datos importada y verificado que el conteo de filas coincide con el origen
• [ ] Funcionalidad completa del sitio probada mediante anulación de /etc/hosts antes del cambio de DNS
• [ ] Archivos de configuración de la aplicación actualizados (host de base de datos, credenciales, URL del sitio)

Post-migración

• [ ] Monitoreo externo de disponibilidad activo dentro de los 5 minutos del cambio de DNS
• [ ] Servidor antiguo mantenido en funcionamiento durante un mínimo de 72 horas después del cambio
• [ ] Rastreo completo del sitio completado; todos los errores 404 y enlaces rotos resueltos
• [ ] URLs codificadas corregidas en la base de datos (especialmente para WordPress)
• [ ] Google Search Console monitoreado durante 7 días después de la migración
• [ ] Plan de alojamiento antiguo cancelado solo después de confirmar todos los elementos anteriores

Preguntas frecuentes

¿Cuánto tiempo tarda realmente la propagación de DNS y puedo acelerarla?

La duración de la propagación de DNS está determinada por el valor TTL del registro que se está cambiando, no por una ventana fija de 48 horas. Si reduces el TTL de tu registro A a 300 segundos al menos 24 horas antes de la migración, la mayoría de los resolvers recogerán la nueva IP en 5–10 minutos tras el cambio. La cifra de 48 horas se aplica a los cambios de delegación de servidores de nombres, que tienen TTLs fuera de tu control.

¿Migrar a un nuevo host perjudicará mi posicionamiento en Google?

Una migración ejecutada correctamente sin tiempo de inactividad, con estructura de URL preservada y SSL válido no tiene impacto negativo en el SEO. Las posiciones pueden caer temporalmente si el nuevo servidor es más lento, si las URLs cambian sin redirecciones 301 adecuadas, o si el sitio es inaccesible durante el rastreo. Monitorea los informes de Cobertura y Core Web Vitals de Google Search Console durante 14 días después de la migración.

¿Cuál es la forma más segura de transferir bases de datos grandes sin corromper los datos?

Usa mysqldump con el indicador --single-transaction para tablas InnoDB para garantizar una instantánea consistente sin bloqueos de tabla. Transfiere el archivo de volcado por SSH usando scp o rsync en lugar de phpMyAdmin, que tiene límites de tamaño de archivo y restricciones de tiempo de espera que causan truncamiento silencioso en bases de datos grandes.

¿Necesito reinstalar mi certificado SSL después de migrar?

Sí. Los certificados SSL están vinculados a la clave privada del servidor, que reside en el servidor original. Debes reemitir el certificado en el nuevo servidor (gratuito para Let’s Encrypt) o exportar la clave privada y la cadena de certificados del servidor antiguo e instalarlos en el nuevo. Asegúrate de que el certificado esté completamente validado antes de actualizar el DNS, para que HTTPS funcione inmediatamente después del cambio.

¿Cómo verifico que mi migración está completa antes de cancelar el plan antiguo?

Ejecuta dig +trace example.com @8.8.8.8 y dig +trace example.com @1.1.1.1 para confirmar que tanto los resolvers de Google como de Cloudflare devuelven la IP del nuevo servidor. Verifica el monitoreo de disponibilidad durante 72 horas consecutivas de respuestas limpias. Rastrea el sitio en busca de errores 404 y verifica la entrega de correo electrónico. Solo después de que todo esto pase es seguro terminar la cuenta de alojamiento antigua.