If your old domain is still showing up somewhere on the site after an All-in-One WP Migration import — in image URLs, links inside post content, a theme's saved settings, or elsewhere — this is a known limitation of the plugin's built-in Find & Replace tool, not a failed import. The free version caps how many characters it will search-replace per field, and it can miss URLs saved in unusual places like theme option tables or serialized arrays with structures the tool doesn't fully parse. The fix is to first re-run Find & Replace correctly, then clean up whatever it missed with a serialization-safe WP-CLI search-replace.

Symptoms

  • Images or media files fail to load, and viewing the page source shows they're still pointing at the old domain.
  • Links inside post or page content go to the old URL instead of the new one.
  • Visual elements from a page builder or theme (background images, logo, custom CSS) reference the old domain and appear broken.
  • The site mostly works, but specific plugin or theme settings pages show broken previews or incorrect saved URLs.

Likely causes, in order of how often they actually happen

  1. The free version's Find & Replace has a per-field character limit. All-in-One WP Migration's free Find & Replace add-on is designed for straightforward URL swaps and imposes a length limit on what it will search and replace within a single field — long serialized strings (common in theme options, widget data, or page builder settings) can exceed this and get skipped silently.
  2. URLs are stored in serialized PHP arrays with an unusual structure. WordPress stores a lot of settings as serialized data, where each string's length is recorded as part of the data structure. A plain text search-replace that doesn't account for this can corrupt the serialization even when it does find a match — which is part of why the built-in tool and any manual approach need to be serialization-aware, not just a raw text swap.
  3. You ran the import before adding the Find & Replace values, or entered the old/new domain slightly wrong (with vs. without https://, with vs. without a trailing slash, or missing the www. variant) — the tool only replaces exact string matches, so a mismatch in format means it silently finds nothing.
  4. Hardcoded URLs outside the database — occasionally a theme or child theme has a domain hardcoded directly into a template file or a custom CSS file rather than stored in the database at all, which no database search-replace tool (built-in or WP-CLI) will touch.

Fix it: lowest-risk steps first

Step 1 — Re-run Find & Replace with the correct values and format

Before assuming the tool failed, confirm you gave it exactly what it needed.

  1. Go to All-in-One WP Migration → Import, or use the Find & Replace tool from the plugin's menu (available as part of the free plugin or its dedicated add-on, depending on your version).
  2. Enter the old domain exactly as it appeared in the source site's database — check the actual format by looking at a raw URL still showing on the site (include or exclude https:// and www. to match precisely what's broken).
  3. Enter the new domain in the same format.
  4. Run the replacement and check the affected pages again. If some URLs update but others don't, you've likely hit the character-limit issue on the fields that are still broken, and you can move to Step 2 for those.

Step 2 — Identify exactly what's still broken

  1. View the page source (right-click → View Page Source, or Ctrl+U) on a page showing the issue, and search for your old domain to see exactly which URLs weren't updated.
  2. Note whether these are inside post content, a widget, a theme option, or a plugin setting — this tells you which database table is still holding the old value, which helps confirm the fix worked afterward.

Step 3 — Run a serialization-safe WP-CLI search-replace for anything the plugin's tool missed

This is the most reliable fallback and handles the length and serialization issues the plugin's built-in tool can run into.

  1. Confirm you have WP-CLI access — via SSH if your host provides it, or through a hosting panel's built-in WP-CLI/terminal feature if SSH isn't available.
  2. Run a dry run first so nothing changes yet: 
    wp search-replace 'https://olddomain.com' 'https://newdomain.com' --dry-run --precise
  3. Review the dry-run output — it lists how many replacements it would make and in which tables, so you can sanity-check that it's finding the same URLs you spotted in Step 2.
  4. Run it for real, keeping the --precise flag: 
    wp search-replace 'https://olddomain.com' 'https://newdomain.com' --precise
    The --precise flag matters here: it makes WP-CLI check every row (rather than relying on a faster but less thorough matching method) and correctly re-serializes any PHP array or object data it modifies, so you don't end up with corrupted serialized strings the way a raw SQL UPDATE ... REPLACE() query can produce.
  5. If your old URLs appear in more than one format (with and without www., or http:// vs https://), run the command again for each variant.

Step 4 — Check for hardcoded URLs outside the database

If specific broken references remain after Step 3, they may not be in the database at all.

  1. Search the active theme's files (via FTP or your host's file manager) for the old domain — check functions.php, any custom CSS files, and template files for a hardcoded URL.
  2. Update these manually, and note them somewhere so you remember to check the same spots on future migrations.

Verify the fix

  1. View source on the pages that were previously broken and confirm no instances of the old domain remain.
  2. Click through main navigation, check the media library for broken image thumbnails, and load a few posts with embedded images or links.
  3. Re-run the WP-CLI dry-run command from Step 3 one more time (--dry-run) and confirm it now reports zero remaining matches.

If you need to roll back

If a search-replace produces unexpected results (missing content, broken formatting, or visibly corrupted data on a page), restore the database backup you took before starting, per the warning above. Because you ran a --dry-run first and used --precise, this scenario should be rare — but restoring the backup and re-running Step 3 with a narrower, more specific search string (for example scoping to just _options values instead of the full database) is the safe next attempt if something looks off.

Related fixes

FAQ

Why does All-in-One WP Migration's free Find & Replace have a character limit at all?

It's a deliberate constraint in the free version's implementation to keep the tool fast and simple for the common case — most URLs are short. Long serialized strings (theme option blobs, page builder layout data) can exceed that limit, which is exactly the scenario this article's Step 3 is designed to catch and fix with WP-CLI instead.

Is it safe to use a plain SQL find-and-replace query instead of WP-CLI?

No — this is the one thing to actively avoid. A raw SQL UPDATE table SET column = REPLACE(column, 'old', 'new') doesn't know that serialized PHP data records each string's byte length as part of its structure, so replacing a shorter or longer string inside a serialized value without updating that length corrupts the data. WP-CLI's --precise search-replace exists specifically to avoid this by unserializing, replacing, and re-serializing correctly.

Do I need the paid version of All-in-One WP Migration to fix this properly?

No — the manual WP-CLI approach in Step 3 is free and handles what the built-in tool's character limit misses, regardless of which version of the plugin you're using. The paid Unlimited Extension raises some of the plugin's own limits (like file size), but the search-replace character constraint on Find & Replace is a separate thing WP-CLI resolves directly.