Quick wins for a faster PC:
Repair Windows errors before they cause bigger problemsFix Now →Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Clear out junk files and repair common Windows errorsFree Scan →iTechGuides 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.
You can move a WordPress site with Migrate Guru when the destination already runs a clean WordPress installation and both sites are publicly reachable by Migrate Guru’s servers. Install and activate the plugin on both installations, copy the migration key from the destination into the source, start the transfer, test the new site privately, and change DNS only after everything works.
Migrate Guru transfers WordPress data, but it is not a backup system and it does not move mailboxes or unrelated server files. Make an independent, restorable backup before beginning.
Do these 3 things before closing this tab:
1Fix the driver behind crashes, sound loss and screen glitches2Repair Windows errors before they cause bigger problems3Scan for outdated or missing drivers - takes under a minute
What you need before starting
A migration is safest when the new hosting account is ready before you touch the live site. Create the destination account, connect the destination domain, and install a clean WordPress instance there. The destination does not need to contain your finished site yet; Migrate Guru will populate it.
Minimum requirements
| Requirement | Why it matters |
|---|---|
| WordPress installed on the destination | Migrate Guru sends the source site into an existing WordPress installation; it is not a general-purpose server imaging tool. |
| Migrate Guru active on both source and destination | The destination generates a migration key that authorizes the transfer from the source. |
| Public access to both sites | Migrate Guru’s servers must communicate with both WordPress installations. A destination that works only through your computer’s hosts file is not sufficient. |
| A destination domain, temporary URL, or staging URL | Use a publicly resolvable address while DNS still points visitors to the old site. |
| An independent backup | The plugin listing explicitly says Migrate Guru does not back up your site. |
| Optional destination FTP or cPanel details | The WordPress.org listing identifies these as optional information that may be useful during setup, depending on the host. |
Remove temporary firewall rules, HTTP authentication, maintenance pages, or IP allowlists that prevent the migration service from reaching the destination. You can restore those protections after the transfer and testing are complete.
What Migrate Guru moves—and what it does not
WordPress content that is migrated
Migrate Guru is intended to move the WordPress installation rather than only a database export. The documented migration set includes:
- WordPress database tables and settings
- The active and inactive themes
- Installed plugins
- The uploads directory and media files
- WordPress users
Because themes and plugins can store absolute URLs, serialized settings, cached data, or host-specific paths, a successful transfer still requires functional testing on the destination.
The Tool Desk
Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →Items outside the migration
- Email accounts and existing email messages are not moved.
- Unrelated server-level files are not included. Examples can include custom services, system users, server scripts, and files stored outside the WordPress installation.
- A local-only destination reached through a hosts-file change is unsupported because the vendor’s servers cannot reach it.
- Moving a single multisite subsite to another domain, or into a subdivision of a multisite network, is listed as unsupported.
Plan email separately: recreate mailboxes with the new provider, preserve any required mail through an export or provider migration, and update your DNS mail records when the domain moves.
Size, speed, host and usage limits
The following figures are claims shown in the Migrate Guru/WordPress.org listing captured in 2026. They can change, so check the current listing before scheduling a production migration.
| Claim | How to interpret it |
|---|---|
| Up to 200 GB | The advertised maximum site size. It is a platform limit, not a guarantee that every 200 GB site will complete successfully on every host. |
| More than 5,000 hosts | A compatibility claim covering supported web hosts; server security rules and resource limits can still block an individual transfer. |
| Five site migrations per user per month | The stated quota counts five sites per user each month. Each of those five sites may be moved unlimited times under the listing’s wording. |
| 1 GB in less than 30 minutes | An approximate vendor claim for a site containing 1 GB of files and database data. The listing says timing depends on other factors. |
| Version 6.72 and 200,000+ active installations | Figures displayed by the WordPress.org listing at the time captured; both are volatile and should be verified before publication or installation. |
Transfer time depends on file count, database structure, available CPU and memory, disk speed, network throughput, throttling, and security scanning at either host. A small site with thousands of tiny files can behave differently from a larger site containing a few large archives.
How to migrate WordPress with Migrate Guru
1. Prepare the destination hosting account
- Create the new hosting account and add the domain you intend to use.
- Install a clean WordPress instance at that domain. Confirm that you can sign in to its WordPress dashboard.
- Choose a temporary or staging URL if the domain’s DNS still points to the old host. The URL must resolve publicly, not only on your workstation.
- Check that the destination has enough disk space for the source files, database, temporary transfer data, and normal WordPress operation.
- Record any destination-specific credentials or control-panel details you may need later. Migrate Guru’s WordPress.org listing describes FTP or cPanel details as optional, not as a substitute for installing WordPress.
Do not start by changing DNS. The old site should remain the public site until the destination has been validated.
Recommended Free Tools
2. Make and verify an independent backup
Create a backup that you can restore without relying on Migrate Guru. Include the database and the complete WordPress files, especially wp-content/uploads, themes, plugins, and any custom configuration required by your host. Store at least one copy outside the source server and verify that the archive can be opened or restored.
This step is essential because the plugin’s own listing answers “Does Migrate Guru backup my site?” with “No.” A migration failure, an accidental overwrite, or a bad DNS cutover should not leave you without a recovery path.
3. Install Migrate Guru on both sites
- On the source site, sign in to WordPress and open Plugins > Add New.
- Search for Migrate Guru, install it, and activate it.
- Repeat the same installation and activation on the destination WordPress dashboard.
- Confirm that the plugin is active on both sites before requesting a key.
Installing the plugin only on the source does not follow the documented key-based workflow. The destination installation is where you obtain the key used to identify and authorize the target.
4. Copy the destination migration key
- Open Migrate Guru in the destination dashboard.
- Copy the migration key shown by the destination installation.
- Keep the key private while you move between dashboards. Treat it as a transfer credential rather than as public text.
5. Start the transfer from the source
- Open Migrate Guru in the source dashboard.
- Confirm the source site and the destination address displayed by the plugin.
- Paste the destination migration key.
- Run the plugin’s validation step. Resolve any accessibility or connection error before proceeding.
- Enter an email address for progress and error notifications.
- Submit the migration and leave the source available while the transfer runs.
Validation is the point to fix a blocked destination, incorrect URL, inactive plugin, or firewall rule. Do not treat a key acceptance message as proof that the final site is ready for visitors; it only confirms that the transfer can begin.
6. Monitor the migration
Use the migration status page and the notification emails to follow progress. Some hosting instructions report that Migrate Guru opens a hosted BlogVault progress page for detailed status. Keep the source site online and avoid making large content, plugin, or configuration changes during the transfer unless you are prepared to repeat those changes on the destination.
If the transfer appears slow, compare the elapsed time with the amount and type of data being moved. Large databases, many small files, host throttling, and malware or firewall scans can all affect the result. Do not repeatedly start new migrations while an existing run is active; first determine whether the current run has failed or is still processing.
Rank #3
Test the destination before changing DNS
Use a temporary or staging URL that is publicly reachable by you and by Migrate Guru. If the destination is protected by a password or maintenance layer for testing, make sure that protection does not prevent the migration service or your own test devices from loading the site.
| Area | Checks to perform | Pass condition |
|---|---|---|
| Front end | Open the home page, representative posts, pages, categories, search, archives, and 404 page. | Pages render without missing templates, fatal errors, or unexpected redirects. |
| WordPress administration | Sign in with existing administrator and editor accounts; open Posts, Media, Settings, and plugin screens. | Users can authenticate and required roles and permissions remain correct. |
| Media | Open images, PDFs, galleries, and files uploaded at different times. | Files load at the destination URL and are not returning 404 or permission errors. |
| URLs and redirects | Inspect internal links, canonical URLs, pagination, attachment links, and old URL redirects. | Links point to the intended domain and no redirect loop occurs. |
| Forms | Submit contact, login, search, checkout, comment, or other important forms using test data. | Validation, confirmation pages, and notifications behave as expected. |
| SSL and mixed content | Load HTTP and HTTPS variants, inspect the browser lock, and check pages containing scripts, images, and fonts. | The intended HTTPS URL works without certificate errors or blocked insecure assets. |
| Cache and performance layers | Purge destination caches and test logged-in and logged-out views. | Visitors see current content and personalized pages are not served from a public cache. |
| Scheduled work | Check WordPress cron events and any host-level scheduled jobs. | Backups, publishing, cleanup, feeds, and other scheduled tasks run at the expected time. |
| Email and integrations | Test transactional email, analytics, payment or shipping connections, webhooks, APIs, CDN settings, and external authentication. | Third-party services recognize the new URL, credentials, and outbound IP where required. |
Check domain and URL behavior carefully
A migration can leave the database containing the old site URL in settings, menus, widgets, plugin options, or serialized values. Test both the temporary address and the final domain plan. If URLs must be changed, use a method that understands serialized WordPress data rather than blindly replacing text in the database; an unsafe replacement can corrupt serialized values.
Check caching, SSL and cron separately
These functions often depend on the host rather than on WordPress files alone. Install or activate the destination SSL certificate, clear page and object caches, confirm the site’s timezone, and verify that scheduled publishing and maintenance jobs execute. A site can look correct in a browser while cron, queues, or cache purges are still failing.
Change DNS and complete the cutover
- Choose a low-traffic maintenance window and record the current DNS records, including mail, verification, CDN, and third-party service records.
- Make a final content check on the source. If the site receives comments, orders, registrations, or other writes, pause those activities briefly or plan a controlled final synchronization so new data is not left behind.
- Point the web DNS records to the destination host using the records supplied by that host.
- Keep the old site online and unchanged while DNS caches expire.
- Check the site from more than one network and resolver. Confirm HTTPS, redirects, forms, media, login, and important integrations on the public domain.
- Review destination access logs, PHP errors, cron results, uptime, and email delivery during the first operating period.
Do not delete the old hosting account immediately. Retain the old site and the independent backup until you have confirmed that DNS has converged and no late-arriving traffic or data is still reaching the source.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Common problems and fixes
The migration key is rejected or validation fails
- Confirm that Migrate Guru is active on the destination, not merely installed.
- Reopen the destination plugin and copy the current key again.
- Verify that the destination URL is correct and publicly resolvable.
- Temporarily remove basic authentication, maintenance mode, IP restrictions, or a web application firewall rule that blocks the vendor’s servers.
- Check that the destination SSL certificate is valid and that the host is not blocking the connection by region or IP.
The destination is available only through a hosts file
This arrangement is unsupported. A hosts-file entry changes name resolution only on your computer; it does not make the site reachable to Migrate Guru’s servers. Use a temporary or staging hostname with public DNS, or complete the migration on a publicly accessible destination before applying private testing controls.
The transfer is slow or stops
- Allow for the actual file and database volume, not just the visible page count.
- Check destination disk space, PHP limits, server resource usage, and host-side transfer restrictions.
- Look for a status or error message in the migration page and notification email.
- Do not assume that the approximate “1 GB in <30 mins” statement applies to your site; it is a vendor estimate with stated dependencies.
- If a run has clearly failed, preserve the source and backup, correct the reported condition, and start a controlled retry rather than several simultaneous runs.
Pages work but images or downloads are missing
Inspect the destination uploads directory, file permissions, attachment URLs, and any CDN or offload configuration. Test files from different years and directories. If only thumbnails are absent, regenerate them with a WordPress-compatible process after confirming that the original files are present.
Links redirect to the old domain or produce loops
Review WordPress’s Site Address and WordPress Address settings, menus, widgets, plugin options, canonical settings, and server redirects. Ensure the final HTTPS decision is consistent across those layers. Make database URL changes with a serialization-aware tool and take another backup first.
Forms submit but no email arrives
Email accounts and mail data are outside the migration. Recreate the mailbox or configure the destination’s authenticated mail service, then test delivery to more than one provider. Also update SPF, DKIM, DMARC, or other mail DNS records when your mail service requires them.
A multisite migration does not match expectations
Migrate Guru’s documented boundaries exclude moving an individual multisite subsite to another domain or into a multisite-network subdivision. Treat a whole-network migration differently from a single-site move, and verify the network’s domain mapping, uploads paths, users, and network-activated plugins. The listing describes a multisite network installation as becoming network-activated, so review network-wide behavior before cutover.
When Migrate Guru is the wrong tool
Choose another migration plan when the destination cannot be made publicly reachable, when you need to move only a multisite subsite in one of the excluded arrangements, or when the project includes substantial non-WordPress server services. A manual or host-assisted process may be more appropriate when you must migrate mailboxes, custom daemons, system-level files, or a database that requires bespoke transformation.
Even when Migrate Guru is suitable, keep the backup, testing, and DNS stages under your control. The plugin automates transfer of WordPress data; it does not decide whether the new server’s email, cron, SSL, cache, DNS, or third-party integrations are correctly configured.
Quick Recap
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.
