Cómo migrar WordPress a otro hosting sin tiempo de inactividad

Migrar una web WordPress implica mucho más que copiar archivos e importar una base de datos. Un traslado bien planificado debe mantener el sitio accesible, proteger el HTTPS, conservar el correo, evitar pérdidas de datos y respetar la configuración SEO. En este contexto, “sin tiempo de inactividad” significa mantener operativos el servidor antiguo y el nuevo mientras el tráfico cambia de destino.

Antes de iniciar el proceso, confirma que el servidor de destino ofrece almacenamiento, memoria, versiones de PHP, extensiones y copias de seguridad adecuados. Conviene revisar estas necesidades al comparar paquetes de alojamiento web, especialmente si se trata de WooCommerce, una membresía o un portal con mucho contenido.

1. Audita la instalación actual

Documenta las versiones de WordPress y PHP, el tema, los plugins activos, las tareas programadas, el tamaño de la base de datos, el espacio utilizado, la zona DNS, el SSL y el proveedor de correo. Anota también integraciones con pagos, analítica, CDN, webhooks, APIs y servicios SMTP.

• Detecta plugins desactualizados o incompatibles.
• Guarda las reglas personalizadas de .htaccess, Nginx o el panel.
• Registra límites, extensiones y ajustes relevantes de PHP.
• Exporta la zona DNS y conserva una referencia de sus valores.
• Identifica datos dinámicos como pedidos, formularios, reservas y altas de usuarios.

Elige una franja con poca actividad, pero no presupongas que estará vacía. Las tiendas y plataformas con usuarios pueden necesitar un breve modo de mantenimiento o solo lectura para completar la sincronización final.

2. Crea copias verificadas y un plan de reversión

Realiza copias independientes de los archivos y la base de datos. No dependas únicamente de un plugin de migración ni de una copia guardada en el propio servidor de origen. Descarga los archivos a otra ubicación, comprueba su tamaño y verifica que el volcado SQL pueda abrirse y restaurarse.

Mantén activo el alojamiento anterior durante la propagación DNS. El plan de reversión debe indicar quién puede recuperar los registros previos, dónde está la copia validada y cómo se reconciliarán pedidos o cambios recibidos si fuera necesario volver al servidor antiguo.

3. Reduce el TTL de los registros DNS

El TTL determina cuánto tiempo puede permanecer un registro DNS en la caché de los resolutores. Reduce con antelación el TTL de los registros A y AAAA que vayas a modificar. Hacerlo justo antes del cambio no invalida los valores que ya estaban almacenados con el TTL anterior.

No cambies los registros MX, SPF, DKIM o DMARC solo porque se traslada la web. El alojamiento del sitio y el servicio de correo suelen ser independientes. Conserva todos los registros de correo salvo que exista un proyecto específico para migrar los buzones.

4. Copia y prueba WordPress en el nuevo servidor

Traslada el núcleo de WordPress, los medios, los temas y los plugins. Exporta la base de datos, impórtala en el destino y actualiza las credenciales de wp-config.php. Si no cambia el dominio, mantén las URL de producción configuradas en WordPress.

Prueba el destino antes de modificar el DNS público. Una entrada local en el archivo hosts permite asociar el dominio con la nueva IP solamente en tu equipo. Así puedes navegar con el nombre de dominio real mientras inspeccionas el nuevo servidor.

Pruebas recomendadas

• Portada, páginas clave, entradas, archivos, búsqueda y menús.
• Acceso administrativo, subida de medios y funciones de plugins.
• Formularios, mensajes transaccionales y autenticación SMTP.
• Carrito, pago, cuentas, impuestos y notificaciones de pasarelas.
• Redirecciones, URL canónicas, robots y sitemap XML.
• Diseño adaptable, caché, registros y cabeceras de seguridad.

Cuando el traslado también afecta a la arquitectura, las redes o el almacenamiento, una migración a la nube planificada ayuda a coordinar las dependencias de la aplicación y sus datos.

5. Configura y valida el certificado SSL

El destino debe servir un certificado válido para todos los nombres públicos, incluido el dominio raíz y la variante www si se utiliza. Según el proveedor, puede emitirse mediante validación DNS, validación temporal del tráfico o instalación manual de un certificado transferible.

Comprueba el HTTPS mediante la prueba con el archivo hosts. Revisa la cadena, la caducidad, los nombres cubiertos y la redirección de HTTP a HTTPS. Busca contenido mixto provocado por recursos con direcciones HTTP fijas. No es aconsejable activar HSTS por primera vez durante la migración, ya que los navegadores pueden conservar una política incorrecta.

6. Sincroniza los datos y cambia el DNS

Justo antes del cambio, activa un mantenimiento controlado o el modo de solo lectura en sitios con muchas actualizaciones. Ejecuta una última exportación e importación de la base de datos, sincroniza los archivos recientes, vacía las cachés y evita que las tareas programadas funcionen a la vez en ambos servidores.

Actualiza los registros A y AAAA necesarios. Si el proveedor obliga a cambiar los servidores de nombres, compara las dos zonas completas antes de hacerlo. Un registro ausente podría afectar al correo, los subdominios o los servicios de verificación. Siempre que sea posible, modificar solo los registros web resulta más fácil de controlar.

Durante la propagación, las visitas pueden llegar a cualquiera de los dos entornos. Mantén ambos operativos y no publiques contenidos diferentes en cada copia. Supervisa accesos, errores de aplicación, formularios, pedidos, disponibilidad y consumo de recursos.

7. Protege el correo electrónico

El correo puede verse afectado aunque los buzones no cambien de proveedor. Es posible que la nueva zona DNS esté incompleta o que los formularios comiencen a enviar mensajes desde una IP distinta.

Lista de comprobación del correo

• Conservar todos los MX y sus prioridades.
• Copiar el registro SPF completo sin publicar varios SPF para el mismo nombre.
• Mantener los selectores y claves públicas DKIM.
• Preservar la política DMARC y sus direcciones de informes.
• Verificar los CNAME de autoconfiguración, webmail y otros servicios.
• Autorizar el nuevo servicio de envío o configurar SMTP autenticado.
• Probar envíos y recepciones externos, revisando los resultados de autenticación.

No dependas únicamente de la función de correo de PHP para notificaciones importantes. Un SMTP autenticado o un proveedor transaccional suele ofrecer registros más claros y un mejor control sobre la identidad del remitente.

8. Revisa el sitio después de la migración

Busca enlaces rotos, imágenes ausentes, bucles de redirección y errores del servidor. Comprueba las herramientas para webmasters, la analítica, la caché, las tareas cron, las copias automáticas y la monitorización de seguridad. Las URL canónicas y el sitemap deben seguir usando el dominio HTTPS preferido.

No canceles inmediatamente el alojamiento de origen. Consérvalo hasta que las cachés DNS hayan caducado y el destino haya funcionado correctamente durante un ciclo normal de actividad. Después, crea un archivo final, revoca las credenciales antiguas y cierra el entorno de forma segura.

Conclusión práctica

Una migración WordPress de bajo riesgo exige seguir el orden correcto: auditoría, copias verificadas, TTL reducido, entorno de pruebas, SSL, sincronización, cambio limitado de DNS, conservación del correo y monitorización. Para revisar dependencias o coordinar un traslado delicado, puedes contactar con developer.ma antes de modificar el DNS de producción.