How to Migrate a WordPress Site to a New Host in 2026

A WordPress website usually consists of several interdependent elements. The files contain WordPress software, themes, plugins, uploaded images and configuration. The database contains most posts, pages, settings, users and other structured records. The domain and DNS determine which servers visitors reach. Email might be hosted by a completely different provider. Third-party services—payment gateways, analytics, caching, forms, search services and scheduled tasks—can depend on environment-specific settings.

Moving only wp-content does not reliably move an entire site. Copying files without the correct database means content and settings may be missing. Importing the database without appropriate credentials or application configuration can result in the 'Error establishing a database connection' screen.

A successful move preserves both the application and its dependencies. Think of the process as rebuilding an operational system at a new address, not simply uploading a folder.

Moving hosting versus changing the domain

Same domain, new host: Visitors continue using example.com and the same post URLs. You replace the infrastructure behind the address, usually by changing A/AAAA/CNAME records or another appropriate DNS configuration. Google has specific guidance for this case and does not recommend treating it automatically as a change-of-URL move.

New domain as well as a new host: You are changing public URLs. You need a URL mapping, appropriate permanent redirects, updated canonical and internal links, a revised sitemap and additional Search Console steps. Google treats this as a site move with URL changes. Do not use the simpler instructions below as the entire SEO plan for a rebrand or domain change.

This distinction prevents one of the most common migration mistakes: changing WordPress URLs or creating broad redirects when no URL change was intended.

Scroll to see all table columns →

Recommended order: Ask the new host whether it provides a genuinely managed migration, and obtain the exact scope in writing. If not, evaluate a reputable plugin compatible with your site. Choose a manual move where you need that flexibility and understand the consequences.

Do not select a method based solely on a marketing claim that it guarantees 'zero downtime'. Downtime risk also depends on content changes, DNS cutover, database synchronisation, SSL, caches and application behaviour.

1. Map the environment

Record the source hosting company, WordPress version, PHP version, database version, active theme, must-use plugins, normal plugins, caching layers and any custom configurations. Note whether the site is standard single-site WordPress, multisite, WooCommerce, an LMS or a membership system.

Check where DNS is controlled. Domain registration, authoritative DNS and web hosting may be on three different services. You will change the records at the authoritative DNS provider, not automatically at the registrar or the new host. If you use Cloudflare, verify how the records are proxied before modifying them.

2. Identify critical integrations

Create an inventory of contact forms, payment processing, order emails, SMTP, scheduled publishing, membership logins, custom cron jobs, object storage, API callbacks, webhooks, CDN settings, firewall rules and any site-specific PHP extensions.

These services may be able to use the same public domain after the move, but still depend on destination server IPs, file paths, secrets or callback allowlists. Inspect them rather than assuming they will reconfigure themselves.

3. Check destination compatibility

Confirm the new host supports your WordPress and PHP versions, required database engine, disk space, filesystem permissions, media storage, expected traffic, required PHP extensions and application upload limits. Ask about SSH/SFTP, WP-CLI, staging environments and backup/restore access.

A site that barely fits its current 20 GB disk allocation may not fit a destination with 10 GB available. Include archive extraction space, database storage and future growth. If the host uses different PHP defaults, plugins may show warnings or fail even though the migration copied every file correctly.

4. Choose a maintenance or content-freeze window

For a brochure website, changes are infrequent and the window can be short. For a news publication with several editors, determine when new posts and uploads should stop. For a store, every new paid order or updated inventory record creates a risk of the old and new databases diverging.

Critical rule: If the source database remains writable while an old snapshot is transferred, anything written after the snapshot may be absent from the destination. Plan a final sync or controlled write freeze for dynamic sites. Do not promise that a standard plugin move automatically solves this problem.

5. Take independent backups of files and database

Create a full backup that includes the database and application files. For many WordPress sites, the essentials include wp-content, core files, wp-config.php, .htaccess where used and the complete appropriate database. Some providers can rebuild WordPress core, but preserving the complete state simplifies recovery and investigation.

Do not rely solely on a backup that is stored inside the account you plan to close. Save a copy in a separately controlled location, protect it against unauthorised access and verify it can be opened or restored. Backup archives frequently contain passwords, personal information and sensitive configuration.

A backup is proven only when restore integrity is checked. At minimum verify archive size, expected folders and a database export that looks structurally complete. For high-value applications, perform an actual restore rehearsal in staging.

6. Lower DNS TTL if appropriate

If you control DNS and understand its current configuration, reducing the relevant record's time to live before cutover can shorten how long resolvers continue using the old address. Do this in advance of the move, allowing the previous TTL to expire. A low TTL is not a guarantee of instantaneous worldwide cutover; caching behaviour and intermediate infrastructure can still vary.

Keep a record of the original values so you can restore a sensible TTL after the site stabilises.

7. Capture a baseline

Take screenshots of the homepage, selected articles, navigation, forms, checkout and admin functions. Record representative URLs and their HTTP statuses. Note current analytics activity, Search Console coverage, robots directives and sitemap location. Export a list of installed plugins and, where possible, the important application settings.

This reference makes troubleshooting much faster. Without it, teams can spend hours deciding whether a visual problem existed before the move.

A WordPress migration is not just a copy operation; it is a state-consistency problem. If a visitor places an order or a customer edits their membership while the database copy is being made, those changes may exist only on the old server. This matters far more for WooCommerce, forums, booking engines and subscription websites than for a read-only portfolio.

For a mostly static content site, a brief publishing freeze followed by a final database synchronisation can be enough. For a store, determine whether your host supports a final synchronisation that preserves order tables and any custom data. If it does not, arrange a short maintenance window or an appropriate write-freeze at cutover, and verify the count and IDs of the most recent orders before opening the new site. Do not assume copying uploads a second time will capture late database transactions.

The safe migration method is therefore the one that matches how frequently data changes, not simply the plugin with the fewest clicks.

A genuinely supported transfer is often the least stressful approach for a small business. Providers may offer free migrations, but free is not a standard service definition.

Step 1: confirm exact scope

Ask whether the migration includes the database, uploads, themes, plugins, redirects, staging, SSL/TLS installation, DNS coordination, email mailboxes and post-move validation. Clarify whether the provider also synchronises final database changes after the initial copy. Many services exclude email and complex custom integrations.

Step 2: grant access securely

The provider may require a temporary WordPress administrator account, control-panel access or SFTP credentials. Use the vendor's approved secure handover method; avoid emailing permanent passwords in plain text. Where possible, create time-limited credentials and remove them when the transfer is complete.

Step 3: request an isolated copy

Ask for the destination to be prepared and previewable before switching public traffic. Some hosts supply a temporary application URL or staging environment. Ensure staging is not accidentally indexed and cannot charge real customers or send live transactional messages.

Step 4: verify application functions

Do not rely only on the migration confirmation email. Review frontend pages, admin, images, fonts, search, forms, logins, contact messages and plugins that matter to the business. Check destination error logs if something behaves differently.

Step 5: agree on cutover responsibility

Know who will update DNS, who will monitor the launch and who is authorised to revert it if something fails. If ecommerce orders or membership records can change during the process, establish a final sync or maintenance procedure before launching.

When this method is best: A typical small WordPress website whose owner values reduced operational risk more than low-level control.

Migration tools can package the WordPress application and move the database while handling environment changes. Well-known examples include Duplicator and provider-specific tools such as the Cloudways WordPress Migrator. Features, archive-size support and paid/free restrictions change; check the current plugin documentation rather than following screenshots from several years ago.

Step 1: select a compatible tool

Verify support for your WordPress and PHP versions, database size, multisite architecture where relevant, host-specific security settings and any special tables created by ecommerce or membership plugins.

Step 2: make the independent backup anyway

A plugin creating its own migration package is not a substitute for an additional recovery copy. Save the separate backup before installing or running the migrator.

Step 3: prepare the destination application

Follow the plugin or host's exact instructions. Some tools import into a blank destination WordPress site; others install a package through a standalone installer. Do not install a second WordPress site into the same directory unless that is specifically part of the supported procedure.

Step 4: run the transfer

Enter the appropriate destination host, application path or connection credentials through the plugin interface. Keep records of errors and completion status. Large sites can be interrupted by PHP execution limits, blocked outgoing connections, insufficient storage or exhausted quotas.

Step 5: preview and test

Check all critical functionality before updating DNS. Confirm that the tool did not unintentionally change public URLs, staging noindex rules, file permissions or data needed by third-party applications.

Step 6: perform a controlled final sync if necessary

An initial plugin transfer of a busy store does not guarantee that new orders placed later are present in the migrated database. Freeze writes, reconcile or synchronise changes using a method supported by the application, and confirm the last order/customer record before cutover. Complex stores may require specialist migration support.

Example: migrating to Cloudways

Cloudways' June 2026 documentation describes creating a WordPress application on the destination, installing the Cloudways WordPress Migrator plugin on the existing site, entering connection and destination details, then running the transfer. Cloudways indicates that its migrator supports single-site and some multisite use cases. Its current documentation specifically says multisite is supported on Cloudways Flexible but not Autonomous; this distinction should be checked before choosing the hosting product.

The provider's wizard is the primary source for exact fields and steps. Do not paste credentials into forms or scripts from unofficial screenshots without verifying their origin.

Manual migration provides precise control. The following is a conceptual process for a single-site WordPress installation where public URLs are staying the same. Hosts differ in file paths, control panels, database systems and SSH availability.

Step 1: create a full backup and export the database

From the existing host, back up the web root and the relevant database. Use a trusted database-export mechanism such as phpMyAdmin's export function, a supported host backup tool or WP-CLI where available. Preserve character encoding and avoid truncating large tables.

Check the export contains posts, options, users and plugin-specific tables as appropriate. File backups should include uploaded media and hidden configuration files needed by the installation. Never assume copying visible files in an FTP window captures every hidden file.

Step 2: prepare a fresh database on the new host

Create the destination database and a dedicated database user with the necessary permissions. Record its database name, username, password and database host securely. These values may differ from the previous server even if the public WordPress domain remains unchanged.

Make sure the database engine/version and character set support the source data. Very old installations may need compatibility work before a safe move.

Step 3: upload application files

Transfer the WordPress files into the correct document root on the new host by SFTP/SSH or an approved file-manager process. Keep directory structure intact. Preserve file ownership and permissions according to the new host's security recommendations. Do not blindly set every directory and file to world-writable permissions as a workaround.

For large media libraries, an archive transferred and extracted on the server can be faster than uploading tens of thousands of small files, but only use an extraction path and archive tool you trust. Remove leftover publicly accessible backup archives and installers after completion.

Step 4: import the database

Use the destination database administration tool to import the SQL dump, or use a supported command-line import. Monitor for errors rather than assuming that reaching the end of a progress bar means every table loaded successfully. Confirm expected table counts and key records.

Database prefixes are not required to be wp_. Use the site's actual table prefix. If you restore the existing tables with their prefix, the WordPress configuration must refer to that prefix.

Step 5: update wp-config.php

Adjust the database values in wp-config.php for the destination:

define('DB_NAME', 'destination_database');
define('DB_USER', 'destination_user');
define('DB_PASSWORD', 'secure-password-from-your-host');
define('DB_HOST', 'database-host-provided-by-host');

These are placeholders, not credentials. The correct DB_HOST might be localhost, an internal hostname or a managed database endpoint. Preserve the existing authentication salts, table prefix and relevant custom settings unless there is a specific security or configuration reason to change them. Do not expose the configuration file in a public download.

Step 6: configure PHP, HTTPS and rewrites

Select a supported PHP version, configure required extensions and review PHP limits, caching and web-server rules. WordPress permalink handling may differ between Apache and NGINX. Preserve custom rewrite rules only when they are compatible with the new environment.

Issue or activate a valid TLS certificate for the live domain. If you preview the site before DNS cutover, the certificate presented during preview may differ; do not misinterpret that as proof the production configuration is finished.

Step 7: avoid unnecessary database URL replacement

When the domain and WordPress URLs stay the same, a general search-and-replace of example.com has no legitimate purpose and may introduce errors. WordPress URLs should normally remain unchanged.

If the public URL really changes—for example from https://old.example.com to https://new.example.com—WordPress data can contain embedded absolute references, including PHP-serialised values. Do not use a plain SQL or text search-and-replace indiscriminately. WordPress' official migration guidance warns about the risks to serialised data. WP-CLI's search-replace supports serialised data and a --dry-run flag.

An illustrative developer command for an actual domain change is:

wp search-replace 'https://old.example.com' 'https://new.example.com' --all-tables-with-prefix --skip-columns=guid --dry-run

Only after reviewing the preview, making a backup and understanding the affected tables should an administrator consider the real change. Scope matters: external systems, multisite and custom fields may need additional handling. Do not copy this command into production merely because a hosting migration occurred.

Step 8: check site settings and plugins

Verify the site's WordPress Address and Site Address, timezone, permalink settings, mail delivery, caching configuration, media paths and any absolute server paths stored by plugins. Update environment-specific API allowlists, cron schedules, storage endpoints and application-level secrets if required.

Step 9: run functional tests

Test publishing and editing, the block editor, media uploads, theme assets, forms, search, authentication, redirect rules, scheduled tasks, checkout and other business-critical processes. Only when the destination passes should public DNS cutover proceed.

This is the step that makes a migration controlled rather than hopeful.

Prefer the new host's supported preview or staging mechanism. Some hosts provide temporary application URLs; others allow a local hosts-file override to point only your own computer at the destination IP. That latter method requires care with HTTPS, CDN/proxy behaviour and browser caching. It is generally a developer-level option, not a universal beginner recommendation.

Test representative pages rather than only the homepage. A homepage can appear perfect while 404 errors affect old articles, image links point back to the source host and checkout fails because an API endpoint is blocked.

Essential pre-launch test matrix

Scroll to see all table columns →

Disable test-mode artefacts and staging-specific blocks before production launch. When testing a store, use vendor-approved sandbox or test payment methods; do not create accidental live charges.

The pre-cutover acceptance test: make the new copy earn the traffic

A correct-looking homepage proves very little. Before changing public DNS, open the destination through your host's supported preview mechanism or a controlled local hosts-file override. Do not leave a public staging site open to indexing or logins. Confirm both HTTP and HTTPS behaviour and test a second browser profile that has no administrator cookies.

Scroll to see all table columns →

Payment gateways can trigger real charges if a test is run in production mode. Use sandbox/test configurations where supported and check that test orders are clearly segregated from live financial records. Some external webhooks may not function through a local hosts-file preview; record those as post-cutover checks instead of marking them 'passed' prematurely.

DNS decides where a domain resolves. A conventional migration may involve updating an A record for IPv4, an AAAA record for IPv6 or a CNAME for a hostname, depending on the destination's instructions. If you use a proxy such as Cloudflare, the public resolution behaviour may differ from a simple DNS-only record.

Do not change nameservers merely because you are changing hosting. If authoritative DNS is already working through a separate provider, updating the necessary website records is usually simpler. Changing nameservers can silently drop email, TXT authentication or other records if the complete zone is not recreated at the new DNS provider.

A safe cutover procedure

• Save an export or screenshot of the working DNS zone, including website, mail and verification records.
• Confirm the new host's authoritative destination values directly from its control panel.
• Check that the destination site serves the expected domain, has a valid certificate and passes the functional tests.
• Arrange a final content/database sync or write freeze if the site is dynamic.
• Update only the website DNS records necessary to route visitors to the new destination.
• Check resolution from multiple networks or resolvers without assuming a single lookup represents the whole internet.
• Monitor application responses, logs, analytics and important transactions on both hosts.
• Leave the old hosting operational until traffic has stopped reaching it and you are confident the new environment is stable.

Keep MX, SPF, DKIM and DMARC records intact

The website's A record is not the same thing as its MX records, which direct incoming email. SPF, DKIM and DMARC are typically associated with TXT and other DNS records used to authenticate email. A careless DNS reset can make the website appear online while breaking inbound or outbound mail.

Before launch, identify whether your domain mailboxes are hosted by the old web host. If they are, changing website DNS records alone may not move or preserve the mail service indefinitely; you may need a separate mailbox migration and a specific email-provider plan. If email is hosted independently with Google Workspace, Microsoft 365 or another provider, avoid disturbing its working records.

Test an actual inbound and outbound business email after cutover, along with WordPress form notifications. A successful browser page load does not prove email is healthy.

If your DNS is behind Cloudflare or another proxy

Changing web hosting does not always mean changing nameservers. When a site already uses third-party authoritative DNS, keep nameservers unchanged and update the relevant A, AAAA or CNAME records to the new host's supplied destination, accounting for existing proxy settings. A proxied public DNS response may display the proxy network's IP rather than your new origin, so verify origin routing using the DNS dashboard and host logs, not only a public dig result.

Inspect root and www separately, and remove obsolete AAAA records if the new service has no valid IPv6 destination. Do not touch MX records or mail-authentication TXT records merely to move the website. Where DNSSEC is enabled, coordinate any actual nameserver change carefully rather than treating it as an ordinary IP update. Keep the previous hosting account available until the new site and mail delivery are both confirmed.

Google's guidance for a hosting change without visible URL changes is deliberately straightforward: prepare the new infrastructure, update DNS, monitor, and shut down the old host only after the transition is complete. That is different from a domain-change migration.

Preserve URLs, content and canonical signals

If the domain remains the same, keep permalink structure and canonical URLs unchanged. Avoid changing the theme, restructuring navigation, removing content and changing host at the same time. Google advises separating major changes where possible so problems can be attributed and addressed.

Ensure the destination is crawlable when live

Temporary staging may use authentication, noindex or robots restrictions. Those protections must not accidentally be retained on the production site. Check WordPress' search-engine visibility setting, meta robots directives, HTTP headers and robots.txt where relevant. Ensure high-value pages return expected 200 responses rather than 404, 500, 503 or redirect loops.

Verify sitemap and Search Console

Keep the existing sitemap accessible at the expected URL. For a domain-preserving host move, you generally do not need a Change of Address request. That Google feature is for domain or subdomain changes. Monitor Search Console for crawling anomalies, indexing coverage changes and accessibility errors after the move.

Do not panic over brief crawl fluctuations

Google notes that Googlebot's crawl rate can change immediately after switching infrastructure and may recover in subsequent days. Temporary fluctuations are not automatically evidence that a hosting migration destroyed rankings. Persistent server errors, blocked resources or missing pages, however, require investigation.

Changing the domain is a separate project

If your move also changes the public domain or URL paths, implement a deliberate URL mapping and permanent redirects, update internal links and canonical tags, submit the new sitemap and use the relevant Search Console processes. Google recommends maintaining redirects for an extended period, generally at least a year, for URL moves. These extra steps are not required simply because server IP addresses changed.

WooCommerce: do not lose orders during the DNS transition

A store's database can change every minute. New orders, refunds, stock changes, coupons and account updates may happen between the first backup and the final DNS cutover. If the destination is just a copy taken earlier in the day, those changes can disappear from the new store.

Schedule an appropriate maintenance or order-freeze period, use a host-supported final database synchronisation process where available, and reconcile order identifiers and payment-provider records. Be especially cautious about webhook deliveries occurring during the transition: processing the same payment event twice or losing an event can have commercial consequences.

Never overwrite a live destination database with an older dump after accepting new orders. A complex ecommerce migration may justify professional support even when the website's front end looks simple.

Membership and LMS websites

Login sessions, protected content, lesson progress and recurring subscription renewals may be database-dependent. Confirm compatibility with object caching, session storage, background queues and third-party billing APIs. Test users at different permission levels, not only administrator accounts.

WordPress multisite

Multisite introduces networks, domain mapping and additional database tables. Plugin compatibility and host support differ. Do not assume a workflow for a normal single-site WordPress installation is safe for multisite. For example, Cloudways currently documents multisite support on Flexible but not Autonomous. WP-CLI operations also have multisite-specific scoping behaviour.

Large media libraries

A site with many gigabytes of media may exceed browser upload limits or PHP execution time. Choose tools that can handle streaming transfers, server-side archives or direct secure transfer. Verify file counts, media permissions and representative thumbnails; a successful database import does not prove that every image arrived.

Custom code and server-level jobs

Applications can depend on environment variables, background workers, private keys, access-control lists and external service callbacks not stored inside standard WordPress tables. Document and test these independently. A 'full backup' of WordPress files and MySQL data may not preserve every server-level dependency.

Error establishing a database connection

Check DB_NAME, DB_USER, DB_PASSWORD, DB_HOST, user permissions and database server availability. Verify the import completed and the destination database contains the expected tables. Do not publicly disclose configuration secrets while troubleshooting.

Homepage works, but inner pages show 404

Investigate rewrite rules and permalink configuration. On Apache-backed sites, .htaccess may be relevant; on NGINX, routing depends on the server configuration. Saving permalinks can help in some environments but cannot repair an incorrect web-server setup by itself.

Images load from the old server or are broken

Check copied wp-content/uploads files, media paths, permissions, CDN/cache configuration and any absolute references in the database. If the public domain is unchanged, a broad domain replacement is unlikely to be the correct fix. Inspect the actual generated URL first.

The site redirects endlessly

Look for conflicting HTTPS settings, reverse-proxy headers, WordPress URL configuration, CDN SSL modes and overlapping redirection rules. Fix the root cause rather than adding another redirect.

Emails stop arriving

Check MX records and the actual mailbox provider. For WordPress-generated mail, inspect SMTP/API configuration, domain authentication, mail logs and form settings. Website hosting and email hosting should be diagnosed separately.

WordPress is slow on the new host

Compare PHP version, caching, database performance, memory limits, location, object-cache settings and background workloads. Clear or repopulate caches as appropriate and check application errors before assuming the host needs an immediate size upgrade.

The site appears correct in one place but not another

Different DNS resolvers may still send requests to the previous host. Confirm the current authoritative records and query from multiple networks. If the old site remains accessible, keep content consistent during the transition and avoid permanently publishing to both databases independently.

Google suddenly reports inaccessible pages

Check actual HTTP responses, firewall/bot restrictions, robots directives, TLS configuration and server logs. A host change can affect crawler access without changing the page's visible content. Use Search Console's URL Inspection tool for affected pages.

Security cleanup after a successful transfer

Migration commonly involves temporary admin accounts, exported SQL files, backup archives, SSH keys, API tokens and support access. Once the destination is working, revoke no-longer-needed temporary access, rotate credentials shared with migration contractors when appropriate, and remove publicly reachable archives from wp-content, document roots and staging locations. Verify that staging is protected, backups are stored off-site and no credentials were copied into public repositories.

Do not delete the only recent backup while clearing temporary files. Preserve an encrypted, restorable copy under a retention schedule appropriate to the site's content and regulatory obligations. Security cleanup is part of migration completion, not an optional afterthought.

A rollback plan is not pessimism. It is the feature that makes a hosting migration controlled.

Before cutover, identify the condition that would justify rollback: checkout failure, sustained server errors, serious data mismatch, widespread missing pages or an unrecoverable integration failure. Keep the previous host alive with an intact site during the transition.

If a rollback becomes necessary, understand that switching DNS back does not reverse database changes created on the new site. For a dynamic site, reconcile orders, users and other writes before reactivating the source environment. Simply pointing traffic back at an out-of-date database can compound the original problem.

A proper rollback therefore includes application state, content state, DNS routing and communications to the people operating the site. For stores, take special care with payment settlement and order consistency.

How to know whether SEO damage is actually a migration issue

If only the hosting infrastructure changes and public URLs remain the same, Google treats this differently from a domain or URL-pattern move. Google recommends verifying that Googlebot can reach the new host, and checking the new server's load and log behaviour. There is normally no need to install blanket 301 redirects or submit a Change of Address for an unchanged domain.

After switching, inspect a few representative URL responses: the canonical article should return 200, a genuinely missing article should return 404/410 rather than silently redirecting home, and protected admin areas should remain protected. Compare XML sitemap URLs, canonical tags and Search Console coverage. A temporary crawl fluctuation is not proof of a ranking penalty; persistent connection errors, redirect loops or noindex instructions require action.

Immediately after switching

Check the homepage, several posts, checkout or forms, admin login, TLS, critical redirects and actual mail delivery. Verify that external services can reach the application. Watch destination logs for errors.

Over the next one to two days

Inspect new and old traffic, search-crawler errors, abandoned-cart activity, scheduled jobs, order reconciliation and backup completion. Distinguish temporary DNS propagation effects from actual application faults. Maintain active old hosting during the transition.

During the first week

Recheck Search Console coverage and important URLs, review uptime and performance, confirm media and download links, test restoration capabilities and ensure old plugins or hard-coded server references have not been left behind. Record the configuration needed for future maintenance.

Only then cancel the previous hosting

Google recommends keeping the old infrastructure online until you are confident that users and Googlebot are being served correctly by the new one. Confirm source traffic has stopped and exports are securely retained. Keep domain registration and independent mail services unaffected.

Can I migrate WordPress without downtime?

You can often make downtime minimal with staging, a prepared destination and careful DNS cutover. A literal zero-downtime guarantee is unsafe for every situation, especially busy ecommerce or membership systems with writes occurring during the move.

Is it possible to transfer WordPress without a plugin?

Yes. A manual process transfers site files and database content, updates destination database configuration, checks server compatibility and performs a controlled DNS cutover. It requires more technical attention but does not depend on a commercial migration plugin.

Will moving WordPress to a different host hurt SEO?

Not inherently. Google provides a dedicated process for changing hosting without changing URLs. Persistent downtime, blocked crawlers, broken pages or accidental URL changes can create search problems, so test and monitor those elements.

Do I need to change nameservers when I change host?

Usually not if DNS is managed independently and you only need to update website destination records. Follow the actual destination architecture and avoid changing nameservers without preserving all existing DNS records.

How long does DNS propagation take?

It varies with previous TTL settings, resolvers, proxies and cached data. Do not rely on a guaranteed global cutover time. Keep the old host operational through the transition and verify from multiple networks.

Can I keep the same domain and email address?

Yes, in many migrations. Keep the public URL and domain registration unchanged and preserve correct DNS. If email mailboxes reside on the old hosting account, however, you must make a separate plan to retain or move them.

What should I back up before moving WordPress?

At minimum, the complete relevant database and application files, including uploaded media, themes, plugins and necessary configuration. Also record DNS, email arrangements and critical third-party integrations. Store an independent, restorable copy.

Do I need to change WordPress URLs when moving to a new host?

Not when the public URL stays the same. Changing host does not by itself require changing siteurl, home or performing a site-wide domain search-and-replace.

Can I move WooCommerce using a normal migration plugin?

Sometimes, but the technical transfer is only part of the problem. Busy stores require careful management of orders, inventory changes, payment callbacks and the final database cutover. Seek specialist help when order integrity is at risk.

Should I delete the old site immediately?

No. Keep the previous hosting available until DNS, application functionality and traffic have stabilised and you are confident that no users or crawlers depend on it. Retain independent backups according to the site's recovery and data-retention needs.

• ☐ Site, DNS, email and integration dependencies documented.
• ☐ Destination hosting compatible with the site's software and resource needs.
• ☐ Independent full backup of WordPress files and database secured and verified.
• ☐ Migration method and maintenance/final-sync plan chosen.
• ☐ Destination copy installed and tested before cutover.
• ☐ Public URLs, permalinks, SSL, forms, login and critical application functions verified.
• ☐ MX, SPF, DKIM and DMARC preserved or intentionally migrated.
• ☐ DNS records changed deliberately, with original settings retained for rollback.
• ☐ Content and orders reconciled during final cutover.
• ☐ Search Console, crawler access, logs and analytics monitored.
• ☐ New-site backups and recovery process verified.
• ☐ Old hosting cancelled only after stability is established.

WordPress hosting migration is not intrinsically complicated, but it involves more than copying files. The reliable sequence is backup, prepare, migrate, test, synchronise, switch DNS and monitor. Treat business email, customer transactions and search visibility as first-class requirements rather than afterthoughts.

For a typical content site, a reputable host-assisted or plugin migration is usually the sensible choice. For custom infrastructure or high-volume transactions, invest in a documented manual or specialist-assisted plan. Whichever path you choose, keep the old environment available until the destination proves that it can safely handle real visitors.

• WordPress official migration guidance
• WP-CLI search-replace and safe dry-run options
• Google guidance for hosting changes without URL changes
• Google guidance for site moves involving URL changes
• Google documentation for unchanged-URL hosting moves (used for SEO cutover checklist)
• Duplicator official WordPress plugin listing
• Cloudways WordPress Migrator documentation (June 2026)