Crashes, No Sound, or Screen Glitches?
Random freezes, missing sound and display glitches usually trace back to one bad driver. Find and replace yours safely.Free scan · under a minutePC Slower Than It Used to Be?
A free scan shows the junk files, broken settings and background clutter dragging Windows down - then fixes them in one click.Free scan · Windows 10 & 11iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Antihost offers managed WordPress hosting with free migration, one-click staging and a 14-day free trial.
To migrate several WordPress sites to new domains safely, treat every domain as its own migration unit. For each site, back up the complete files and database, build and test the destination before changing DNS, update every stored URL with a serialization-aware tool, and publish a one-to-one permanent redirect map. You can run those units in parallel, but do not treat unrelated installations as one database or assume a single network-wide replacement is safe.
The migration is complete only after the new sites work, old URLs redirect directly to their matching destinations, search engines can crawl the new properties, and you have monitored errors and traffic long enough to catch delayed failures.
Recommended Free Tools
What a multi-domain WordPress migration actually changes
A domain migration is more than a DNS change. DNS only directs a hostname to a server; it does not move WordPress files, import the database, update stored URLs, configure SSL, or preserve links to old pages. Each site needs its own controlled copy, URL conversion, testing cycle, and redirect policy.
Standalone installations are separate migration units
If you have several ordinary WordPress installations on different domains, each normally has its own database, wp-config.php, plugins, themes, uploads, cron jobs, and URL map. Create a separate runbook and rollback point for every installation, even when the sites share a host or destination server. A failure in one database should not force you to roll back the others.
WordPress Multisite is a different case
A Multisite network stores network-level and per-site domains or paths in shared database structures. The move must account for wp_blogs, wp_site, and each wp_x_options table, including its home, siteurl, and fileupload_url values. The network also has shared configuration and rewrite rules. Use a network-scoped procedure only when the sites genuinely belong to the same Multisite network; never apply a network command to unrelated standalone databases.
Build a migration register before touching production
Create one row per domain in a shared register. This becomes the control document for backups, testing, cutover, and rollback. Record the values as they exist before migration so that a later error can be traced to a specific change.
The Tool Desk
Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →| Record for each site | Why it matters during the move |
|---|---|
| Old and planned new domain, including protocol and www preference | Defines the URL replacement and redirect map; prevents mixed HTTP, HTTPS, www, and non-www variants. |
| Hosting account, server address, PHP version, database engine and version | Lets you reproduce compatible runtime settings and identify version-related failures. |
| WordPress version, active theme, must-use plugins, ordinary plugins and license callbacks | Provides a checklist for restoring functionality and reconnecting services. |
| Database name, table prefix, approximate size and largest tables | Determines export method, transfer time, disk requirements and whether a large-database plan is needed. |
| Uploads size and filesystem locations | Confirms that media, backups and generated assets are copied, not just the core WordPress directory. |
| Important URLs, URL count and current redirect rules | Forms the basis of a one-to-one redirect map and post-migration crawl. |
| DNS records, nameservers, SSL certificates, mail records and third-party endpoints | Prevents an apparently successful web move from breaking email, APIs, payment callbacks or verification records. |
| Scheduled tasks, external cron jobs, webhooks and analytics IDs | Ensures background jobs run once, on the right host, with the right credentials. |
Freeze changes or define a content window
Choose a short period in which editors do not publish, update settings, upload media or change orders. If a full freeze is impossible, record the exact cut-off time and plan a final database export immediately before cutover. A database copied before the last content change cannot contain that change, so the register should show which export is the authoritative one.
Create independent, restorable backups
- Copy the entire WordPress directory, including
wp-content, uploads, custom files and any web-server configuration kept with the site. - Export the complete database, not only selected content tables.
- Store at least one untouched copy outside both the old and destination servers.
- Record the backup timestamp, file sizes and checksums where your process supports them.
- Test that the archive can be opened and that the SQL dump contains the expected table prefix and recent content.
Keep the old host intact until the new site has passed verification and the redirect period is established. It is both a rollback source and the place that can answer old URLs during the transition.
Prepare every destination before changing DNS
Build the target environment while the old domain still serves visitors. For each site, create the hosting account, database, database user, PHP/runtime settings, filesystem permissions and SSL certificate. Use a staging hostname or hosts-file override so you can test the site without exposing an unfinished installation to the public domain.
Match compatibility deliberately
Start with the same PHP and database major versions unless you have separately tested an upgrade. Copy required PHP extensions, memory limits, upload limits, execution limits and server rewrite support. A domain move is a poor time to combine an untested runtime upgrade with a data migration; changing one variable at a time makes failures diagnosable.
Plan capacity for the largest site
Allow temporary disk space for the original files, compressed archives, extracted files and imported database. Large SQL imports may require higher execution or packet limits, command-line import, or a host-supported database tool. Measure the largest site rather than sizing the destination from the average of the group.
Prepare SSL and mail dependencies
Issue the destination certificate before cutover and test HTTPS directly on the staging hostname where possible. List every mail-related DNS record and provider setting. Moving web files does not automatically move mailboxes, and changing nameservers or MX records can interrupt delivery if the records are not recreated.
Repeatable per-site migration runbook
Run the following sequence independently for each domain. You may execute several sites in parallel after the operators, backups and rollback checkpoints are clearly separated.
1. Capture the final inventory and backup
- Confirm the old and new canonical URLs, protocol and hostname format.
- Export the database and copy the full WordPress directory.
- Save DNS, SSL, cron, email, webhook and redirect information with the backup record.
- Crawl or export important old URLs, including posts, pages, media, feeds, sitemaps and transactional endpoints.
- Mark the backup location and verify that it is available without relying on the destination server.
2. Install the destination shell
- Create the destination database and user with the required privileges.
- Set the tested PHP version and extensions.
- Install the web server rules needed by WordPress and create the staging hostname.
- Install the destination SSL certificate and confirm that HTTPS requests reach the intended virtual host.
3. Transfer files and database
Copy the WordPress directory, preserving permissions where the host requires them. Import the database into the destination database rather than attempting to rebuild content through the WordPress editor. WP-CLI provides scriptable database operations:
Free tools Windows power users keep installed
One-click scans. No signup required.
wp db export /safe/path/site-old.sql
wp db import /safe/path/site-old.sqlRun these commands from the correct WordPress directory and identify the target database explicitly when the environment contains more than one installation. For very large databases, use the host’s documented command-line or streamed import process and keep the original dump unchanged.
4. Set configuration and initial URLs
Edit the destination wp-config.php with the destination database name, user, password, host and table prefix. Confirm that the web-server user can read WordPress files and write only where WordPress needs to write, such as uploads and cache directories.
Set the copied site’s home and siteurl to the new URL. You can update them in the database or with WP-CLI, provided the command is pointed at the destination installation:
wp option update home 'https://new.example'
wp option update siteurl 'https://new.example'If the site is temporarily accessed through a staging hostname, use a controlled hosts-file or staging method rather than permanently writing the staging hostname into content that should resolve to the production domain.
5. Replace old URLs without corrupting data
Old-domain strings can appear in post content, options, widgets, theme settings, plugin configuration, media metadata and custom tables. Some values are PHP-serialized and contain the character length of the stored URL. A plain SQL text replacement can therefore leave invalid lengths and break widgets, theme settings or other data.
Use a serialization-aware tool. WP-CLI’s search-replace command is suitable for repeatable work and can be reviewed before it changes anything:
wp search-replace 'https://old.example' 'https://new.example' --dry-run --report-changed-onlyReview the dry-run table and row counts. If they match the inventory, run the replacement without --dry-run:
wp search-replace 'https://old.example' 'https://new.example' --report-changed-onlyFor large or unusual databases, consider --precise; for nested objects, consider --recurse-objects. Exclude tables or columns only when the migration policy calls for it. The --skip-columns=guid option is available when you intentionally leave post GUIDs unchanged; document that decision rather than applying it automatically. Export a transformed SQL file when you need an auditable artifact or a second environment to receive the same converted data.
6. Clear caches and regenerate derived data
After the replacement, clear page, object and opcode caches according to the destination host. Regenerate rewrite rules by visiting the Permalinks screen or using the site’s established WP-CLI procedure. Rebuild search indexes, image thumbnails or plugin-generated files only when that plugin requires it, and record each action so it can be repeated during rollback.
7. Verify the complete site on staging
Use the staging hostname or a local hosts-file override while the public DNS still points to the old site. Test both logged-out and administrator sessions. A migration is not ready merely because the homepage loads.
8. Cut over DNS and redirects
Lower DNS TTL ahead of the planned change when operationally appropriate, then point the new domain’s records to the validated destination. Keep the old host available to answer old URLs with redirects. Do not delete the old installation immediately after DNS changes; resolver caches and delayed crawlers will continue to reach it.
9. Monitor and record results
For each domain, watch origin logs, uptime, PHP and database errors, 404 responses, redirect chains, Search Console coverage, sitemap processing, traffic, conversions and server capacity. Record incidents by site so one noisy installation does not hide a failure on another.
Rank #3
How to replace every old domain reference safely
Where old URLs commonly remain
- Post and page body content, excerpts and custom fields.
- Site options, widgets, menus and theme customizer values.
- Attachment metadata, image URLs, generated CSS and cached HTML.
- Plugin settings, form actions, webhook destinations and API callbacks.
- Canonical tags, schema fields, Open Graph metadata and XML sitemap configuration.
- Custom tables created by themes or plugins.
- Multisite network and per-site tables.
Search for both the full URL and meaningful host variants, such as an HTTP version or a www variant, after the primary replacement. Do not assume that changing home and siteurl changes post content or plugin settings.
Why blanket SQL replacement is risky
Serialized values store lengths alongside strings. If the old and new domains have different lengths, a raw SQL replacement can make the stored value unreadable. WordPress Developer Resources specifically warns that whole-database replacement can cause serialization issues because themes and widgets may store the URL length. Use WP-CLI, a serialization-aware migration plugin, or a specialist database script instead.
Choosing replacement scope
| Situation | Recommended scope | Control to apply |
|---|---|---|
| One standalone installation | That site’s tables and relevant custom tables | Run a dry run, inspect changed rows, then execute and export the result. |
| Several standalone installations on one server | One database at a time | Use separate credentials, working directories and logs; never use a shared network flag. |
| One WordPress Multisite network | Network and all site tables | Use the WP-CLI --network scope only after confirming the database is a single network. |
| Mixed domains stored in one database | Target only the old-to-new mapping for the site being moved | Use table and column exclusions where required and review every changed table. |
Multisite-specific checks
Before a Multisite move, map every site ID, domain and path. Confirm whether the network is changing only its host, its paths, or both. The database references and web-server rules must agree with that decision.
Database locations to review
wp_blogsfor each site’s domain and path.wp_sitefor the network’s domain and path.- Each
wp_x_optionstable forhome,siteurlandfileupload_url. - Network options and custom tables that contain hostnames or absolute URLs.
WordPress also requires review of .htaccess and wp-config.php when a Multisite domain changes. Test network administration, site creation, uploads, mapped domains, login cookies and subdirectory or subdomain routing before DNS cutover.
Use network scope only for a confirmed network
WP-CLI’s --network flag scopes search-replace across a Multisite network. It is useful when the network’s sites share one database, but it is dangerous on a server containing unrelated installations. Identify the database connection and table prefix first, then run a dry run and inspect the per-table report.
Build redirects and protect search visibility
Create a one-to-one URL map
Map every important old URL to the most relevant new URL before cutover. Include pages that are not linked from navigation but receive search traffic or external links. A simple mapping can be maintained as a CSV or spreadsheet:
| Old URL | New URL | Expected response | Validation |
|---|---|---|---|
https://old.example/guide/ |
https://new.example/guide/ |
301 or 308 directly | Content, canonical and status match |
https://old.example/product-a/ |
https://new.example/products/product-a/ |
301 or 308 directly | Equivalent product page loads |
| Removed URL with no equivalent | Closest genuinely relevant replacement, or an intentional 404/410 | Documented decision | No mass redirect to the homepage |
Use direct permanent redirects
Configure server-side 301 or 308 redirects from each old URL to its final destination. Avoid chains such as old URL to an intermediate host to the new URL, and do not send unrelated pages to the homepage. Update internal links, canonical tags, structured data, feeds and sitemaps so visitors and crawlers encounter the new URLs directly.
Remove migration-only blocks
Before launch, remove temporary noindex directives, password protection and robots rules that were used to keep staging private. Confirm that the production robots file permits crawling of important content and that the XML sitemap contains only the new canonical URLs.
Quick wins for a faster PC:
Clear out junk files and repair common Windows errorsFree Scan →Scan for outdated or missing drivers - takes under a minuteDriver Scan →Complete the Google migration steps
Verify both old and new properties in Search Console, submit the new sitemap and use Change of Address for a domain-to-domain move. Google states that permanent redirects do not cause a loss in PageRank, but rankings can fluctuate while the new URLs are crawled and reindexed. Google describes a few weeks or more as a possible timeframe for medium sites, with larger sites often taking longer. Keep redirects for at least one year; retaining them indefinitely is useful when users or external links may continue to use old addresses.
Change one major variable at a time where possible. Combining a domain move, a redesign, a URL taxonomy change and an untested platform upgrade makes it difficult to identify why rankings, conversions or templates changed.
Pre-cutover verification checklist
| Test | What to verify | Evidence to record |
|---|---|---|
| Administrator login | Login, password reset, roles and cookies work on the new domain. | Successful login and logout from a clean browser session. |
| Front-end templates | Home, archive, post, page, search, pagination, 404 and author views render correctly. | Representative URLs with no PHP warnings or broken layout. |
| Media | Images, downloads, responsive sizes and captions use the new host. | Sample original and generated-size requests return 200. |
| Forms and commerce | Validation, submission, notifications, payment callbacks and confirmation pages work. | Test submission or transaction in the provider’s safe mode. |
| Search and feeds | Internal search, RSS/Atom feeds and XML sitemaps reference the new domain. | Fetched documents contain no old-host URLs. |
| SEO signals | Canonical tags, robots rules, structured data and hreflang (if used) are correct. | Rendered HTML and crawler output from representative pages. |
| APIs and integrations | REST endpoints, webhooks, analytics, license callbacks and external APIs accept the new host. | Successful request logs and provider-side confirmations. |
| Background work | WP-Cron or system cron runs once and writes expected results. | Recent scheduled-task entries and no duplicate jobs. |
| Redirects | Old URLs return one direct permanent redirect to the mapped new URL. | Automated status and hop-count report. |
Run several migrations in parallel without losing control
Parallel work reduces calendar time but increases the chance of mixing credentials, databases or redirect files. Use a batch board with a separate status for inventory, backup, destination ready, import, URL replacement, verification, DNS cutover and monitoring.
Safe batching pattern
- Start with one low-risk site and use it to validate the destination template, backup process and monitoring.
- Run a second site only after the first has a tested rollback and a clean log.
- Group sites by host, database size or integration complexity, but keep each site’s files, database and redirect map isolated.
- Schedule high-traffic or transaction-heavy sites in separate windows from one another.
- Assign one owner to approve each site’s DNS change and rollback decision.
Keep credentials and logs separated
Use a unique working directory and migration log for every domain. Label SQL dumps with the site, environment and timestamp. Never paste one site’s database credentials into another site’s configuration, and verify the active WordPress path before every WP-CLI command.
Do these 3 things before closing this tab:
1Fix the driver behind crashes, sound loss and screen glitches2Clear out junk files and repair common Windows errors3Scan for outdated or missing drivers - takes under a minuteDefine rollback triggers
Roll back a site when critical pages fail, transactions or email cannot be verified, redirect errors are widespread, or database corruption is suspected. A rollback normally means restoring the old DNS target, keeping the old host serving the original installation, and preserving the new site’s logs for diagnosis. Do not overwrite the only clean backup while troubleshooting.
Choose the migration method that fits your risk
| Method | Strengths | Trade-offs and controls |
|---|---|---|
| Manual file and database transfer | Full visibility, no dependency on a migration plugin, works with unusual layouts. | Slower and easier to perform inconsistently across many sites; requires careful serialization-aware replacement and documented commands. |
| WP-CLI automation | Repeatable exports, imports and search-replace; dry runs, reports, exclusions and scripting support. | Requires shell access, command-line/database knowledge and strict path and credential checks. |
| Migration plugin | Convenient interface for teams that prefer a guided workflow; some provide serialized-data handling and staging support. | Compatibility, upload limits, licensing and large-database behavior vary; test the exact plugin and version before a batch move. |
| Managed migration service | Can supply operational expertise for DNS, SSL, redirects, large databases and rollback coordination. | Requires clear access controls, a written scope, backup ownership, audit logs and acceptance tests for every domain. |
Compare options on serialized-data safety, repeatability, Multisite support, dry-run capability, database size limits, downtime control, DNS and SSL handling, redirect management, logging, required expertise and total cost. The cheapest transfer is not necessarily the least expensive if it creates lost leads, broken payments or prolonged search recovery.
Common failure modes and recovery actions
The new homepage works but internal links still use the old domain
The database replacement was incomplete or only home and siteurl were changed. Search the database and generated files for all old protocol and hostname variants, then rerun a serialization-aware replacement. Clear caches and recrawl representative content.
Widgets or theme settings disappear after replacement
A raw SQL replacement probably damaged serialized lengths. Restore the clean database backup, repeat the move with WP-CLI or another serialization-aware tool, and validate widgets and customizer settings before importing new content.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Redirects loop or require several hops
Conflicting rules may exist on the old host, destination host, HTTPS terminator or application. Test the old HTTP, old HTTPS, www and non-www variants separately, then consolidate each into one direct permanent redirect to the final canonical URL.
Images return 404 while pages load
Check upload paths, attachment metadata, case-sensitive filenames, CDN settings and rewrite rules. Confirm that the wp-content/uploads tree was copied and that generated image sizes exist or can be regenerated.
Administrators are repeatedly logged out
Inspect cookie domain and HTTPS configuration, reverse-proxy settings, mixed-content errors and duplicate WordPress installations. Clear browser cookies, confirm the destination URL values and test from a clean session.
Cron jobs run twice
Both old and new hosts may still be executing scheduled work. Disable or isolate the old scheduler at cutover, verify the destination cron configuration, and monitor job logs for duplicate sends or repeated imports.
Email stops after DNS changes
Web content and mail routing are separate. Compare the new DNS zone with the recorded MX, SPF, DKIM and provider verification records, and confirm that the mail provider—not the web migration—owns the mailbox data.
Search traffic falls immediately
Check that redirects are direct and permanent, canonical tags and sitemaps use the new domain, staging noindex rules were removed, and important old URLs were mapped individually. Inspect Search Console coverage and server logs before making additional structural changes.
When to bring in migration help
Use an experienced WordPress migration specialist when you lack shell or database access, the database is very large, the sites process transactions continuously, the network is Multisite with domain mapping, or the move includes a host change, redesign and runtime upgrade at the same time. Ask for a per-domain inventory, restorable backups, a dry-run report, a redirect map, acceptance tests, access revocation and a documented rollback plan. Managed help is valuable only when those deliverables are explicit; handing over credentials without an audit trail does not reduce migration risk.
Quick Recap
Operational sign-off after launch
- All mapped old URLs return one direct 301 or 308 to the intended new URL.
- The new sitemap is submitted and contains only canonical destination URLs.
- Search Console properties and Change of Address are configured where applicable.
- 404s, PHP/database errors, uptime, redirect hops and origin capacity are monitored per domain.
- Forms, payments, email, analytics, APIs, cron and plugin callbacks have confirmed results.
- The old host remains available for redirects and rollback for at least the planned retention period.
- Each site’s final configuration, DNS values, backup location and migration log are archived.
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
