Skip to content

A safe WordPress migration is not finished when the files arrive. It is finished when the destination works, the critical user journeys pass, DNS points to the right server and you still have a rollback path.

Before the migration window

  1. Inventory the site. Record WordPress and PHP versions, active plugins, the active theme, database size, uploads size and any server-level jobs.
  2. Prepare the destination. Confirm PHP extensions, database access, free disk space, HTTPS and filesystem permissions.
  3. Reduce DNS TTL. If the IP address will change, lower the relevant record TTL ahead of the cutover.
  4. Choose a quiet period. Stores and membership sites need a plan for orders, registrations and form submissions created during the move.
  5. Create an independent backup. Keep a recovery copy somewhere other than the source server.

Package the source site

Open MigrateNest → Migrate out. Review the preflight result, choose the database and file scope, and create the archive. Packaging is performed in resumable, time-budgeted work rather than assuming one request can run indefinitely.

Download the completed archive or transfer it through infrastructure you control. Do not include WordPress core, wp-config.php, server configuration files or previous backup archives.

Restore on the destination

  1. Install WordPress and MigrateNest on the destination.
  2. Open MigrateNest → Migrate in.
  3. Select the archive and confirm the destination will be replaced.
  4. Allow chunked upload and restore stages to complete. If an interruption occurs, resume instead of uploading from the beginning.
  5. Sign in with the credentials from the restored source site if authentication changes.

Verify before changing DNS

Use a temporary hostname or local hosts-file preview when your hosting provider supports it. Check more than the homepage:

  • WordPress admin login and user roles;
  • important pages, posts, media and downloads;
  • menus, search, forms and email delivery;
  • WooCommerce cart, checkout, payment sandbox and webhooks;
  • scheduled tasks, caching and security plugins;
  • canonical URLs, robots directives, sitemap and analytics;
  • SSL, HTTP-to-HTTPS redirects and mixed content.

Cut over and monitor

Point DNS only after the destination passes verification. Keep the old host intact while caches expire and real traffic reaches the new server. Watch error logs, form delivery, checkout, scheduled tasks and Search Console for failures that do not appear on the homepage.

Keep a rollback path

Do not delete the source immediately. If a critical issue appears, restore the last known-good state or point traffic back while you investigate. Document the final DNS values and take a fresh backup after the destination is stable.

See the complete new-host workflow and use the restore safety checklist before writing to a destination.