Disclosure: This post contains affiliate links; we may earn a commission at no extra cost to you.
Migrating to managed WordPress hosting is not simply copying files and changing DNS. A safe move preserves the database, uploads, redirects, email, certificates, scheduled jobs, analytics, and new customer activity while providing a tested rollback path.
This guide uses Cloudways as the recommended destination because it provides free migration assistance, staging, backups, flexible resources, and a temporary application URL. The same sequence works with Kinsta, WP Engine, Pressable, Flywheel, and similar managed platforms.
Before you begin
Collect access to the existing WordPress administrator, SFTP or hosting panel, database, DNS provider, domain registrar, CDN, analytics, transactional email, and new hosting account. Do not begin a cutover if the only person with DNS access is unavailable.
Record the current PHP version, WordPress version, database size, file size, traffic, cron jobs, redirects, DNS records, and required plugins. Identify stores, forms, memberships, forums, and learning systems that receive live data.
Choose a quiet migration window and notify stakeholders. A brochure site may need no maintenance mode; a busy store needs a short, controlled write freeze during final synchronization.
Step 1: reduce DNS time-to-live
One or two days before cutover, lower the TTL for the website’s A, AAAA, or CNAME record to roughly 300 seconds if the DNS provider permits it. This encourages resolvers to refresh quickly after the change.
Do not modify MX, SPF, DKIM, or DMARC records unless email is also being migrated. Web-host changes frequently break email because someone replaces the entire DNS zone instead of changing only the website records.
Capture the original record values and take screenshots or export the zone. You will need them for rollback.
Step 2: clean and update cautiously
Remove abandoned backup archives, cache files, and known malware before copying. Do not perform a sweeping plugin or PHP upgrade immediately before migration. Too many simultaneous changes make failures difficult to diagnose.
Create a full independent backup of files and database. Store it away from both the old and new hosts. Verify the archive opens and the database export is not empty.
If the source site is already unstable, document existing errors so they are not incorrectly attributed to the new host.
Step 3: create the destination
Launch the new WordPress application in the closest appropriate region. On Cloudways, choose a provider and server size with headroom beyond current peak use; the cheapest entry-level server tier is not automatically suitable for every production site.
Match a supported PHP version and configure the temporary domain. Enable the destination’s backup system before importing. Record SFTP, SSH, and database credentials securely.
Do not point public DNS yet. The existing site should continue serving visitors while the copy is built and tested.
Step 4: copy the site
Use the destination host’s managed migration service or supported migration plugin when the site is conventional. Cloudways provides a WordPress Migrator workflow and offers managed migration assistance. Provide source credentials only through approved secure channels.
Large sites, multisite networks, unusual filesystem layouts, or restricted source hosts may require SFTP and database migration by support or a developer. Preserve file permissions and serialized WordPress data; a plain text replacement in the database can corrupt serialized values.
Keep the source unchanged after the initial copy except for normal live activity.
Step 5: test through a temporary URL or hosts file
A temporary domain is convenient but can affect redirects, cookies, licenses, and integrations. The most accurate test maps the real domain to the new server on your own computer using the hosts file. Only that computer sees the destination while public visitors remain on the source.
Check:
- home page, key landing pages, posts, search, and 404 behavior;
- mobile navigation, images, fonts, and downloads;
- administrator login, editor, and media uploads;
- contact forms and spam protection;
- account, cart, checkout, coupons, and payment sandbox flows;
- memberships, course progress, and protected pages;
- redirects, canonical tags, robots directives, and sitemap;
- analytics, consent tools, pixels, and external APIs;
- cron jobs, queues, webhooks, and transactional email.
Inspect browser console errors and PHP logs. Compare representative pages with the source, not an unrelated speed score.
Step 6: configure caching, CDN, and security
Enable the host’s recommended cache and avoid running overlapping full-page cache plugins. Exclude carts, checkout, accounts, previews, and personalized pages. Purge the cache and verify logged-in content never leaks to another user.
Configure CDN and firewall services after origin behavior is correct. Import required redirects carefully. Allow legitimate payment, monitoring, search, and webhook traffic through security rules.
Install SSL for the final domain and confirm the destination is ready to issue or attach the certificate at cutover. Avoid forcing redirects that trap the temporary test domain in a loop.
Step 7: plan the final database sync
For a static brochure site, the initial copy may remain current. For a store, membership, forum, or active publisher, it becomes stale as soon as someone creates data on the source.
Schedule a maintenance window. Pause new writes, take a final source database export, import it at the destination, run safe URL replacement if needed, and verify counts for orders, users, posts, and form entries. Copy new uploads created since the initial migration.
Do not perform another visual redesign during this window. The objective is data consistency.
Step 8: change DNS
Update only the records that direct web traffic. Confirm IPv4 and IPv6 behavior; an old AAAA record can send some visitors to the former server even after the A record changes.
Keep the old host active. DNS propagation is gradual, despite a low TTL. Monitor traffic and logs on both systems to see when requests shift.
If a proxy such as Cloudflare controls DNS, review proxy status, SSL mode, cache, and firewall rules. An incorrect edge setting can make a healthy origin appear broken.
Step 9: validate production
Repeat the functional checklist on the public domain from several networks and devices. Submit a real low-value transaction if appropriate, confirm the payment webhook, and check transactional email. Verify SSL, redirects, sitemap, analytics, and search-console ownership.
Monitor PHP errors, 404s, server resources, cache behavior, forms, orders, and uptime for at least 48 hours. Compare order and lead counts with normal expectations.
Do not cancel the old host when the home page loads once.
Step 10: finalize and document
After a stable observation period, raise DNS TTL to the normal value. Create a fresh destination backup, remove migration accounts, rotate temporary credentials, and delete unneeded archives containing customer data.
Document the host, region, plan, DNS provider, backup schedule, support contacts, renewal date, email provider, and rollback history. Cancel the old service only after confirming backups and any refund implications.
Rollback plan
Define rollback triggers before cutover: failed checkouts, unacceptable errors, missing data, or an unresolved integration. To roll back, restore the original DNS values, remove maintenance mode at the source, and reconcile any transactions created on the destination.
Rollback is harder when both copies accept writes. Keep the decision window short and assign one person authority to act.
Editor’s pick: Cloudways
Related reading: Cloudways Review 2026: Managed Cloud Hosting Tested
Final checklist
A successful migration preserves functionality and data, not merely page appearance. Keep the source online, test through the real domain locally, protect live writes, change only relevant DNS records, and monitor both sides after launch.
Managed migration assistance reduces labor, but the site owner remains responsible for business verification. No hosting technician knows every form, subscription rule, or external integration as well as the team operating the site.
Frequently asked questions
Will a WordPress migration cause downtime?
It can be nearly seamless when the destination is tested first and final data synchronization and DNS are planned carefully.
How long should the old host remain active?
Keep it available through DNS propagation and a stable monitoring period, commonly several days for an important site.
Does changing web hosting move email?
No. Preserve MX and mail-authentication records unless a separate email migration is planned.
Should plugins be updated during migration?
Avoid unrelated updates during cutover. Establish a stable baseline, migrate, and schedule changes afterward.