Diagnose a WordPress migration: SQL, uploads and URLs

Your WordPress site opens on localhost, but an image retains an address another computer cannot visit. Before moving it, separate three pieces: the database, files and URLs describing where content lives. Copying SQL does not copy media; uploading files alone does not reconstruct the CMS rows.

This guide uses an original MIT example rehearsing two synthetic WordPress core installations in a disposable environment. It checks SQL, a generated PNG, serialized URLs and restoration. This is a generic diagnostic, not a Sites panel recipe or a migration performed for a customer.

Separate a localhost problem from reliable instructions

An original question about localhost image addresses asks about images when accessing a local website elsewhere. It demonstrates an individual problem, not the correctness of its replies: a suggested SQL replacement of GUID is not adopted here.

Inventory the database, wp-content/uploads, themes, plugins and configuration before changing the destination. The official migration documentation helps distinguish files from data. The example rehearses only core and synthetic media, not your themes, blocks, plugins or shop.

First decide whether the URL actually changes

Moving an installation does not always require replacing URLs. If the public URL stays exactly the same, do not add a replacement merely because the server changes. If the scheme, hostname, port or path prefix changes, identify affected references and rehearse on a copy.

The resource changes http://source.invalid:8080 to http://destination.invalid:8081. These are fictional addresses within one Pod, not public domains. It uses WP-CLI search-replace, running --dry-run before applying and --skip-columns=guid: GUIDs remain unchanged. Do not adopt a blanket SQL substitution or rewrite GUIDs to fix images.

The official search-replace documentation explains serialized-data handling. Replacing text without respecting that structure can invalidate data. The example checks a nested option containing a URL and Unicode, plus the content link, after replacement.

What the completed rehearsal checks

The historical evidence contains eleven checks and comes from thirteen retained trials; that number does not mean thirteen successful runs. The final execution passed with WordPress 7.1.3, PHP 8.3.35 and WP-CLI 2.12.0, using digest-pinned images. The README and REHEARSAL-EVIDENCE.json distinguish executed code from later documentation updates.

The destination has its own database and user. SQL and uploads are exported, their hashes checked and both restored. Dry-run preserves original values; after applying, IDs, types, slugs, GUIDs and a defined logical projection are compared, along with the serialized option and PNG hash. These checks do not certify every possible datum in any WordPress installation.

Negative controls reject invalid SQL, missing media, an unreplaced URL and a corrupt file. The importer also detects SQL errors even when WP-CLI reports success; that message does not replace checking the data. After repairing the media, HTTP checks the post, page, PNG, 404, administrator access and logout. No Chrome rendering or mobile screen was tested.

Rollback restores the original SQL and uploads into the synthetic destination and removes an extra test file. It also checks that the source remains unchanged. This restores that copy; it is not DNS rollback, universal recovery or a zero-loss guarantee.

Read the harness before running it

This is an advanced resource: the WordPress rehearsal requires Kubernetes. You can inspect the code and run preparation checks from the pinned revision:

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

Four Python tests check the preparation contract and reject network, volume or token changes. The shell check validates syntax only. Neither executes WordPress or guarantees a successful migration. prepare.py generates manifests; it does not apply resources automatically. Execution requires an appropriate namespace and new resources you own, compatible images and environment review.

The rehearsal used loopback only and configured a deny NetworkPolicy, but did not measure effective CNI enforcement. Do not reuse this harness on a real database or interpret its local TLS exception as remote database instructions.

Before considering Sites

Confirm PHP, database access, file access, available capacity and the specific migration scope before purchasing or creating a site. This diagnostic does not prove a panel restore, remote TLS, public DNS or HTTPS, mail, WooCommerce, multisite or continuity of writes. Retain a recoverable copy and verify your installation separately; changing hosting does not turn a synthetic result into proven delivery.