Los datos serializados de PHP guardan la longitud en bytes de cada cadena. Un buscar y reemplazar hecho a ciegas puede cambiar el texto sin actualizar esa longitud y dejar una opción o metadato completo ilegible.
Confirma que el problema es realmente la serialización
Busca avisos de unserialize(), widgets vacíos, ajustes de tema desaparecidos o layouts del maquetador que se hayan roto justo después de la sustitución. Compara una fila afectada con una copia anterior.
Restaura antes de repetir la migración
Si existe un backup fiable, recuperar las filas afectadas es más seguro que editar longitudes manualmente. Después repite la operación con una herramienta compatible con WordPress y con una prueba previa.
Define bien tablas y columnas
- limita la operación a las tablas necesarias;
- excluye GUIDs salvo que exista un motivo explícito;
- revisa JSON y URLs escapadas por separado;
- incluye tablas multisitio solo si forman parte de la migración.
Relaciona la reparación con el síntoma real
Si el objetivo era eliminar el host antiguo, revisa primero por qué WordPress puede seguir usando el dominio anterior. Corregir la base de datos no sustituye revisar redirecciones o caché.
No guardes repetidamente configuraciones rotas
Un plugin puede sustituir un valor todavía recuperable por un valor vacío. Conserva el estado hasta saber qué dato ha quedado afectado.
Validación
Los ajustes complejos deben coincidir con el estado anterior, los logs no deben mostrar errores de serialización y una prueba de sustitución solo debe detectar valores antiguos esperados. Si queda un problema de routing, consulta los 404 después de migrar.