Lista de verificación de migración WordPress: mover archivos, datos y dominios de forma segura

Defina lo que se mueve y quién controla la reducción

Una migración WordPress mueve una aplicación existente y sus datos. Decide si sólo está cambiando el servidor de alojamiento, o también el dominio, la ruta URL o el esquema HTTPS. Escriba la configuración actual de WordPress y Site Address, conexión de base, ubicación de carga y cualquier enrutamiento personalizado. Un movimiento del servidor y un cambio de dominio requieren diferentes cheques.

Asignar una persona para aprobar la copia final y cambio DNS. Confirme que puede acceder a los archivos antiguos, exportar la base de datos, configurar el destino y editar los registros DNS pertinentes. Grabar los registros existentes antes de cambiarlos. Elegir un plan de hospedaje no transfiere su sitio web; organizar la migración con la persona responsable de su aplicación.

Crear una copia de seguridad de archivos y bases de datos

Guarde los archivos WordPress y una exportación de bases de datos como un conjunto de respaldo identificable. Incluya subidas, temas, plugins y la configuración necesaria para reconectar la aplicación. Descargar el directorio WordPress por sí solo no captura una base de datos almacenada en MySQL o MariaDB. Grabar cuando se tomó la exportación y retener una copia fuera del servidor que se reemplaza.

Compruebe el destino PHP versión, extensiones requeridas, compatibilidad de bases de datos y espacio para la aplicación restaurada y archivos temporales. Confirme que su respaldo puede ser abierto y restaurado en una base de datos separada. Tratar las credenciales en los archivos de configuración como secretos y eliminar archivos de exportación temporales de directorios accesibles al público una vez que su propósito esté completo.

Planifique y pruebe una restauración completa de alojamiento

Separar un movimiento de alojamiento de un cambio de URL

Cuando el dominio público y los caminos se mantienen iguales, las URL de aplicación existentes generalmente siguen siendo válidas. Actualizar la conexión de la base de datos de destino si su host, nombre de la base de datos o credenciales difieren. Prueba usando un método que preserva el nombre de host deseado, como una anfitriona local, donde tu operador lo soporta; esto cambia sólo el dispositivo de prueba, no público DNS.

Desplazar la tabla horizontalmente si es necesario.

Handle cambió URLs sin romper datos serializados

Temas y plugins pueden almacenar valores estructurados que contienen tanto texto como su longitud. Un reemplazo simple de texto SQL puede dañar los datos serializados cuando una URL vieja y nueva URL tienen diferentes longitudes. Utilice una herramienta de migración WordPress o un buscador WP-CLI si está disponible WP-CLI y revise su alcance antes de aplicar un cambio.

En una copia restaurada, ejecute primero una carrera seca, inspeccione las tablas reportadas y mantenga una exportación de rebote. WP-CLI proporciona --dry-run y --skip-columns=guid; WordPress post GUIDs identificar contenido y no debe ser reescrito como enlaces ordinarios. Un comando multisite necesita un alcance de red deliberado. Compruebe las tablas y la configuración de propiedad del plugin por separado en lugar de reemplazar cada cadena de coincidencia en cada base de datos.

Prueba el destino sin desencadenar efectos secundarios en vivo

Abra la página principal, un post, búsqueda, medios de comunicación, acceso y el área de administración en el destino. Chequea los permalinks, activos desaparecidos, HTTPS redirige y errores de aplicación. Probar formularios y almacenar flujos usando un ambiente de prueba adecuado. Mantenga una copia aislada del envío de mensajes de clientes reales, cargando pagos o disparando webhooks de producción durante el ensayo.

Para WooCommerce, verifique las variaciones de los productos, actualizaciones de la cesta, comportamiento de comprobación y la pantalla de administración de pedidos. Una carga de página exitosa es sólo una prueba. Compare el destino con una lista corta de funciones de negocio que utiliza y resuelva las diferencias antes de la copia final. Grabar cualquier configuración de aplicación cambiado para la prueba de modo que pueda ser revisado antes del lanzamiento.

Revisión WooCommerce hosting y configuración de tiendas

Protege pedidos y otros escritos durante la recortación DNS

Una tienda puede recibir nuevos pedidos después de la copia de seguridad del ensayo. Planifique una pausa controlada en los escritos o una sincronización final específica de la aplicación, a continuación, crear la copia final consistente. Compare los últimos registros de pedidos y los eventos de proveedores de pagos con el punto de corte aprobado. Restaurar una base de datos más antigua sobre los datos de las tiendas en vivo puede descartar transacciones que ocurrieron después.

Los caches DNS pueden enviar visitantes a diferentes destinos durante la transición. Decide qué aplicación es autorizada para pedidos y qué tan tarde se manejarán los escritos antes de cambiar los registros. Mantenga el entorno anterior disponible para la investigación sin reabrir casualmente dos tiendas. La guía DNS cubre cambios récord; la decisión de migración también necesita un propietario claro para los datos de la aplicación.

Compruebe los registros DNS antes de conectar el destino

Verifique el lanzamiento y defina un revolvente usable

Repita los controles funcionales a través de DNS público, inspeccione errores de aplicación y revise nuevos pedidos o presentaciones en el destino previsto. Si las URL cambian, prueba direcciones antiguas importantes y sus redirecciones. Compruebe la configuración de indexación, URL canónicas y la hoja de sitio para que una restricción de estadificación o nombre de host temporal no se lleve a la producción.

Establece las condiciones que justificarían la devolución. Para una tienda en vivo, revertir DNS por sí solo no mueve pedidos recién creados de vuelta a la vieja base de datos. Reconcile nuevos datos antes de volver al tráfico, y mantenga un registro de la decisión final de migración. Retire la antigua instalación sólo después del destino, copia de recuperación y registros de negocios han sido verificados.

• El conjunto de respaldo final y la base de datos de destino coinciden con la reducción aprobada.
• Las URL públicas, HTTPS, las formas y las funciones de almacén funcionan en el destino.
• En la solicitud prevista se registran nuevas órdenes y presentaciones.
• Se han revisado archivos temporales y ajustes de prueba únicamente.

Comparar los planes de destino WordPress