The migrated site loads at its new domain, but images, menu links, and page-builder data still point to staging. A global replacement looks simple until the same hostname appears in GUIDs, backups, email addresses, multisite records, and third-party callbacks.
Map the old and new URLs, inspect where each match occurs, and use a serialization-aware preview before changing the database. Treat exceptions deliberately, then verify both the public site and connected services before retiring the old host.
What it means
A post-migration URL replacement updates internal references that still use the former scheme, hostname, or path. Those values may appear in post content, block markup, attachment metadata, options, widgets, menus, and plugin tables.
WordPress also stores structured values that a plain SQL replacement can corrupt when the string length changes. The goal is therefore to update confirmed site-owned references with a serialization-aware tool, not to replace every matching byte in the database.
- Record the exact old and new URLs, including scheme, subdomain, path, case, and trailing slash.
- Count matches by table and column, and identify which plugin or WordPress component owns them.
- Review GUIDs, email addresses, archives, license endpoints, webhooks, and historical text separately before excluding or changing them.
A realistic WordPress example
A store moves from staging.example.netto shop.example.com. A dry run finds the staging URL in block content, page-builder settings, attachment metadata, the homeand siteurloptions, old post GUIDs, and a webhook configured for a test service.
The team updates the site-owned content and settings but excludes GUID history and the external webhook until its owner approves a new endpoint. After the write, they open representative pages and editors, submit a form, test checkout and login, and check the old host logs for requests that still need attention.
Why it matters and when to use it
Run the replacement after the new files, database, domain, and TLS certificate are ready, but before the former environment is retired. Stale URLs can cause missing media, mixed-content warnings, broken canonical output, failed callbacks, and editor content that still depends on staging.
Do not start from an unexplained symptom or an incomplete domain map. Resolve multisite mappings, custom upload locations, callback ownership, and any certificate or redirect problems first. A database replacement should have one explicit old-to-new mapping and a defined set of exceptions.
A straightforward route for beginners
- Confirm that the new domain serves the correct site over HTTPS, then take a restorable database backup.
- Write down the exact old and new URL values and list any scheme, subdomain, path, or encoded variants.
- Run a serialization-aware preview against only the tables in scope.
- Inspect representative matches from each table and exclude GUIDs, external services, and historical text unless they genuinely need changing.
- Apply the approved replacement once, preferably during a quiet write window.
- Clear relevant caches and test public pages, media, editors, login, forms, scheduled jobs, and integrations.
Keep the old environment available until the remaining matches and requests are understood. A lower database count is useful evidence, but it is not proof that the migrated site works.
The advanced route
For a command-line migration, use a tool that understands PHP serialization and supports a dry run. Select the network or site scope explicitly, review table prefixes, and skip columns such as guidwhen the migration plan requires them to remain unchanged.
- Compare preview and write counts by table rather than relying on one total.
- Inspect serialized options, block markup, page-builder data, and plugin-owned custom tables separately.
- Crawl representative pages and assets, open the block and builder editors, and test webhooks, OAuth callbacks, forms, feeds, and scheduled tasks.
- Watch requests reaching the old host during a normal traffic and scheduled-job window; every unexplained dependency needs an owner.
On multisite, distinguish network domains from subsite domains and account for path-based and domain-based configurations. If the approved scope changes after the preview, run the preview again.
Risks, common mistakes, backup, and rollback
The most serious risks are corrupted serialized values and legitimate references changed simply because they contain the same text. Partial replacements can also leave the site split between old and new hosts, while a full database restore may overwrite orders or form entries created after the backup.
- Never run a raw global SQL replacement on serialized WordPress data.
- Avoid short search strings that can match unrelated domains, email addresses, or prose.
- Do not change GUIDs, signed callbacks, license servers, or third-party URLs without a specific reason.
- Stop if write counts differ unexpectedly from the preview or if editors, login, media, or integrations fail.
Preserve the preview report and database backup. If validation fails before new writes matter, restore the verified backup. Otherwise reverse only a fully documented change or reconcile the newer data before restoring.
How AIOWS helps:
AIOWS Replace Manager
AIOWS Replace Manager provides a preview-first way to review a migration URL change before writing it to the database. Start with a verified backup, the exact old and new values, and the approved tables, columns, and exclusions. Scheme, hostname, path, case, slash, and encoding all affect what the tool will match.
Run the preview and review counts by table. Inspect examples from ordinary text and serialized settings, confirm that each data family belongs to the site, and exclude historical or external references that should remain unchanged. Apply the replacement only when the preview matches the migration plan. Afterward, compare the write count with the preview, recount the old value, and test pages, media, editors, forms, login, and connected services.
Replace Manager cannot determine what every match means, make an untested backup restorable, preserve later transactions during a broad rollback, or repair data that was already corrupt. If the scope changes, preview again. If the result differs from the approved plan, stop further writes and either restore the verified database backup or reverse only changes that are completely documented and safe to undo. Record the values, scope, exclusions, counts, tests, and recovery decision with the migration notes.
Related AIOWS articles
- How to Replace HTTP URLs with HTTPS in WordPress
- WordPress Search and Replace Without Breaking Serialized Data
- How to Change a WordPress Domain in the Database
Conclusion and recommended route
Inventory matches by table, preview the exact URL change with serialization support, and review every exception before writing. Then recount the database and test real pages, editors, and integrations. Keep the former environment available until its remaining requests are understood and the migrated site has been accepted.
