Una migración mal planificada puede dejar una tienda sin ventas, un sitio corporativo mostrando errores o correos que no llegan a tiempo. Esta guía de migración de hosting WordPress está pensada para empresas que necesitan cambiar de proveedor sin poner en riesgo su operación, sus datos ni la confianza de sus clientes.
Mover WordPress no consiste solo en copiar archivos y restaurar una base de datos. También hay que validar versiones de PHP, configuraciones de seguridad, certificados SSL, DNS, caché, formularios, correos y procesos de pago. El objetivo no es simplemente que el sitio abra en el nuevo servidor: debe funcionar igual o mejor antes de cambiar el tráfico real.
Cuándo conviene migrar un sitio WordPress
Las señales suelen ser claras. Un sitio lento de forma persistente, caídas frecuentes, recursos compartidos con demasiadas cuentas, soporte que responde tarde o sin resolver, y límites poco transparentes son motivos suficientes para evaluar un cambio. También lo son una infraestructura sin copias de seguridad confiables, falta de protección ante ataques o dificultades para escalar una tienda online.
No todos los problemas se corrigen con una migración. Un WordPress con plugins obsoletos, imágenes pesadas o una base de datos saturada seguirá teniendo limitaciones en un servidor nuevo. Sin embargo, una plataforma con SSD, recursos correctamente asignados, versiones actualizadas de PHP y soporte técnico competente elimina muchos cuellos de botella que un hosting de bajo costo suele normalizar.
Antes de contratar, confirme qué incluye el nuevo servicio: espacio y tipo de almacenamiento, límites de CPU y memoria, política de respaldos, certificado SSL, protección de correo, panel de control, soporte y condiciones reales de uptime. Para una web institucional pequeña, un hosting WordPress administrado puede ser suficiente. Para una tienda con alto tráfico, integraciones o procesos críticos, conviene evaluar un entorno semi dedicado, VPS o servidor dedicado.
Guía migración hosting WordPress paso a paso
La migración debe ejecutarse como un cambio controlado. La regla central es simple: no modifique DNS ni cancele el servicio anterior hasta que el nuevo entorno haya sido probado por completo.
1. Levante un inventario antes de mover datos
Comience identificando qué depende del hosting actual. Registre el dominio, sus zonas DNS, las cuentas de correo, los subdominios, certificados SSL, redirecciones, tareas programadas, versiones de PHP, configuraciones de caché y accesos administrativos.
En WordPress, anote los plugins activos, el tema en uso, las integraciones con medios de pago, formularios, servicios de analítica, SMTP y herramientas externas. Si el sitio utiliza WooCommerce, revise además los webhooks, pasarelas de pago, correos transaccionales y métodos de despacho. Esta etapa evita descubrir una dependencia crítica después del cambio.
2. Cree respaldos verificables
Genere una copia completa de los archivos y otra de la base de datos. No asuma que el respaldo automático del proveedor está disponible, actualizado o que contiene todo lo necesario. Descargue una copia independiente y guárdela en una ubicación segura.
El respaldo debe incluir la carpeta de WordPress, especialmente `wp-content`, el archivo `wp-config.php`, archivos de configuración adicionales y la exportación completa de MySQL o MariaDB. Si maneja correo en el mismo servidor, respalde también los mensajes o planifique su migración por separado. El contenido de las cuentas de correo no se mueve automáticamente junto con WordPress.
Una copia sin validación no es un plan de contingencia. Compruebe que el archivo se descargó correctamente, que la base de datos puede abrirse y que dispone de credenciales para acceder al dominio, al hosting antiguo y al nuevo servidor.
3. Prepare el nuevo servidor
Configure la cuenta de hosting antes de trasladar el sitio. Cree el dominio o sitio en el panel, la base de datos y el usuario correspondiente. Verifique que la versión de PHP sea compatible con su instalación, y que existan extensiones habituales como cURL, mbstring, GD o Imagick, según lo que use su sitio.
Instale o active el certificado SSL y defina las políticas de seguridad necesarias. Si el nuevo proveedor ofrece firewall de aplicaciones web, escaneo de malware, respaldos automáticos y caché a nivel de servidor, revise cómo se administran. Estas capas mejoran la protección y velocidad, pero deben configurarse de acuerdo con el funcionamiento real de la web.
En Smart.cl, una migración bien atendida no se trata de mover archivos a ciegas: se revisa el escenario técnico para que la infraestructura elegida responda al nivel de exigencia del sitio.
4. Transfiera archivos y base de datos
Suba los archivos mediante el administrador de archivos o SFTP. Luego importe la base de datos en el nuevo servidor y actualice en `wp-config.php` el nombre de la base, usuario, contraseña y host si corresponde.
Si el dominio se mantiene igual, normalmente no tendrá que reemplazar URLs dentro de la base de datos. Aun así, revise si existen referencias absolutas al servidor antiguo, rutas personalizadas o configuraciones en plugins de caché. Si cambia el dominio, use una herramienta que respete los datos serializados de WordPress. Un reemplazo manual mal ejecutado puede romper widgets, ajustes de constructores visuales o configuraciones de plugins.
Ajuste permisos de archivos solo cuando sea necesario. Como referencia, directorios con 755 y archivos con 644 suelen ser adecuados, pero la configuración final depende del entorno. Evite permisos 777: no solucionan un problema de raíz y abren una brecha de seguridad innecesaria.
5. Pruebe el sitio antes de cambiar DNS
Este es el punto que separa una migración profesional de una apuesta. Acceda al sitio en el nuevo servidor mediante una URL temporal, vista previa del panel o modificación local del archivo hosts. Así podrá navegar el sitio nuevo sin dirigir todavía a los visitantes hacia él.
Pruebe la portada, páginas internas, imágenes, buscador, formularios, inicio de sesión, recuperación de contraseña, carga de archivos y enlaces permanentes. En una tienda online, simule una compra completa: producto, carrito, checkout, medios de pago, cálculo de despacho, emisión de correo y actualización de stock.
También revise la consola del navegador y los registros de error. Un sitio puede verse correcto y, al mismo tiempo, tener errores de PHP, recursos bloqueados por contenido mixto o fallas en solicitudes AJAX. Corregirlos antes del cambio evita interrupciones visibles para clientes y equipos internos.
6. Planifique DNS y correo sin improvisar
Cuando las pruebas estén aprobadas, actualice los registros DNS necesarios. Según el caso, puede cambiar los nameservers completos o modificar solo el registro A del sitio. La segunda alternativa puede ser más segura si el correo corporativo, verificaciones de servicios externos o subdominios se administran fuera del hosting.
Antes del cambio, reduzca el TTL con anticipación si tiene control de la zona DNS. Esto ayuda a que la propagación sea más rápida, aunque no elimina por completo los tiempos de caché de terceros. Durante algunas horas, parte de los usuarios puede seguir llegando al servidor anterior. Por eso ambos entornos deben mantenerse operativos durante la transición.
Si el correo usa Google Workspace, Microsoft 365 u otro proveedor externo, preserve sus registros MX, SPF, DKIM y DMARC. Si el correo vive en el hosting, cree las cuentas en el nuevo servidor y valide envío y recepción antes de modificar los registros. Perder esos valores puede afectar la entrega de mensajes justo cuando su empresa necesita comunicar normalidad.
7. Monitoree después del cambio
Tras apuntar el dominio, no dé la tarea por terminada. Revise el sitio desde distintas redes, confirme que el candado SSL aparece correctamente y supervise formularios, pedidos, correos y accesos al panel. Mantenga el hosting anterior activo por al menos 48 a 72 horas, o más si su operación genera contenido constantemente.
En sitios con formularios, comentarios, pedidos o reservas, considere una sincronización final de la base de datos justo antes del cambio de DNS. De lo contrario, los datos ingresados durante la ventana de transición podrían quedar en el servidor antiguo. En proyectos de alto tráfico, la migración debe hacerse en horario de menor actividad y con una ventana operativa definida.
Errores que provocan caídas evitables
El error más frecuente es cancelar el proveedor anterior antes de confirmar la propagación DNS y el funcionamiento del nuevo sitio. Le siguen omitir el respaldo propio, migrar sin probar, olvidar los registros de correo y cambiar demasiadas cosas al mismo tiempo, como hosting, dominio, tema y plugins.
También conviene evitar plugins de migración como única estrategia de respaldo. Son útiles para sitios simples, pero pueden fallar por límites de memoria, tamaño de archivos, configuraciones especiales o bases de datos grandes. En proyectos empresariales, una revisión técnica y un plan de reversión son más valiosos que una migración rápida sin control.
Una migración bien ejecutada no debería ser un período de incertidumbre para su empresa. Debe ser el momento en que su sitio pasa a una infraestructura capaz de responder con velocidad, estabilidad y soporte cuando realmente importa.




