WordPress Migration Checklist: Files, Database, Email and DNS

To move WordPress to a new host, copy the site's files and database, test the destination, then switch the domain's DNS. Before you start, decide what happens to email and to new orders, forms, uploads, and comments during the move. Those are separate migration tasks; a homepage loading successfully doesn't prove they survived.

This checklist assumes you are keeping the same public domain and URLs. It is a planning and verification guide for an ordinary single-site installation. A busy store, multisite network, or custom application needs a migration plan that accounts for its own data and integrations.

1. Inventory what actually needs to move

Write down what the old hosting account runs before choosing a replacement. A WordPress installation may share its account with mailboxes, scheduled jobs, subdomains, redirects, and other applications.

Use this inventory to check plan limits as well: total storage, mailbox usage, database size, and any features your site requires. Compare the current Nest plans with the actual account, rather than assuming that every WordPress site fits the smallest plan.

2. Back up both files and the database

Keep a recoverable copy outside the old hosting account before changing anything. WordPress's backup documentation treats the database and site files as separate parts of a complete backup.

Check that the archive opens and the database export contains the expected tables. Record when both were taken. A file backup from Monday and a database from Thursday may not describe the same working site if plugins or uploads changed between them.

Include a secure copy of configuration and rewrite rules, plus the DNS inventory. Treat configuration and database exports as sensitive: they can contain credentials and customer information. Don't leave backup archives in a publicly served directory.

A useful rehearsal is to restore your copy into a restricted test environment and verify it. That gives you stronger evidence than a green backup notification. It doesn't replace the final copy taken at cutover.

3. Prepare the destination before moving traffic

Create the hosting account, check available space, and agree on the transfer method. On Nest, Krova provides a managed hosting panel for WordPress, MySQL, email, SSL, and backups, with migration from an existing cPanel host. Confirm the scope and method for your particular account before the move; don't assume every plugin, mailbox, or custom job transfers automatically.

Restore the files and database using the destination's supported workflow. If the database name, user, or password changes, update the connection configuration. The official WordPress migration handbook explains these dependencies and the extra work involved when URLs change.

Keep the test copy restricted. Disable outbound emails, scheduled jobs, payment calls, and webhooks there until you have deliberately configured how to test them. A clone should not send duplicate invoices or process the same background task as production.

Ask the destination provider how to preview the site under its intended hostname before changing public DNS. HTTPS, redirects, cookies, and plugins can behave differently on a temporary preview URL. If an accurate preview isn't available, include those checks in the controlled cutover window.

4. Keep URLs stable and test more than the homepage

For a host-only move, preserve the public scheme, domain, and paths where possible. Don't add an unnecessary domain change to the migration.

If URLs really must change, use a migration tool that understands WordPress data. A plain text replacement across an SQL dump can damage serialized values. The WP-CLI search-replace documentation describes serialized-data handling and a dry-run option; use it only where WP-CLI is supported, or ask for an equivalent supported migration workflow. Back up first and review the affected tables.

Run a short acceptance checklist against the destination:

• Open several existing posts, pages, media files, and a known permalink.
• Log in, save a test draft, and upload a harmless test image.
• Submit a form to a controlled recipient and confirm delivery.
• Check redirects, the preferred domain, and the HTTPS certificate.
• For a store, exercise cart and checkout in the payment provider's test mode, including the return and webhook flow. Confirm production credentials separately before reopening.
• Verify that only the intended environment runs scheduled tasks and external notifications.

Keep a record of the hostname tested, the result, and the remaining blockers. These checks are a proposed migration procedure, not a claim that Krova has tested your installation.

5. Plan email and DNS as their own workstream

Changing website hosting doesn't necessarily require moving your email provider or nameservers. If mail stays where it is, preserve the records it needs. If mail moves too, agree on mailbox transfer, credentials, client settings, and the final synchronization before changing routing.

When replacing a DNS zone, reconcile every required record: apex and www, subdomains, MX, SPF, DKIM, DMARC, and third-party verification entries. Confirm how DNSSEC is handled with the registrar and DNS provider if nameservers change. The goal is to move the site without accidentally disconnecting services that merely share the domain.

For records you control, lower the TTL sufficiently ahead of cutover to let the previous cached value expire. Cloudflare's TTL documentation explains how TTL affects caching and the limits for different record types. A shorter TTL can reduce cache duration; it doesn't make all visitors change destinations at the same instant.

6. Choose one place that accepts new writes

A migration can split activity between old and new databases if both remain writable. For a quiet brochure site, a short editorial freeze may be enough. A store or membership site also has orders, sign-ups, payment notifications, and jobs arriving without an editor pressing Save.

Choose a low-activity window and tell the people operating the site what will pause. Stop relevant writes and workers at the old environment, then take and restore the final database and changed files. Verify recent records and uploads at the destination before reopening activity there. Coordinate payment callbacks and retries with the payment integration rather than assuming a maintenance page pauses them.

Keep the old environment from accepting conflicting writes while cached DNS can still send visitors to it. Use the routing or maintenance arrangement agreed with your host. If the business cannot pause writes, arrange a supported synchronization or proxy cutover with someone responsible for the application's data. A simple export-and-import checklist cannot guarantee uninterrupted ordering.

7. Verify the switch and keep a deliberate rollback path

After changing the agreed DNS records, check the site from more than one network. Repeat the acceptance checks, confirm new records land at the destination, and watch application errors, email delivery, and integration callbacks.

Keep the old account and the pre-move backup until the agreed verification period ends. Choose that period using observed traffic, DNS behavior, and how often important jobs run, rather than a universal number of hours.

Before new writes resume, returning to the old environment is relatively straightforward if the agreed cutover plan supports it. After the new site has accepted orders or sign-ups, pointing DNS back can strand those records. Freeze writes, reconcile the new data, and choose the authoritative database before rolling back. Keep the migration owner involved in that decision.

Finally, verify backups at the new host and retire temporary copies, test credentials, and obsolete routing only after they are no longer needed.

When Nest is the right destination

Nest suits WordPress and everyday websites that fit its managed hosting plans and benefit from panel-based operation. Krova's Nest overview describes WordPress tooling, email, automatic SSL, scheduled backups, and cPanel migration. The existing Nest hosting guide covers the product; this checklist covers the transfer decisions around it.

If your site needs root access, custom daemons, or a runtime outside the managed hosting offering, evaluate a Cube instead and account for the server administration work. Choose the destination that fits the application, then make files, database, email, and DNS explicit parts of the move.