Diagnosticar una migración WordPress: SQL, uploads y URLs

Tu WordPress abre en localhost, pero una imagen conserva una dirección que otro equipo no puede visitar. Antes de moverlo, separa tres piezas: la base de datos, los archivos y las URLs que describen dónde vive el contenido. Copiar un SQL no copia los medios; subir archivos no reconstruye por sí solo las filas del CMS.

El ejemplo original MIT de esta guía ensaya dos instalaciones sintéticas de WordPress core en un entorno desechable. Comprueba SQL, un PNG generado, URLs serializadas y restauración. Es un diagnóstico genérico, no una receta del panel Sites ni una migración realizada para un cliente.

Distingue un problema de localhost de una receta fiable

Una pregunta original en español sobre rutas de imágenes muestra la dificultad de pasar una web local a otra ubicación. Es un caso individual, no una prueba de frecuencia ni una validación de las respuestas del foro.

Inventaría la base de datos, wp-content/uploads, temas, plugins y configuración antes de tocar el destino. La documentación oficial de migración ayuda a separar archivos y datos. El ejemplo sólo ensaya core y medios sintéticos: no verifica tus temas, bloques, plugins o una tienda.

Decide primero si realmente cambia la URL

Mover una instalación no obliga siempre a sustituir URLs. Si la URL pública permanece exactamente igual, no añadas un reemplazo sólo por cambiar de servidor. Si cambian esquema, hostname, puerto o prefijo de ruta, identifica las referencias afectadas y ensaya el cambio sobre una copia.

En el recurso, http://source.invalid:8080 pasa a http://destination.invalid:8081. Son direcciones ficticias para un mismo Pod, no dominios públicos. La herramienta usa WP-CLI search-replace, con --dry-run antes de aplicar y --skip-columns=guid: conserva los GUID. No adoptes una sustitución SQL general ni reescribas GUID para arreglar imágenes.

La documentación oficial de search-replace describe el tratamiento de valores serializados. Cambiar texto sin respetar esa estructura puede dejar datos inválidos. Aquí se verifica una opción anidada con URL y Unicode, además del enlace del contenido, después del reemplazo.

Qué comprueba el ensayo terminado

La evidencia histórica contiene once comprobaciones y procede de trece ensayos conservados; ese total no significa trece éxitos. La ejecución final pasó con WordPress 7.1.3, PHP 8.3.35 y WP-CLI 2.12.0, usando imágenes fijadas por digest. El README y REHEARSAL-EVIDENCE.json distinguen el código ejecutado de sus actualizaciones documentales posteriores.

El destino tiene base y usuario propios. Se exportan SQL y uploads, se verifican sus hashes y se restauran juntos. El dry-run conserva los valores originales; tras aplicar, se comparan IDs, tipos, slugs, GUID y una proyección lógica definida, además de la opción serializada y el hash del PNG. Esas comprobaciones no certifican cada dato posible de cualquier WordPress.

Los negativos rechazan SQL inválido, medio ausente, URL sin reemplazar y archivo corrupto. El importador también detecta errores SQL aunque WP-CLI anuncie éxito; ese mensaje no sustituye comprobar los datos. Después de reparar el medio, HTTP comprueba artículo, página, PNG, 404, acceso al administrador y cierre de sesión. No se ensayó un render de Chrome ni una pantalla móvil.

La vuelta atrás restaura el SQL y los uploads originales del destino sintético y elimina un archivo extra de prueba. Comprueba también que la fuente no cambió. Es una restauración de esa copia, no un rollback de DNS, recuperación universal o garantía de pérdida cero.

Lee el harness antes de ejecutarlo

Este recurso es avanzado: necesita Kubernetes para el ensayo de WordPress. Puedes revisar su código y ejecutar las comprobaciones de preparación desde la revisión fijada:

git clone https://github.com/ocentelles/hostbrid-example-wordpress-migration.git
cd hostbrid-example-wordpress-migration
git checkout 17d66e5808498adc62a4cf8061cf8c49d4648792
python3 test-preparation.py
/bin/sh -n rehearse.sh

Los cuatro tests Python comprueban el contrato de preparación y rechazan cambios de red, volumen o token. La comprobación de shell sólo valida sintaxis. Ninguno ejecuta WordPress ni garantiza que una migración vaya a funcionar. prepare.py genera manifiestos; no aplica recursos automáticamente. Una ejecución requiere un namespace adecuado y recursos nuevos propios, imágenes compatibles y revisión del entorno.

El ensayo usó sólo loopback y configuró una NetworkPolicy de denegación, pero no midió que el CNI la hiciera efectiva. No reutilices este harness sobre una base real ni interpretes su excepción TLS local como instrucciones para una base remota.

Antes de valorar Sites

Confirma PHP, base de datos, acceso a archivos, capacidad disponible y alcance concreto de la migración antes de contratar o crear un sitio. Este diagnóstico no prueba restauración del panel, TLS remoto, DNS o HTTPS públicos, correo, WooCommerce, multisite ni continuidad de escrituras. Mantén una copia recuperable y verifica tu instalación aparte; cambiar de alojamiento no convierte el resultado sintético en una entrega probada.