Summarize this blog post with: ChatGPT | Perplexity | Claude | Grok

Moving a WordPress website to Cloudways may appear as simple as installing a migration plugin and starting a transfer. However, the most consequential work—protecting recent data, testing business-critical functions, changing DNS, restoring email, and monitoring SEO—happens before and after the files move. In this guide, you will learn the complete Cloudways migration process, from method selection and risk assessment to launch verification and rollback planning.

Key Takeaways

A successful Cloudways migration includes preparation, data transfer, pre-DNS testing, controlled cutover, and post-launch monitoring.

• Cloudways migration transfers website files, databases, media, themes, plugins, and application data from a source host to a Cloudways destination application.
• Cloudways WordPress Migrator automates WordPress and WooCommerce transfers using the destination application and SFTP credentials.
• Migration method selection should reflect the CMS, database activity, site size, technical complexity, and acceptable business risk.
• Pre-migration preparation requires a current backup, source-host access, Cloudways credentials, DNS access, compatibility checks, and a documented rollback path.
• Pre-DNS testing identifies broken pages, missing records, checkout failures, email problems, redirect errors, and PHP incompatibilities before visitors reach the new server.
• DNS, SSL, and email configuration remain separate workstreams because copying website data does not automatically reroute the domain or migrate mailboxes.
• Post-migration monitoring should continue until traffic, orders, forms, email delivery, indexing, backups, and application logs remain stable.

[Insert image: Five-stage Cloudways migration lifecycle showing preparation, transfer, testing, cutover, and monitoring | Alt text: “Visualize Cloudways migration from preparation to monitoring”]

What Is Cloudways Migration and How Does It Work?

Cloudways Migration is the process of transferring a website or application from an existing hosting provider to a destination application hosted on Cloudways. The transfer normally includes website files, databases, media, themes, plugins, and other application data required to reproduce the working site on the new server.

The existing provider is the source host, while the Cloudways server and application form the destination environment. A migration copies the site into that destination environment, but the public website normally remains on the source host until you update the domain’s DNS records.

“Migrating a website means moving your website data from your current hosting provider to Cloudways.”

— Syed Abuzar Mehdi, Cloudways Help Center Author, Cloudways Help Center, 2026

The quotation matters because it separates data movement from the broader go-live process. A completed file transfer is not yet a completed hosting migration.

The five stages of a complete Cloudways website migration

A reliable Cloudways website migration follows five stages:

1. Prepare: Back up the source, audit compatibility, gather credentials, and create a rollback plan.
2. Transfer: Copy the website using the Cloudways WordPress Migrator, an expert-managed request, or a manual process.
3. Test: Validate the copied website through its temporary URL or a local hosts-file override.
4. Cut over: Point DNS to Cloudways, issue SSL, configure email, and purge caches.
5. Monitor: Review transactions, forms, logs, indexing, performance, and traffic on both servers.

Cloudways WordPress migration involves copying the site’s files, database, media, plugins, themes, and relevant settings to a Cloudways application and validating the copy before changing DNS.

What Cloudways migration does not automatically complete

A website transfer does not necessarily migrate or configure:

• Domain registration
• DNS hosting
• Domain mailboxes
• MX, SPF, DKIM, or DMARC records
• Transactional email delivery
• Third-party CDN settings
• External cron jobs
• Payment webhooks
• SaaS integrations
• License activations tied to the old domain or server IP
• Monitoring and analytics configuration

For example, a WooCommerce store can display correctly after migration while order-confirmation emails fail because the SMTP service was not configured on the new server.

Why Should You Migrate Your Website to Cloudways?

Website owners usually migrate to Cloudways when their current environment no longer provides the required performance, scalability, administrative control, or operational reliability. The business objective is not merely to change hosts; it is to establish an environment that can support traffic, transactions, development workflows, and future growth without introducing unacceptable migration risk.

Common migration triggers include:

• Shared-hosting CPU or memory restrictions
• Slow backend or checkout performance
• Traffic spikes that exceed current resources
• Expensive renewal pricing
• Limited staging or development workflows
• Inflexible PHP or server configurations
• Unreliable support
• Growing WooCommerce database activity
• Requirements for Redis, Varnish, SSH, or WP-CLI
• Agency requirements for managing multiple client applications

A detailed Cloudways review can help you evaluate the platform before committing to the migration. You should also review the current Cloudways features rather than assuming that every product tier provides the same architecture or controls.

→ Explore Cloudways Features

Migration quality affects revenue and business continuity

Migration quality determines whether visitors can continue browsing, submitting forms, logging in, and completing purchases after the cutover. For example, a missing WooCommerce database table may not affect the homepage, but it can prevent checkout, subscription renewals, or inventory updates.

Migration quality also affects:

• Customer trust
• Payment completion
• Advertising conversion tracking
• Affiliate click attribution
• Search-engine crawling
• Staff access
• Transactional email
• API and webhook processing
• Recovery time when something fails

A low-downtime website migration involves preparing the destination, testing the migrated copy, synchronizing recent data, changing DNS, and retaining the original server until the new environment is verified.

Cloudways Flexible and Autonomous require different decisions

Cloudways Flexible and Cloudways Autonomous are separate hosting products with different architectures and application limitations. Current Cloudways documentation states that WordPress Multisite is supported on Cloudways Flexible but not on Cloudways Autonomous, making product selection a migration prerequisite rather than a post-purchase detail.

→ Evaluate Cloudways for Your Site

Review the Cloudways Flexible vs. Autonomous comparison before launching the destination application. The wrong destination product can force you to restart the migration or redesign part of the application.

Is Cloudways Website Migration Free?

Cloudways currently documents unlimited no-cost self-service migrations for WordPress and WooCommerce through the Cloudways WordPress Migrator. A June 2026 Help Center article also states that expert-managed WordPress and WooCommerce migrations are free, while non-WordPress applications may incur charges or use plan-based migration allowances.

Cloudways lists the following policy in its current managed-migration documentation:

The non-WordPress price and plan allowances above were stated by Cloudways in March 2026 — Source: Cloudways Help Center, 2026.

Cloudways’ official pages currently contain conflicting wording

Cloudways’ migration pricing should be verified in the user dashboard because two official sources currently describe expert-migration eligibility differently. The Help Center says expert WordPress and WooCommerce migrations are free, but the public migration landing page says the first expert-handled website migration is free.

This discrepancy matters for agencies migrating several sites. Before promising a client unlimited expert migrations, open Integrations → Application Migration and confirm the entitlement displayed in the active Cloudways account.

For current hosting costs, compare the destination options through the Cloudways pricing guide. When you are ready to evaluate the live offer, compare current Cloudways hosting plans before creating the destination server.

Which Cloudways Migration Method Should You Choose?

The best Cloudways migration method is the method that matches the website’s platform, size, dynamic-data risk, technical complexity, and available expertise. The WordPress Migrator suits many standard sites, expert-managed migration reduces operational burden, and manual migration provides maximum control for custom or technically unusual applications.

Cloudways migration method decision matrix

Cloudways offers both the Migrator plugin and an application-migration request through its platform. The plugin is limited to WordPress and WooCommerce, while the managed request accepts connection methods including SSH, SFTP, FTP, cPanel, and other hosting access.

Use the Cloudways WordPress Migrator when

Choose the Migrator plugin when:

• The website uses a standard WordPress installation.
• You have WordPress administrator access.
• The source site is stable and publicly accessible.
• The site does not contain unusual external databases.
• You can test the migrated copy yourself.
• You understand how to manage DNS, SSL, email, and final validation.

The Cloudways WordPress Migrator is a self-service plugin that uses destination application and SFTP details to automate WordPress and WooCommerce migrations. Cloudways’ official plugin page also states that the plugin migrates only to Cloudways.

Use Cloudways managed migration when

Choose expert-managed migration when:

• The website is unfamiliar to you.
• The site generates substantial revenue or leads.
• The database changes continuously.
• The site uses memberships, subscriptions, bookings, or marketplaces.
• The application has custom directories or multiple databases.
• The source host applies strict security controls.
• The website uses a complex WordPress Multisite setup.
• A client requires documented testing and accountability.

Managed migration does not eliminate the need for your own acceptance testing. Cloudways asks users to specify checks such as login, add-to-cart, checkout, redirects, and custom SSL requirements in the migration request.

Use manual migration when

Choose manual migration when:

• The application is not WordPress.
• The source installation is inaccessible through WordPress.
• The plugin repeatedly fails on a technically healthy source.
• You need selective file or database movement.
• The project requires custom deployment steps.
• You must preserve external storage, workers, queues, or unusual cron jobs.
• You require a repeatable command-line migration runbook.

A typical manual WordPress migration involves:

1. Exporting the source database.
2. Downloading or synchronizing website files.
3. Importing the database into the Cloudways application.
4. Updating database credentials in wp-config.php.
5. Running a serialization-safe URL search-and-replace.
6. Reviewing permissions and ownership.
7. Testing the application before DNS changes.
8. Performing a final synchronization for recent data.

Readers who have not selected a destination host should compare Cloudways alternatives before beginning. Changing the destination after preparation can invalidate testing, credentials, and server-sizing decisions.

What Do You Need Before Migrating a Website to Cloudways?

A Cloudways migration requires a verified backup, a working destination application, administrative access, server credentials, DNS control, compatibility checks, and a rollback plan. Preparation should also identify mail services, dynamic database activity, tracking integrations, external APIs, and business-critical workflows that cannot be judged from the homepage alone.

Use the following WordPress migration checklist as your project record.

Cloudways pre-migration checklist

• Full source-file backup completed
• Current database backup completed
• Backup downloaded or stored outside the source account
• Backup restoration method verified
• Cloudways account active
• Destination server and application created
• Correct Cloudways product selected
• Appropriate server region selected
• WordPress administrator credentials available
• SSH, SFTP, FTP, or cPanel access available
• Cloudways destination URL recorded
• Cloudways server IP recorded
• Database name recorded
• SFTP username and password recorded
• Source and destination PHP versions reviewed
• WordPress, theme, and plugin compatibility reviewed
• Premium licenses inventoried
• Custom .htaccess rules documented
• DNS-provider access confirmed
• Existing A, CNAME, MX, SPF, DKIM, and DMARC records exported
• Current DNS TTL recorded
• Email mailboxes and SMTP provider documented
• GA4 and Search Console baseline recorded
• Critical forms and transactions documented
• Maintenance window selected
• Content or order freeze planned where necessary
• Rollback owner and decision deadline assigned
• Old hosting cancellation postponed

Create a restorable copy using the WordPress backup guide before installing migration software or modifying DNS.

Record a pre-migration technical baseline

A pre-migration baseline allows you to distinguish migration defects from existing website problems. For example, an existing 3.5-second Largest Contentful Paint should not be reported as a Cloudways migration regression when the new environment records 2.8 seconds.

Record:

A Cloudways performance guide can help you evaluate post-migration results without attributing every improvement or regression to the hosting provider.

Calculate your migration risk score

A migration risk score is a practical way to decide whether self-service migration is appropriate. Assign one point for each condition below:

• Database changes every few minutes
• WooCommerce orders or inventory updates
• Memberships or subscriptions
• WordPress Multisite
• More than one database
• Large media library
• Custom PHP or must-use plugins
• Multilingual or multi-currency configuration
• External APIs or payment webhooks
• Background queues or server cron jobs
• Complex redirects or .htaccess rules
• Mailbox or transactional-email dependence
• Limited rollback access
• No experienced technical reviewer

Use these thresholds:

• 0–3 points: Standard self-service migration is usually reasonable.
• 4–7 points: Use enhanced testing and consider managed migration.
• 8 or more points: Prefer expert-managed or developer-led migration with a formal cutover plan.

The score is an operational framework, not a Cloudways policy. A single critical condition—such as an active subscription platform—can justify managed migration even when the total score is low.

How Do You Migrate WordPress to Cloudways With the Migrator Plugin?

You migrate WordPress to Cloudways by creating a destination application, installing Cloudways WordPress Migrator on the source site, entering the destination URL and SFTP/database details, starting the transfer, and testing the copied website before changing DNS. The plugin currently supports WordPress and WooCommerce migrations to Cloudways.

Watch the Cloudways WordPress Migration Process

This official Cloudways walkthrough demonstrates how to create the destination environment and migrate an existing WordPress website using the Cloudways WordPress Migrator plugin. Watch it once for the complete workflow, then follow the detailed steps and validation checks below.

Video: “How to Migrate Your WordPress Site to Cloudways | Cloudways 101” by Cloudways.

Step 1: Launch the Cloudways destination application

Create a fresh WordPress application on the appropriate Cloudways product and server. The application can run on a new server or an existing server, but the server should have enough capacity for both current traffic and migration processing.

Record the following details:

• Destination application URL
• Public server IP
• Database name
• SFTP username
• SFTP password
• WordPress admin URL
• Application or master credentials
• Destination PHP version

[Insert image: Cloudways application Access Details screen with the destination URL, server IP, database name, and SFTP credentials highlighted | Alt text: “Find Cloudways migration credentials in Access Details”]

Step 2: Verify the empty destination application

Log into the destination WordPress installation before migration. Confirm that:

• WordPress loads successfully.
• The dashboard is accessible.
• The expected PHP version is active.
• No unrelated production content exists.
• The destination can be overwritten safely.

Cloudways warns that existing application data on the selected target can be overwritten during a managed migration. The same caution should guide self-service projects: never migrate into an application containing data you need to preserve.

Step 3: Install Cloudways WordPress Migrator on the source

On the existing WordPress website:

1. Open Plugins → Add New.
2. Search for Cloudways WordPress Migrator.
3. Select Install Now.
4. Activate the plugin.
5. Open the migration wizard.

The plugin can also be installed through WP-CLI with the WordPress.org-listed package slug.

[Insert image: WordPress Add Plugins screen displaying Cloudways WordPress Migrator | Alt text: “Install Cloudways WordPress Migrator on the source website”]

Step 4: Enter the destination and connection details

The current Cloudways migration workflow asks for:

• Email address for status notifications
• Cloudways product or environment
• Destination site URL
• SFTP host or server IP
• Database name
• SFTP username
• SFTP password
• HTTP authentication status
• Optional custom root directories
• Optional additional database tables
• Source-site password-protection details

Cloudways says these values are available through the application’s Access Details and server credentials areas.

Use Yes for additional root directories only when the source contains required custom directories outside the standard WordPress structure. Use Yes for additional tables when plugins, multisite networks, or custom systems store required data outside the normal table selection.

[Insert image: Cloudways Migrator wizard showing destination URL, SFTP host, database name, username, and advanced migration options | Alt text: “Configure Cloudways WordPress migration destination fields”]

Step 5: Handle password protection correctly

Password protection means frontend restrictions, not the normal WordPress administrator login. HTTP Basic Authentication, maintenance-mode plugins, and frontend access-control plugins can block migration connections.

If migration fails at connection or scanning:

1. Temporarily disable HTTP authentication.
2. Disable maintenance mode.
3. Disable frontend password-protection plugins.
4. Confirm that the destination is externally reachable.
5. Retry the migration.
6. Restore the restrictions after testing.

Cloudways specifically identifies HTTP authentication and frontend restrictions as potential migration blockers.

Step 6: Start and monitor the transfer

Start the migration only after checking every field. Do not close the source site, modify the destination, or update DNS while the plugin is transferring data.

Migration duration depends on:

• Total file size
• Number of files
• Source-server performance
• Source-host connection limits
• Database size
• Network throughput
• Security scanning
• Migration queue status

Cloudways does not promise one universal plugin duration. Its public managed-migration page says expert migrations are usually completed within one to two business days, depending on complexity — Source: Cloudways, 2026.

Step 7: Review the completion result

After completion:

• Open the Cloudways-hosted copy.
• Log into WordPress.
• Confirm themes and plugins.
• Review media.
• Regenerate permalinks when necessary.
• Purge application and Varnish caches.
• Check error logs.
• Begin the full acceptance test.

Cloudways recommends testing the migrated site and purging Varnish if an outdated copy appears.

How Do You Request an Expert-Managed Cloudways Migration?

You request an expert-managed Cloudways migration through the Application Migration area under Integrations, select the destination application, provide source-site and connection credentials, define required checks, and submit the request for review. Accurate credentials and explicit acceptance criteria reduce delays and prevent important workflows from being overlooked.

Step 1: Open the Application Migration request

In the current Cloudways interface:

1. Log into Cloudways.
2. Open Integrations.
3. Select Application Migration.
4. Review the migration service details.
5. Select the option to submit or migrate an application.

Cloudways’ documentation uses slightly different button labels across current Help Center pages, including Submit Your Application and Migrate Your Application. Follow the label displayed in your account rather than relying on an older screenshot.

[Insert image: Cloudways Integrations screen with Application Migration selected | Alt text: “Request Cloudways managed migration from Integrations”]

Step 2: Select the destination application

Select:

• Cloudways product
• Destination server
• Destination application
• Application type

Verify that the destination does not contain valuable data. The migration can overwrite the target application.

Step 3: Enter site and administrator details

Provide:

• Primary application domain
• CMS or backend URL
• Administrator username
• Administrator password
• Subsite information
• Back-office details for custom applications

A subsite or nested application with a separate database may be treated as an additional migration. Document the architecture before submitting the request.

Step 4: Provide source-server connection details

Cloudways accepts connection types such as:

• SSH
• SFTP
• FTP
• cPanel
• Other hosting access
• Downloadable backup, when arranged with support

For SSH, SFTP, or FTP, provide the correct hostname, port, username, and password. When database access is separate, include the phpMyAdmin or database credentials requested by the form.

Cloudways recommends SSH where possible because it generally provides a stable and secure transfer channel.

Step 5: Define specific acceptance checks

Do not write only “please migrate the website.” Include a test list such as:

• Homepage and key landing pages
• WordPress administrator login
• Customer login
• Add-to-cart
• Checkout
• Payment gateway callback
• Subscription renewal
• Search and filters
• Contact forms
• Transactional email
• Redirect rules
• Member-only pages
• Multisite subsites
• Custom API integrations
• Custom SSL requirements

Cloudways’ request form explicitly allows users to specify checks such as add-to-cart and login behavior.

Step 6: Protect the credentials after migration

After acceptance:

• Change temporary administrator passwords.
• Change source-server credentials shared for migration.
• Revoke temporary SFTP users.
• Remove shared backup links.
• Delete unused administrator accounts.
• Review Cloudways team access.
• Confirm that credential copies are not stored in tickets longer than necessary.

Cloudways states that migration-form data is deleted after 30 days, but credential rotation remains a sensible security measure.

How Do You Migrate a WooCommerce Store Without Losing New Orders?

A WooCommerce store requires an initial migration followed by a controlled content freeze or final database synchronization before DNS cutover. Without that final synchronization, orders, inventory changes, registrations, subscriptions, refunds, and customer updates created after the first database copy may remain only on the old server.

Use the initial-copy and final-sync framework

A low-risk WooCommerce cutover follows this sequence:

1. Migrate the full store while the source remains live.
2. Test products, accounts, checkout, taxes, shipping, and payment flows.
3. Select a low-traffic launch window.
4. Announce a brief checkout or administrative freeze when necessary.
5. Record the last accepted order ID and timestamp.
6. Perform the agreed final database synchronization.
7. Stop writes to the source.
8. Update DNS.
9. Purge all cache layers.
10. Place a controlled test order on the new server.
11. Verify inventory, payment, email, and webhooks.
12. Keep the old server accessible for rollback.

The Cloudways Migrator plugin’s changelog references WooCommerce dynamic-sync support, but the exact behavior and eligibility for the current project should be confirmed before relying on it for active order data.

Define which WooCommerce data can change

Inventory every write-sensitive data source:

• Orders
• Order notes
• Customer accounts
• Product stock
• Coupon usage
• Subscriptions
• Membership status
• Bookings
• Refunds
• Payment tokens
• Download permissions
• Form entries
• Abandoned-cart records
• Analytics events
• Webhook delivery logs

For example, copying the database at 10:00 p.m. and changing DNS at midnight can lose two hours of orders unless those writes are synchronized or checkout is paused.

Validate the complete purchase lifecycle

Test more than the cart page:

1. Create a new customer account.
2. Add a physical or digital item.
3. Apply a valid coupon.
4. Estimate tax and shipping.
5. Complete a test transaction.
6. Confirm the order in WordPress.
7. Verify the payment provider.
8. Confirm stock reduction.
9. Check customer and administrator emails.
10. Process a refund or cancellation where safe.
11. Confirm webhook delivery.
12. Check subscription or membership activation.

A store should not go live merely because the homepage and product pages render correctly.

How Do You Migrate WordPress Multisite to Cloudways?

WordPress Multisite migration requires a compatible Cloudways destination, matching network structure, complete database-table transfer, correct primary-domain configuration, and hosts-file testing before DNS changes. Current Cloudways documentation states that Multisite is supported on Cloudways Flexible but not on Cloudways Autonomous.

Enable Multisite on the destination first

Before running the Migrator:

1. Open the destination application.
2. Go to Application Settings.
3. Open the WordPress settings area.
4. Enable WordPress Multisite.
5. Match the source network type:
   • Subdomain network
   • Subdirectory network

Do not enable Multisite experimentally on an application containing data. Cloudways describes Multisite activation as an action that requires significant manual work to reverse.

Configure the primary domain before transfer

Add the source network’s primary domain to the destination application and set it as the primary domain. For Multisite migration, Cloudways instructs users to enter the real primary domain—not the temporary Cloudways URL—as the destination URL in the migration wizard.

Include all required database tables

Set Migrate Additional Database Tables to Yes and include the entire Multisite table set. Missing blog-specific tables can produce partial networks where the primary site works but one or more subsites fail.

Also review:

• wp_blogs
• wp_site
• wp_sitemeta
• Subsite posts and options tables
• Domain-mapping plugin tables
• User and user-meta tables
• Custom network plugin tables

Select the correct web stack

Cloudways currently documents two stacks:

• Hybrid Stack: NGINX and Apache, with .htaccess support
• Lightning Stack: NGINX-only, without .htaccess support

If the source network depends on .htaccess rewrite rules, Cloudways recommends selecting Hybrid Stack. This distinction is particularly important for subdirectory Multisite networks and custom redirect configurations.

Test every subsite through the hosts file

Test:

• Network dashboard
• Primary site
• Every representative subsite
• Subdomain or subdirectory routing
• Domain mapping
• Media paths
• Login cookies
• Network-activated plugins
• User roles
• Redirects
• SSL behavior

Cloudways specifically recommends local hosts-file testing for Multisite before public DNS changes.

How Do You Test a Migrated Cloudways Website Before Changing DNS?

You test a migrated Cloudways website by opening the temporary application URL or mapping the production domain to the Cloudways IP in your local hosts file, then validating content, administration, transactions, email, logs, redirects, and dynamic functionality. Public DNS should remain unchanged until the destination passes the acceptance checklist.

“First, upload a copy of your site to your new hosting provider.”

— Google Search Central Documentation Team, Search Documentation Publisher, Google Search Central, 2026

Google’s sequence is important: copy and test first, change DNS second, monitor both environments third, and retire the old host only after traffic has moved successfully.

Test with the Cloudways temporary URL

The temporary Cloudways application URL is useful for:

• Basic page rendering
• WordPress dashboard access
• Media-library checks
• Plugin activation
• PHP compatibility
• Initial log review

However, some applications behave differently on a temporary domain. Absolute URLs, cookie scopes, licensing systems, payment callbacks, Multisite routing, and HTTPS integrations may require the real domain.

Test with a local hosts-file override

A hosts-file override makes your own computer resolve the production domain to the Cloudways server while public visitors continue reaching the old host.

“It is a critical step in doing the final DNS changes and taking your site(s) live from Cloudways.”

— Usama Zafar, Cloudways Help Center Author, Cloudways Help Center, 2024

Hosts-file testing provides a more realistic preview because WordPress loads under the intended domain.

For Windows:

1. Open Notepad as Administrator.
2. Open the system hosts file.
3. Add the Cloudways IP followed by the root and www domains.
4. Save the file.
5. Flush local DNS if necessary.
6. Open the website in a private browser window.
7. Remove the hosts entry after public DNS has changed.

Cloudways documents the Windows hosts-file location and advises removing the temporary entry after cutover.

[Insert image: Windows hosts file mapping a production domain and www hostname to a Cloudways server IP | Alt text: “Test Cloudways migration with a local hosts file”]

Complete the pre-DNS acceptance checklist

Content and media

• Open the homepage.
• Open major landing pages.
• Check blog posts and category archives.
• Test image, video, PDF, and download links.
• Confirm menus, widgets, and footer content.
• Check multilingual versions.

WordPress administration

• Log into WordPress.
• Create and update a draft.
• Upload a test image.
• Save plugin settings.
• Confirm scheduled tasks.
• Review Site Health.
• Check error logs.

Dynamic functionality

• Submit every important form.
• Test search and filters.
• Test customer or member login.
• Test password reset.
• Test add-to-cart and checkout.
• Test subscriptions or bookings.
• Confirm API calls and webhooks.

Technical validation

• Check response codes.
• Crawl for broken links.
• Review browser-console errors.
• Inspect mixed content.
• Confirm canonical tags.
• Confirm robots directives.
• Verify XML sitemap availability.
• Confirm analytics and tag-manager scripts.
• Compare database record counts.
• Purge caches and test again.

Google recommends reviewing pages, images, forms, downloads, Search Console verification, and Googlebot access before completing a hosting change.

How Do You Point Your Domain to Cloudways and Configure SSL, Email, and Cache?

You take a migrated Cloudways site live by adding the primary domain, updating the appropriate DNS records, preserving mail-related records, installing SSL, configuring transactional email or mailboxes, and purging every active cache layer. DNS should be changed only after the destination has passed functional testing.

Lower the DNS TTL before the cutover

Lowering the Time to Live can reduce how long recursive DNS systems retain the old server record. Google recommends lowering the TTL to a conservative low value in advance of a hosting move, ideally early enough for existing cached values to expire.

A practical approach is:

• Review the current TTL at least several days before migration.
• Lower it to a value supported by the DNS provider, such as one hour.
• Wait for the previous TTL to expire.
• Perform the cutover.
• Restore a normal TTL after the migration stabilizes.

Do not lower TTL immediately before changing DNS and assume every resolver will update quickly. Resolvers may still hold the previous value.

Add the primary domain to Cloudways

In the destination application:

1. Open Domain Management.
2. Add the root domain.
3. Add required aliases.
4. Make the production domain primary.
5. Copy the server IP or Cloudways-provided target.

Cloudways’ current documentation says the www version may be added automatically when the root domain is added, but you should verify the actual domain list before changing DNS.

[Insert image: Cloudways Domain Management screen with the production domain set as primary | Alt text: “Set the primary domain after Cloudways migration”]

Watch How to Point Your Domain and Install SSL

This official Cloudways tutorial shows how to map your production domain, configure the required DNS records, and activate a Let’s Encrypt SSL certificate. The registrar interface may differ, but the underlying A-record, primary-domain, and HTTPS workflow remains the same.

Video: “How to Point Domains and Install SSL Certificates on Cloudways | Cloudways 101” by Cloudways.

Update A and CNAME records carefully

A common configuration uses:

• Root domain: A record pointing to the Cloudways server IP
• www hostname: A record or provider-supported CNAME pointing to the intended production target
• Other subdomains: Existing records preserved unless they also move

Cloudways’ current A-record guide shows A records for root, www, subdomain, and wildcard configurations. It states that worldwide propagation can take 24–48 hours, although many users see changes sooner — Source: Cloudways Help Center, 2025.

[Insert image: DNS management panel showing the root A record and www record pointing to Cloudways | Alt text: “Update DNS records for Cloudways migration”]

Preserve MX, SPF, DKIM, and DMARC records

Do not replace the entire DNS zone merely to update web hosting. Preserve:

• MX records
• SPF TXT records
• DKIM TXT or CNAME records
• DMARC TXT records
• Mail-autodiscovery records
• Domain-verification records
• SaaS verification records

For example, changing nameservers without recreating Microsoft 365 MX and TXT records can make the website work while stopping company email.

Install SSL after domain routing is valid

Cloudways provides Let’s Encrypt SSL for applications and supports custom certificates. Its documentation states that Let’s Encrypt certificates renew automatically, and HTTPS redirection should be enabled after installation.

The cutover sequence should be:

1. Confirm the domain resolves correctly.
2. Install Let’s Encrypt or the custom certificate.
3. Enable HTTPS redirection.
4. Confirm WordPress Address and Site Address use HTTPS.
5. Check the browser padlock.
6. Test HTTP-to-HTTPS redirects.
7. Scan for mixed content.
8. Purge cache.

[Insert image: Cloudways SSL Certificate screen showing a valid Let’s Encrypt certificate and HTTPS redirection | Alt text: “Install SSL after Cloudways website migration”]

Treat email as a separate migration workstream

Cloudways distinguishes transactional email from domain mailboxes. Elastic Email or a custom SMTP integration can send application-generated messages, while Rackspace Email provides mailboxes for sending and receiving business email.

Cloudways currently allows one server-level transactional email add-on at a time: Elastic Email or the SMTP add-on. Rackspace is a separate mailbox service.

[Insert image: Cloudways email add-on screen comparing Elastic Email, SMTP, and Rackspace options | Alt text: “Configure Cloudways email services after migration”]

Purge every cache layer

Purge:

• WordPress page cache
• Breeze cache
• Varnish
• Redis object cache
• Cloudflare or another CDN
• Host-level cache
• Browser cache
• Local DNS cache

Cloudways provides an application-level Purge Site Cache function and separate Varnish controls. Cache purging may briefly increase response time while caches rebuild.

[Insert image: Cloudways Application Settings screen with Purge Site Cache highlighted | Alt text: “Purge Cloudways cache after DNS cutover”]

How Do You Troubleshoot a Failed Cloudways Migration?

Cloudways migration troubleshooting starts by identifying whether the failure occurs during authentication, file transfer, database transfer, application execution, domain routing, SSL, email, or caching. Troubleshoot one layer at a time and preserve the source website until the destination passes all critical checks.

Cloudways migration troubleshooting table

Fix incorrect SFTP credentials

Test the Cloudways SFTP credentials in a separate client before retrying the Migrator. Confirm:

• Server IP
• SFTP protocol
• Port
• Username
• Password or SSH key
• IP allowlisting
• Application or master credential type

Cloudways notes that SFTP failures and timeouts can result from network, credential, software, or IP-access restrictions.

Fix large-site migration failures

For a large website:

• Remove obsolete backups from the WordPress directory.
• Exclude cache directories.
• Check source disk space.
• Check inode limits.
• Disable heavy security scans temporarily.
• Schedule the transfer outside peak traffic.
• Use SSH, rsync, or a managed migration when appropriate.
• Transfer the database separately when the plugin repeatedly fails.

Do not permanently delete the only backup to make room. Move the backup to independent storage first.

Fix broken images and serialized URLs

A raw SQL replace can corrupt serialized values. Use a WordPress-aware search-and-replace process such as WP-CLI or a compatible database tool.

Check for:

• Old source-domain URLs
• Temporary Cloudways URLs
• HTTP asset references
• Upload directories outside wp-content/uploads
• CDN hostnames
• Builder-generated CSS files
• Multisite upload paths

After replacement, regenerate builder assets where applicable and purge all caches.

Fix mixed content

Mixed content occurs when an HTTPS page loads images, stylesheets, scripts, or other resources through HTTP. Cloudways recommends reviewing insecure asset URLs and fixing the affected WordPress references after SSL installation.

Use browser developer tools to identify the exact asset. Do not install multiple SSL-fixing plugins without first determining whether the source is the database, theme, CDN, or cache.

Use a rollback decision tree

Rollback when any of the following remains unresolved within the launch window:

• Checkout cannot complete.
• New orders are missing.
• Payment webhooks fail.
• Customer login is broken.
• Critical forms fail.
• Severe redirect loops persist.
• Core pages return server errors.
• Multisite routing is incomplete.
• The destination database is inconsistent.
• DNS points to an inaccessible server.

Do not roll back only because one noncritical image or cosmetic style is imperfect. Record minor issues and fix them after stabilizing business-critical functionality.

A rollback should normally include:

1. Stop writes on the failed destination.
2. Point DNS back to the verified source.
3. Purge DNS and CDN caches where possible.
4. Confirm the source is serving current data.
5. Reconcile transactions created during the failed window.
6. Investigate before scheduling another cutover.

Will Migrating to Cloudways Affect Your SEO Rankings?

Changing hosting providers without changing public URLs should not inherently require a ranking loss, but technical migration errors can disrupt crawling, indexing, page delivery, redirects, analytics, and user experience. Google recommends copying and testing the new environment, updating DNS, monitoring both servers, and shutting down the old host only after traffic has moved correctly.

Keep the URL structure unchanged

Preserve:

• Page and post URLs
• Trailing-slash behavior
• HTTPS status
• Canonical URLs
• Redirect destinations
• Pagination
• Category and tag structures
• Image URLs where practical
• XML sitemap location

When the domain and URLs remain unchanged, you generally do not need a site-wide set of new 301 redirects. Redirects are required only for URLs that actually change.

Prevent accidental indexing of the temporary site

A temporary public hostname can create duplicate-content or indexing risks. Google recommends applying noindex to a publicly accessible temporary environment and removing that block before the new environment becomes the live serving infrastructure.

Check that the production destination does not retain:

• noindex
• A staging robots.txt block
• HTTP Basic Authentication
• IP restrictions
• A maintenance-mode response
• Canonicals pointing to the temporary URL

Monitor Search Console and server logs

After cutover, review:

• URL Inspection
• Page indexing
• Crawl statistics
• Sitemap processing
• Core Web Vitals
• HTTPS reports
• Manual actions
• Security issues
• Server logs on both hosts
• 404 and 5xx responses

Google states that a temporary fluctuation in Googlebot crawl rate can occur after a hosting change. A short fluctuation is not automatically a ranking problem, but persistent crawl errors require investigation.

Compare traffic and rankings correctly

Compare equivalent periods and account for:

• Day-of-week patterns
• Seasonality
• Campaign changes
• Search updates
• Tracking-code changes
• Consent-banner behavior
• CDN changes
• Cache warming
• Server location
• PHP version
• Plugin changes made during migration

Use the Core Web Vitals optimization guide when interpreting performance changes, and avoid claiming that hosting alone caused every measured improvement.

Which Tools Help With Cloudways Migration and Validation?

Cloudways migration tools help transfer files, inspect databases, test DNS, validate application behavior, measure performance, and monitor search visibility. The best toolkit combines Cloudways’ native migration features with open protocols, browser diagnostics, Google tools, and independent testing rather than depending on one migration-completion message.

Standard WordPress blog example

A 5 GB affiliate blog with infrequent comments and no membership system is usually a suitable Migrator-plugin project.

A practical workflow is:

1. Back up the source.
2. Create the destination.
3. Run the Migrator.
4. Test pages, media, affiliate links, forms, and analytics.
5. Update DNS.
6. Install SSL.
7. Configure SMTP.
8. Purge caches.
9. Crawl the site.
10. Monitor Search Console and GA4.

The risk remains moderate because content changes are relatively infrequent and can be paused during cutover.

Dynamic WooCommerce example

A 40 GB WooCommerce store with daily orders, live inventory, subscriptions, and payment webhooks should use managed or developer-led migration.

The project should include:

• Initial full copy
• Checkout-flow testing
• Subscription testing
• Payment-webhook testing
• Defined content-freeze window
• Final database synchronization
• Last-order ID comparison
• Post-cutover test purchase
• Inventory reconciliation
• Extended monitoring

The migration method matters less than the quality of the final synchronization and acceptance test.

Host-specific preparation notes

A detailed Cloudways vs. GoDaddy comparison can help readers understand why a GoDaddy migration may involve separate domain, DNS, hosting, and email control panels.

[Insert image: Composite checklist showing cPanel, SiteGround, Hostinger, GoDaddy, Kinsta, and WP Engine migration preparation areas | Alt text: “Compare source host settings before Cloudways migration”]

What Should You Do After Migrating to Cloudways?

Post-migration work should validate availability, dynamic transactions, email delivery, SEO signals, backups, performance, and security before the previous hosting account is cancelled. Monitoring should be organized by urgency because checkout failures require immediate action, while long-term performance tuning can wait until the new environment is stable.

First-hour checklist

During the first hour:

• Confirm the root and www domains.
• Confirm HTTPS and redirects.
• Submit priority forms.
• Test login and password reset.
• Complete a safe test transaction.
• Confirm transactional emails.
• Confirm analytics activity.
• Review PHP and web-server logs.
• Check uptime monitoring.
• Purge caches after any correction.
• Watch traffic on both servers.

First 24-hour checklist

During the first 24 hours:

• Review new orders and registrations.
• Reconcile inventory.
• Confirm cron jobs.
• Check payment webhooks.
• Check email bounce or spam behavior.
• Crawl the website.
• Review 404 and 5xx responses.
• Confirm sitemap and robots.txt.
• Check Search Console.
• Confirm backup scheduling.
• Compare performance with the baseline.

First 72-hour checklist

During the first 72 hours:

• Review traffic on both old and new hosts.
• Confirm major DNS resolvers use Cloudways.
• Compare order and lead volume.
• Review error logs daily.
• Verify scheduled content and automated tasks.
• Check third-party integrations.
• Review ranking and indexing anomalies.
• Confirm the old server is no longer receiving meaningful public traffic.
• Document every corrected issue.

Google recommends monitoring logs on both servers and shutting down the previous infrastructure only after traffic to the old host reaches zero.

Seven-day checklist

Within seven days:

• Recheck backups and perform a restoration review.
• Remove the migration plugin when no longer needed.
• Remove temporary administrator accounts.
• Rotate exposed credentials.
• Restore normal DNS TTL.
• Review Cloudways security settings.
• Tune Redis, Varnish, CDN, and page cache.
• Re-run performance tests.
• Review Core Web Vitals.
• Review crawl and indexing reports.
• Archive the migration documentation.
• Decide whether the old hosting can be cancelled.

Use the Cloudways security guide for hardening and the WordPress speed optimization guide for post-stabilization tuning.

What Are the Next Steps After a Successful Cloudways Migration?

The next step after a successful Cloudways migration is to stabilize the environment before making performance, plugin, design, or infrastructure changes. Keeping the first few days operationally quiet makes it easier to determine whether an error came from the migration or from an unrelated optimization introduced afterward.

Follow this order:

1. Complete functional acceptance.
2. Monitor the new and old servers.
3. Confirm backups.
4. Rotate credentials.
5. Document the destination configuration.
6. Remove obsolete migration components.
7. Begin security hardening.
8. Tune performance one change at a time.
9. Cancel the old host only after final confirmation.

Do not combine migration day with a theme redesign, plugin overhaul, PHP major-version change, CDN replacement, and URL restructuring. Each simultaneous change expands the troubleshooting surface.

Readers still selecting a destination can review the broader Cloudways platform guide and verify the current Cloudways coupon before opening a paid server.

When the preparation checklist is complete, create a Cloudways account and select the appropriate plan based on application type, traffic, location, and growth requirements.

Conclusion: How Do You Complete a Cloudways Migration Safely?

A safe Cloudways migration is completed through verification rather than assumptions. The process must include preparation, transfer, testing, final synchronization, DNS cutover, SSL and email configuration, cache purging, monitoring, and a usable rollback path.

The Cloudways WordPress Migrator is appropriate for many standard WordPress and WooCommerce websites. Expert-managed migration is better for high-risk or unfamiliar projects, while manual migration provides the control required for custom applications.

Keep the old hosting active until the new environment consistently serves current data, critical transactions succeed, email is delivered, Google can crawl the site, and traffic no longer reaches the source. The safest migration is not the fastest transfer; it is the migration that protects users, revenue, data, and search visibility throughout the entire cutover.

→ Start Your Cloudways Migration

Frequently Asked Questions About Cloudways Migration

Cloudways migration FAQs clarify pricing, timing, email, DNS, SEO, and cancellation decisions that frequently remain unresolved after the initial transfer.

Is Cloudways website migration free?

Cloudways documents unlimited free self-service migrations through its WordPress Migrator. Its Help Center currently says expert WordPress and WooCommerce migrations are free, but its public landing page says the first expert migration is free, so verify the active entitlement in your account.

How long does Cloudways migration take?

Cloudways does not provide one duration for every project. Its public migration page says managed migrations are usually completed within one to two business days, but site size, access, complexity, database activity, and scheduling can change the timeline.

Does Cloudways migration include email accounts?

Cloudways website migration should not be assumed to include domain mailboxes. Transactional email and mailboxes use separate services, and existing MX, SPF, DKIM, and DMARC records must be preserved or recreated.

Can Cloudways migrate a WooCommerce website?

Cloudways supports WooCommerce through its WordPress Migrator and managed-migration workflow. An active store still requires a final synchronization or controlled freeze to protect orders and inventory created after the initial database copy.

Can WordPress Multisite be migrated to Cloudways?

WordPress Multisite can currently be migrated to Cloudways Flexible. Cloudways documentation says Multisite is not available on Cloudways Autonomous, and the destination must be configured correctly before the migration starts.

Will migrating to Cloudways affect SEO?

A hosting change without URL changes should not inherently cause a permanent ranking loss. SEO problems usually result from crawl blocks, downtime, missing content, changed URLs, slow responses, redirect errors, or tracking failures rather than the host change itself.

Why does the Cloudways Migrator fail or time out?

Common causes include incorrect SFTP credentials, blocked ports, IP restrictions, password protection, source-host limits, large file counts, insufficient disk space, and security plugins. Test the credentials independently and review both source and destination restrictions before retrying.

When is it safe to cancel the previous hosting account?

Cancel the previous host only after DNS has propagated, traffic to the old server has stopped, transactions and forms succeed, email is working, backups are active, and the new server has remained stable through the agreed observation period. Google recommends reviewing old-server logs and waiting until traffic reaches zero.

References

The following references support the external product, migration, DNS, email, SSL, plugin, and SEO claims cited in this article.

Cloudways. (2024, May 29). Test new Cloudways application via local hosts file changes. Cloudways Help Center.

Cloudways. (2024, August 21). How to fix mixed content issue for WordPress. Cloudways Help Center.

Cloudways. (2025, July 23). How to create an A record. Cloudways Help Center.

Cloudways. (2025, August 6). Which email add-on should I use? Cloudways Help Center.

Cloudways. (2026, March 27). How to request a managed application migration to Cloudways. Cloudways Help Center.

Cloudways. (2026, June 29). How to request and manage an end-to-end application migration on Cloudways. Cloudways Help Center.

Cloudways. (2026, June 29). How to use the Cloudways WordPress Migrator Plugin for single site and multisite migration. Cloudways Help Center.

Cloudways. (2026, July 7). How do I take my website live from Cloudways? Cloudways Help Center.

Cloudways. (2026). Expert website migration with zero downtime.

Google Search Central. (2026). Changing your web hosting and SEO. Google for Developers.

WordPress.org. (2026). Cloudways WordPress Migrator. WordPress Plugin Directory.