Checklist: move a WordPress site to modern hosting

Who this is for

Founders, operations leads, and IT staff who own a WordPress site and need to move it from a shared plan, an old VPS, or a retiring host to a managed WordPress platform or a cloud server. The site may run WooCommerce, membership plugins, forms, or a blog with years of media. You do not need to be a developer, but someone on the project must have WordPress admin access and DNS access.

Checklist: move a WordPress site to modern hosting is written for the person who has to plan the cutover, not only the person who clicks the buttons. That person should know which plugins are active, who owns the mail records, and which pages bring in revenue. If no one owns those details, stop and assign them before you schedule a window.

A small blog can move in an afternoon with help from the new host. A store with live orders, custom plugins, or tight email dependencies needs a written plan. Treat the move as a small project with a rollback point, a test pass, and a named person who can approve the DNS change.

Before you begin

Collect access before you touch anything: registrar login, DNS zone, current hosting panel, SFTP or SSH, WordPress admin, database tools, and plugin license accounts. Record the current WordPress version, PHP version, database type and version, web server, disk usage, and the full plugin list. Check each plugin against the target host's PHP version and caching rules.

Build a staging copy on the new host with a temporary hostname. Do not point the live domain at an untested site. Lower the DNS TTL for the site record to 300 seconds at least a day before cutover, and set a content freeze for the cutover window. Tell the people who publish pages and process orders.

Choose a migration method and write it down. A migration plugin can work for a simple site, but it can time out on large uploads or leave out mail settings. A manual move with rsync, wp db export, and a serialized data aware search and replace gives you more control. Whichever method you use, keep the old host running and keep a backup you have restored once.

The checklist

Work in order. The early steps protect the site, and the late steps protect your users. Do not skip the backup test or the rollback plan because the new host looks fast in a browser.

At cutover, change one layer at a time. Copy files, import the database, fix the site address, then test. Change DNS last. Keep the old site reachable by IP or a hosts file entry until the new one passes.

After cutover, watch the things that break quietly: cron, email, forms, logged in sessions, and scheduled posts. A page can look fine while checkout or password reset fails.

• Record the current WordPress, PHP, database, and web server versions and list every plugin with its version and license status.
• Take a full backup of files and database, download it off the server, and restore it once to prove the backup works.
• Lower the DNS TTL for the site record to 300 seconds at least a day before the planned cutover.
• Build the new environment with a temporary hostname, match the current PHP version first, and test plugin updates there.
• Export the database with wp db export or mysqldump, and import it into a new database with utf8mb4 collation.
• Copy wp-content, wp-config.php, .htaccess, and any custom files with rsync or SFTP, excluding cache and backup folders.
• Run a serialized data aware search and replace to swap the old domain for the new one, then check widgets, menus, and settings.
• Set new WordPress salts, update database credentials, and turn off debug display before the site is public.
• Test forms, checkout, login, password reset, cron, email delivery, and third party API connections on the new host.
• Configure TLS, redirect HTTP to HTTPS, and confirm the canonical domain and permalinks match the old site.
• Purge caches at the host, CDN, and WordPress plugin layers, then load key pages in a private window.
• Change DNS only after sign off, watch error logs and uptime for 24 hours, and keep the old host available for rollback.

What good looks like

The finished move has no missing media, no mixed content warnings, and no redirect loops. The WordPress address and site address match the canonical domain. Permalinks work without a plugin reset. Logged in users can stay logged in, and password reset mail arrives.

The new host shows a clean PHP error log and a working object cache if you use one. Scheduled tasks run, forms send, and checkout completes in a test order. Your CDN and host cache purge when you publish. Backups run on a schedule you have checked, and a restore has been tested.

You also have a short handover note: who can change DNS, where backups live, which plugins are licensed, and how to roll back. That note matters more than the host's control panel.

What to do next

If the site is small and the new host offers a managed migration, use it and keep the checklist as your acceptance test. If the site has custom code, a store, or complex DNS, schedule a pilot on a staging domain and a separate cutover window. Do not combine a hosting move with a major WordPress or plugin upgrade unless you have no other choice.

For teams that need architecture and a phased plan before the move, the Discovery and roadmap sprint from Cloudverg is a fixed price engagement at $9,500 that runs two weeks and ends with a target design, a roadmap, and a quote for phase one. It is one option among managed hosting migrations, a freelancer, or an in house move.

Close the project by raising DNS TTL back to its normal value, keeping the old host for a short rollback window, and removing stale DNS records. Update the asset list, plugin licenses, and backup schedule. Then run the checklist again in a month as a health check.

Frequently asked questions