Cómo migrar un sitio web con WP-CLI

Si estás administrando un sitio grande de WordPress y necesitas moverlo a un nuevo host, WP-CLI te ofrece una ruta más rápida y programable.

No te dará tiempos de espera de PHP en bases de datos grandes. Además, tendrás un proceso que puedes repetir o automatizar en varios sitios.

En este tutorial, te mostraré cómo migrar un sitio de WordPress usando WP-CLI. Al final, tu sitio estará funcionando en el nuevo servidor y habrás confirmado que funciona antes de que un solo visitante acceda al nuevo host.

Aquí están los puntos clave:

• La migración con WP-CLI es más rápida que la migración basada en plugins para sitios grandes, pero requiere acceso SSH en ambos servidores y WP-CLI instalado en cada uno.
• La opción --precise en wp search-replace es el comando más importante de este tutorial. Sin ella, los datos serializados se corrompen silenciosamente y la configuración del tema, los widgets y las opciones de los plugins se restablecen sin ningún mensaje de error.
• Copiar wp-config.php del servidor antiguo al nuevo trae consigo las credenciales de base de datos incorrectas. Debes actualizar DB_NAME, DB_USER, DB_PASSWORD y DB_HOST en el nuevo servidor antes de importar.
• Nunca cambies el DNS antes de verificar que la migración funcionó. El paso 7 cubre una lista de verificación previa al DNS usando wp option get, wp core verify-checksums y una vista previa del archivo hosts.
• wp duplicator build crea una copia de seguridad completa del sitio desde la terminal antes de que comiences. Si algo falla a mitad de la migración, la URL de recuperación de desastres de Duplicator restaura el sitio original sin SSH en el servidor antiguo.
• Si estás migrando a un nuevo dominio, incluye --skip-columns=guid en tu comando search-replace. Reemplazar los GUIDs rompe las suscripciones RSS.

Tabla de Contenidos

Cuándo usar WP-CLI para migrar un sitio de WordPress

WP-CLI no es la herramienta adecuada para todas las migraciones. Aquí te explicamos cuándo tiene sentido optar por la línea de comandos (y cuándo otro enfoque encaja mejor).

Usa WP-CLI cuando:

• Tu sitio es lo suficientemente grande como para que las herramientas basadas en navegador alcancen tiempos de espera de PHP o límites de memoria a mitad de la transferencia
• Tu host no te proporciona suficiente espacio en disco temporal para crear una copia de seguridad completa a través del navegador
• Estás migrando varios sitios y deseas un proceso repetible y programable. wp duplicator build dentro de un script de bash maneja copias de seguridad por lotes sin ningún trabajo manual
• Deseas control total sobre cada paso: qué se transfiere, qué se reemplaza y qué se verifica antes de los cambios de DNS

Considere un plugin de migración en su lugar cuando:

• No tenga acceso SSH en el servidor de origen o destino
• No se sienta cómodo con la línea de comandos
• Desea un proceso visual guiado con indicadores de progreso y reversión integrados

Cuál utilice depende de su configuración y preferencia.

Lo que necesitas antes de empezar

Tenga todo esto listo antes de ejecutar un solo comando. Si le falta algo a mitad de la migración (especialmente credenciales de base de datos o rutas de archivos), terminará con una base de datos medio importada y un sitio caído en ambos servidores.

• Acceso SSH a ambos servidores. Necesitará ejecutar comandos en el servidor antiguo y en el nuevo en diferentes momentos de este proceso.
• WP-CLI instalado en ambos servidores. Si aún no está instalado, siga la guía de instalación oficial. Lo necesitará en el servidor nuevo para los pasos de verificación en el Paso 7, no solo en el servidor antiguo.
• Duplicator Pro instalado y activo en el servidor antiguo. Este plugin de copia de seguridad/migración tiene los comandos wp duplicator build, wp duplicator info y wp duplicator cleanup.
• Una nueva base de datos ya creada en el servidor nuevo con un usuario que tenga privilegios completos. wp db import no crea la base de datos por usted; si no existe, la importación falla.
• Sus credenciales de base de datos del servidor nuevo listas: DB_NAME, DB_USER, DB_PASSWORD y DB_HOST. Las necesitará en el Paso 4.
• Las rutas de archivo absolutas para ambas instalaciones de WordPress. Ejecute pwd dentro de cada directorio raíz de WordPress y copie la salida en algún lugar útil.
• Si va a cambiar de dominio: su URL antigua y su URL nueva listas para copiar/pegar exactamente como aparecen en la base de datos, incluido el protocolo (https:// frente a http://).

Cómo migrar un sitio de WordPress con WP-CLI

Esto es lo que hará. Cada paso se basa directamente en el anterior, así que trabaje en orden.

• Paso 1: Ejecute una comprobación previa y cree una copia de seguridad completa con wp duplicator info y wp duplicator build
• Paso 2: Exporte la base de datos del servidor antiguo usando wp db export
• Paso 3: Transfiera los archivos de WordPress y la base de datos al servidor nuevo usando rsync y scp
• Paso 4: Actualice wp-config.php en el servidor nuevo con sus nuevas credenciales de base de datos
• Paso 5: Restablezca e importe la base de datos en el servidor nuevo usando wp db reset y wp db import
• Paso 6: Ejecute búsqueda-reemplazo para actualizar las URL usando wp search-replace (solo cambios de dominio)
• Paso 7: Vacíe la caché y verifique la migración antes de tocar DNS
• Paso 8: Actualice DNS y ponga en marcha
• Paso 9: Limpie el servidor antiguo con wp duplicator cleanup

Paso 1: Haz una copia de seguridad del sitio original

Antes de exportar nada, necesita un punto de restauración limpio en el servidor original. Si algo sale mal a mitad de la migración, querrá poder volver a un sitio que funcione sin prisas.

Utilizo Duplicator para la protección de copias de seguridad de WordPress. Es un plugin de copia de seguridad y migración utilizado por más de 1.5 millones de profesionales de WordPress y tiene comandos WP-CLI integrados.

Eso significa que puedes crear una copia de seguridad completa del sitio sin salir de la terminal. Para un flujo de trabajo de línea de comandos, eso importa.

Comienza verificando que la configuración de copia de seguridad de Duplicator esté funcionando correctamente. Inicia sesión por SSH en el servidor antiguo, navega a la raíz de tu WordPress y ejecuta:

wp duplicator info

Una vez que esto regrese limpio, crea tu copia de seguridad:

wp duplicator build

Esto crea una copia de seguridad completa de tu sitio desde la terminal.

Si deseas guardar la copia de seguridad en una ubicación específica en lugar de la predeterminada, usa:

wp duplicator build --dir=/path/to/backup/location

Ejecuta wp duplicator build --help para ver todas las opciones disponibles, incluyendo --template=<ID> para plantillas de copia de seguridad predefinidas y opciones de motor de archivo como --phpsqldump, --phpzip y --duparchive.

Si esta migración rompe algo, la URL de recuperación de desastres de Duplicator puede restaurar tu sitio incluso si WordPress está completamente bloqueado en el servidor antiguo. Esa es tu red de seguridad antes de tocar cualquier otra cosa.

Paso 2: Exporta la base de datos del servidor antiguo

Aún en el servidor antiguo, navega a la raíz de tu WordPress y exporta la base de datos:

wp db export site-backup.sql

Cuando termine, verás: Éxito: Exportado a 'site-backup.sql'.

El archivo se guarda en tu directorio actual. Anota dónde está, ya que lo transferirás en el siguiente paso.

Una cosa que hacer antes de continuar. Si tu archivo .sql termina dentro de un directorio accesible desde la web como /public_html o /htdocs, muévelo o elimínalo inmediatamente después de la transferencia.

Un archivo .sql expuesto es una copia completa de tu base de datos, incluyendo nombres de usuario, contraseñas hasheadas y cada pieza de contenido del sitio. No es un riesgo teórico.

Si estás migrando una red de WordPress Multisite, añade --all-tables para capturar datos de toda la red:

wp db export site-backup.sql --all-tables

Paso 3: Transfiere los archivos de WordPress y la base de datos al nuevo servidor

Dos cosas necesitan moverse al nuevo servidor: los archivos de WordPress y la exportación .sql que acabas de crear.

Para los archivos, usa rsync. Maneja transferencias grandes bien, muestra el progreso y reanuda donde lo dejó si la conexión se interrumpe:

rsync -avz --progress /path/to/old-wordpress/ user@newserver:/path/to/new-wordpress/

Con la barra, rsync copia el contenido del directorio. Sin ella, rsync copia el directorio en sí, lo que pone tus archivos un nivel más profundo de lo esperado en el nuevo servidor.

Ejecuta primero una simulación para verificar qué se transferirá antes de confirmar:

rsync -avz --progress --dry-run /path/to/old-wordpress/ user@newserver:/path/to/new-wordpress/

Para el archivo de la base de datos, usa scp:

scp site-backup.sql user@newserver:/path/to/new-wordpress/

Si prefieres comprimir todo en un solo archivo primero, eso también funciona:

tar -czf site_files.tar.gz .
scp site_backup.sql site_files.tar.gz user@newserver:/path/to/new-wordpress/

Luego extrae en el nuevo servidor:

tar -xzf site_files.tar.gz

Este enfoque funciona bien para sitios más pequeños o hosts que manejan transferencias de un solo archivo de manera más confiable que las conexiones rsync.

Paso 4: Actualiza wp-config.php en el nuevo servidor

Este es el paso que la mayoría de los tutoriales de migración de WP-CLI omiten, y es la razón más común por la que una migración falla inmediatamente después de la importación.

Cuando transferiste tus archivos de WordPress en el último paso, wp-config.php vino con ellos. Ese es el archivo correcto, pero todavía tiene las credenciales de la base de datos de tu servidor antiguo. Si ejecutas la importación ahora, WP-CLI intentará conectarse a una base de datos que no existe en el nuevo servidor.

Inicia sesi ilde{n}n por SSH en el nuevo servidor, navega hasta la ra ilde{i}z de tu WordPress y abre wp-config.php:

nano /path/to/new-wordpress/wp-config.php

Actualiza estos cuatro valores con los detalles de la base de datos de tu nuevo servidor:

• DB_NAME: el nombre de la base de datos que creaste en el nuevo servidor
• DB_USER: el nombre de usuario de la base de datos
• DB_PASSWORD: la contrase ilde{n}a de la base de datos
• DB_HOST: normalmente es localhost, pero cons ilde{u}ltalo con tu proveedor. Algunos proveedores de hosting gestionado utilizan un valor diferente aqu ilde{i}.

Guarda y sal. En nano, pulsa Ctrl+O para guardar y Ctrl+X para salir.

No olvides este paso. Si las credenciales son incorrectas, wp db import se conectar ilde{a} a la base de datos equivocada o fallar ilde{a} con "Error establishing a database connection", y no siempre ser ilde{a} obvio que wp-config.php es la causa.

Paso 5: Restablece e importa la base de datos en el nuevo servidor

Inicia sesi ilde{n}n por SSH en el nuevo servidor y navega hasta la ra ilde{i}z de tu WordPress. Si tienes una instalaci ilde{o}n nueva de WordPress en el nuevo servidor, elimina sus tablas predeterminadas antes de importar. Omitir este paso puede causar conflictos entre las tablas existentes y las de tu exportaci ilde{o}n.

wp db reset --yes

Ver ilde{a}s: Success: Database reset.

La opci ilde{o}n --yes omite la solicitud de confirmaci ilde{o}n. Sin ella, WP-CLI te pedir ilde{a} que confirmes antes de eliminar todas las tablas.

Ahora importa la base de datos:

wp db import site-backup.sql

Tan pronto como se confirme la importaci ilde{o}n, elimina el archivo SQL:

rm site-backup.sql

Luego, vuelve a iniciar sesi ilde{n}n por SSH en el servidor antiguo y elim ilde{i}nalo tambi ilde{e}n all ilde{i}.

Esto no es una tarea de limpieza opcional. Un archivo .sql en un directorio accesible por la web es una copia completa de tu base de datos. Elim ilde{i}nalo de ambos servidores antes de hacer nada m ilde{a}s.

Paso 6: Ejecuta Search-Replace para actualizar las URL

Si vas a conservar el mismo dominio y solo vas a cambiar de servidor, omite este paso y ve directamente al Paso 7. Tus URL ya son correctas en la base de datos.

Si vas a cambiar de dominio, aqu ilde{i} es donde la mayor ilde{i}a de las migraciones fallan silenciosamente. No con un error, sino con configuraciones de tema que se ven mal, widgets que desaparecieron y opciones de complementos que volvieron a los valores predeterminados. La causa es casi siempre la misma: una b ilde{u}squeda-reemplazo que no manej ilde{o} correctamente los datos serializados.

Antes de ejecutar nada, haz una prueba:

wp search-replace 'https://olddomain.com' 'https://newdomain.com' --all-tables --precise --dry-run

Esto ejecuta la operaci ilde{o}n completa y te muestra una tabla de cu ilde{a}ntos reemplazos se har ilde{i}an por tabla de base de datos, sin guardar ning ilde{u}n cambio. Rev ilde{i}sala.

Busca tablas en las que esperar ilde{i}as reemplazos (wp_options, wp_posts, wp_postmeta) y aseg ilde{u}rate de que los recuentos parezcan razonables. Los ceros inesperados en esas tablas merecen ser investigados antes de que te comprometas.

Cuando est ilde{e}s satisfecho, ejec ilde{u}talo sin --dry-run:

wp search-replace 'https://olddomain.com' 'https://newdomain.com' --all-tables --precise

Por qu ilde{e} --precise importa: WordPress almacena algunos datos como PHP serializado. La configuraci ilde{o}n del personalizador de temas, las configuraciones de widgets, las opciones de complementos, no se almacenan como texto plano. Se almacenan como cadenas PHP estructuradas que incluyen recuentos de caracteres.

Una b ilde{u}squeda-reemplazo est ilde{a}ndar basada en SQL intercambia la cadena de la URL pero no recalcula esos recuentos de caracteres. PHP lee el recuento, encuentra una discrepancia y descarta silenciosamente los datos.

Tu tema se reinicia. Tus widgets desaparecen. Nada genera un error: el sitio simplemente se ve mal.

La opción --precise fuerza a WP-CLI a usar PHP en lugar de SQL. Deserializa cada valor, realiza la sustitución, recalcula el recuento de caracteres y vuelve a serializar el resultado correctamente. Es más lento en bases de datos grandes. Úsalo de todos modos.

Una cosa que wp search-replace omite correctamente por defecto: la columna guid en wp_posts. No intentes forzar la sustitución de GUIDs.

La documentación de WordPress establece explícitamente que los GUID deben permanecer constantes. Identifican las publicaciones para los lectores de feeds, y cambiarlos rompe las suscripciones RSS.

Si estás migrando una red Multisite, añade la opción –network:

wp search-replace 'https://olddomain.com' 'https://newdomain.com' --all-tables --precise --network

La documentación oficial de WordPress describe un orden diferente: actualiza tus URLs en Ajustes » Generales en el servidor antiguo antes de migrar, luego exporta la base de datos ya actualizada y omite el paso de buscar y reemplazar en el nuevo servidor por completo. Funciona. El enfoque de este tutorial (migrar primero, buscar y reemplazar después) es más fácil de verificar porque puedes ejecutar una simulación antes de confirmar cualquier cambio de URL.

Paso 7: Limpia la caché y verifica antes de tocar el DNS

Una vez que se ha realizado la búsqueda y el reemplazo, es tentador ir directamente al DNS. No lo hagas.

Cambiar el DNS antes de haber confirmado que el sitio funciona significa que cualquier problema que encuentres serán problemas en vivo, visibles para los visitantes reales. Tómate diez minutos aquí y verifica todo en el nuevo servidor primero.

Empieza vaciando la caché de objetos:

wp cache flush

Luego vacía las reglas de reescritura:

wp rewrite flush

Ahora verifica que las URLs en la base de datos son correctas. Ejecuta ambas:

wp option get siteurl
wp option get home

Ambas deberían devolver tu dominio correcto. Si alguna devuelve el dominio antiguo, puedes actualizarlas manualmente:

wp option update siteurl 'https://newdomain.com'

wp option update home 'https://newdomain.com'

A continuación, verifica que tus archivos principales de WordPress se transfirieron sin corrupción:

wp core verify-checksums

Si devuelve errores, anota qué archivos están marcados. Un puñado de archivos modificados en wp-content es esperado y no es un problema; esos son tus archivos de tema y plugin, que no forman parte de la comparación de checksum. Los errores en archivos principales en wp-admin o wp-includes merecen ser investigados.

Previsualiza el sitio antes de actualizar el DNS. Añade una línea temporal al archivo hosts de tu máquina local apuntando tu dominio a la dirección IP del nuevo servidor. En Mac o Linux, abre /etc/hosts en un editor de texto y añade:

123.456.789.0 yourdomain.com

Reemplaza 123.456.789.0 con la IP de tu nuevo servidor. Guarda el archivo, luego abre tu dominio en un navegador. Ahora estás viendo el nuevo servidor mientras que todos los demás siguen accediendo al antiguo.

Comprueba cada uno de estos antes de continuar:

• La página de inicio carga correctamente
• El inicio de sesión de administrador funciona en /wp-admin
• Las imágenes se muestran en las publicaciones y páginas
• Los menús de navegación están intactos
• Los widgets aparecen correctamente en la barra lateral o el pie de página
• La apariencia del tema coincide con la original

Cuando todo esté correcto, elimina la línea que añadiste a tu archivo hosts. Entonces, estarás listo para una actualización del DNS.

Paso 8: Actualiza el DNS y sal en vivo

Apunta el registro A de tu dominio a la dirección IP de tu nuevo servidor. Dónde hagas esto depende de dónde apunten los servidores de nombres de tu dominio: ya sea tu registrador de dominios o el gestor de DNS de tu proveedor de hosting.

Inicia sesión, encuentra el registro A para tu dominio y actualiza la IP.

La propagación de DNS tarda entre unos minutos y 48 horas, dependiendo de tu registrador y la configuración TTL (tiempo de vida) de tu dominio. Durante ese período, algunos visitantes accederán al servidor antiguo y otros al nuevo. Eso es normal. No es señal de que algo se haya roto.

Mantén el servidor antiguo en funcionamiento durante al menos 24-48 horas después de actualizar el DNS. Apagarlo durante la propagación significa que algunos visitantes no encontrarán nada.

Una vez que estés seguro de que la propagación se ha completado, realiza un último vaciado de caché en el servidor nuevo:

wp cache flush

Paso 9: Limpia con wp duplicator cleanup

Una vez confirmado que el servidor nuevo está activo y estable, vuelve al servidor antiguo y ejecuta:

wp duplicator cleanup

Esto elimina los archivos de copia de seguridad y cualquier dato temporal que Duplicator haya creado durante el proceso de compilación en el Paso 1. Mantiene el servidor antiguo ordenado y elimina cualquier artefacto de migración antes de que lo desmanteles.

Ejecuta esto solo después de estar seguro de que la migración está completa. Una vez que los archivos de copia de seguridad hayan desaparecido, la opción de recuperación ante desastres del Paso 1 también lo hará.

Si deseas conservar la copia de seguridad como archivo a largo plazo, múévela a almacenamiento remoto antes de ejecutar la limpieza.

Solución de problemas comunes de errores de migración de WP-CLI

Incluso una migración cuidadosa puede encontrar obstáculos. Aquí están los puntos de fallo más comunes, cómo se manifiestan y cómo solucionarlos.

“Error al establecer una conexión con la base de datos” después de la importación

Lo que ves: WordPress muestra una pantalla en blanco o el mensaje “Error al establecer una conexión con la base de datos” en el servidor nuevo inmediatamente después de la importación.

Por qué sucede: wp-config.php todavía tiene las credenciales de la base de datos del servidor antiguo. Este es el error más común en una migración con WP-CLI y es fácil de pasar por alto si transferiste archivos antes de actualizar la configuración.

Cómo solucionarlo: Abre wp-config.php en el servidor nuevo y actualiza DB_NAME, DB_USER, DB_PASSWORD y DB_HOST para que coincidan con la base de datos de tu servidor nuevo. Guarda el archivo y recarga el sitio.

Configuración del tema, widgets u opciones de plugins restablecidos después de la migración

Lo que ves: El sitio carga, pero el tema se ve mal, faltan widgets o la configuración de los plugins ha vuelto a los valores predeterminados. No hay mensajes de error en ninguna parte.

Por qué sucede: Ejecutaste wp search-replace sin la opción --precise. El reemplazo de URL corrompió los datos serializados en la base de datos, y WordPress descartó silenciosamente los valores rotos.

Cómo solucionarlo: Vuelve a ejecutar search-replace con --precise y --all-tables:

wp search-replace 'https://olddomain.com' 'https://newdomain.com' --all-tables --precise

Si los datos ya están gravemente corruptos y volver a ejecutar search-replace no restaura la configuración, restaura la copia de seguridad de Duplicator que creaste en el Paso 1 y repite la migración.

“wp: command not found” en el servidor nuevo

Lo que ves: Cualquier comando de WP-CLI en el servidor nuevo devuelve wp: command not found o command not found: wp.

Por qué sucede: WP-CLI no está instalado en el servidor nuevo, o está instalado pero no en tu PATH.

Cómo solucionarlo: Instala WP-CLI en el nuevo servidor. Si no tienes permiso para hacer que el archivo sea ejecutable en tu host, puedes ejecutar comandos usando php wp-cli.phar en lugar de wp.

rsync Sale con "Permiso denegado"

Lo que ves: rsync se ejecuta pero sale prematuramente con uno o más errores de "Permiso denegado" en archivos o directorios específicos.

Por qué sucede: O tu clave SSH no está configurada correctamente para el servidor de destino, o hay una discrepancia en la propiedad de los archivos entre los dos servidores.

Cómo solucionarlo: Verifica primero el acceso a la clave SSH con ssh user@newserver. Si eso falla, soluciona la autenticación de la clave antes de reintentar rsync. Si la conexión funciona pero se deniegan archivos específicos, es posible que necesites usar chown en los archivos transferidos en el nuevo servidor para que coincidan con el usuario web que usa tu host, comúnmente www-data en Ubuntu o el nombre de usuario de la cuenta en hosts cPanel.

El sitio carga pero las imágenes están rotas

Lo que ves: Las páginas cargan correctamente, pero las imágenes muestran iconos de imagen rota en todo el sitio.

Por qué sucede: O la carpeta wp-content/uploads no se transfirió completamente, o las URL de imágenes codificadas en el contenido de las publicaciones no fueron capturadas por search-replace.

Cómo solucionarlo: Vuelve a ejecutar rsync apuntando solo a la carpeta de subidas para capturar cualquier archivo que no se haya transferido:

rsync -avz --progress /path/to/old-wordpress/wp-content/uploads/ user@newserver:/path/to/new-wordpress/wp-content/uploads/

Luego, vuelve a ejecutar search-replace con --dry-run para comprobar si alguna URL de imagen todavía hace referencia al dominio anterior.

Nada funciona: Restaura y empieza de nuevo

Si el sitio está completamente roto y no puedes identificar una causa clara, no pases horas depurando un estado de migración a medias. Restaura la copia de seguridad de Duplicator Pro que creaste en el Paso 1.

La URL de recuperación ante desastres de Duplicator puede restaurar el sitio anterior incluso si WordPress está bloqueado.

Una vez que vuelvas a un estado limpio y funcional, repite los pasos lentamente. Usa –dry-run en rsync y wp search-replace antes de confirmar nada, y comprueba las credenciales de wp-config.php antes de ejecutar la importación.

Preguntas Frecuentes (FAQs)

Tu sitio está en el nuevo servidor. Esto es lo que debes vigilar a continuación.

Has exportado la base de datos, transferido los archivos, actualizado wp-config.php, importado, ejecutado una búsqueda y reemplazo, verificado todo en el nuevo servidor y cambiado el DNS. Esa es la migración completa.

Las primeras 48 horas merecen atención. La propagación del DNS significa que algunos visitantes seguirán accediendo al servidor antiguo durante ese período, así que no lo desactives todavía.

Vigila las capas de caché que puedan estar sirviendo contenido obsoleto. Un vaciado completo de la caché en el nuevo servidor una vez confirmada la propagación tarda diez segundos y descarta muchos problemas de visualización.

Si algo todavía parece incorrecto después de que la propagación se haya completado, usa wp search-replace --dry-run como herramienta de diagnóstico antes de tocar nada:

wp search-replace 'https://olddomain.com' 'https://newdomain.com' --all-tables --precise --dry-run

Esto te muestra qué tablas todavía contienen el dominio antiguo sin realizar ningún cambio. Es la forma más rápida de confirmar si una URL persistente es un error de búsqueda y reemplazo o algo codificado directamente en un archivo de tema.

Las URL codificadas directamente en archivos de tema personalizados no serán detectadas por la búsqueda y reemplazo en absoluto. Necesitarás encontrarlas y actualizarlas manualmente en el código del tema.

Migra con confianza usando Duplicator Pro

Una migración sin copia de seguridad es una apuesta. Los servidores se comportan de forma inesperada, las importaciones se interrumpen y los datos serializados no siempre sobreviven a una búsqueda y reemplazo de forma limpia.

Tener un punto de restauración antes de empezar significa que cualquiera de esas situaciones es un contratiempo menor en lugar de un problema grave.

Duplicator Pro hace la copia de seguridad con un solo comando desde la terminal: wp duplicator build. Y si algo sale mal, la URL de recuperación ante desastres recupera tu sitio original incluso si WordPress está completamente bloqueado.

Más de 1.5 millones de profesionales de WordPress usan Duplicator Pro para hacer copias de seguridad, migrar y clonar sus sitios. ¡Únete a ellos!

Si este tutorial te ha sido útil, estas guías también merecen ser marcadas.

• Cómo mover un sitio web de WordPress a un nuevo host
• Por qué no puedes iniciar sesión en WordPress después de una migración
• Migración de DNS hecha correctamente: Cómo evitar los errores más comunes
• La lista de verificación completa de pruebas de WordPress post-migración
• Cómo auditar contenido antes de una migración de sitio web
• Cómo migrar un sitio de WordPress GRATIS