Keep the old host until the destination works with the latest data, correct domain, and essential customer actions. A migration service can copy the site, but you still need to coordinate DNS, email, changing transactions, and acceptance checks. Agree those responsibilities before starting.

Prepare before copying anything

Inventory the domain registrar, DNS provider, hosting account, email service, plugins, external integrations, scheduled jobs, redirects, and certificates. Confirm who has access to each. A WordPress administrator login alone does not give you control of the whole move.

Take a restorable files-and-database backup and keep a copy outside the source hosting account. Record the current configuration so another person can help if the usual maintainer is unavailable.

Check essential plugins at the destination. Both Kinsta and WP Engine maintain restrictions; a change in hosting may require removing redundant caching or replacing an incompatible tool. Resolve that before the public cutover.

What each provider offers

Destination Starting route What to agree before the move
Kinsta Request a migration through its documented service Scope, timing, access, testing, and final synchronization
WP Engine Follow its migration process and supported tooling Automation suitability and any assistance needed for a complex site
Cloudways Follow its WordPress migration/onboarding process Destination configuration, required access, and assisted-migration terms

Use the provider's current instructions for credentials and tooling. We do not promise a fixed turnaround or describe every complex migration as included. A standard copy and a live store cutover are different jobs.

If you are still choosing a destination, read the provider comparison. If one is selected, ask that provider to confirm the migration arrangement before signup or cancellation elsewhere.

Protect email and DNS

Website hosting, DNS, and mailboxes can be supplied by different companies. Moving WordPress does not inherently move email. If the old hosting package also supplies mailboxes or DNS, determine what cancellation would remove.

Keep a record of MX records and email-related TXT records. Change only the records required for the website move, following the destination's instructions. Do not replace an entire DNS zone with a minimal web-hosting setup and accidentally discard mail or verification records.

Arrange the destination certificate and validation procedure before switching public traffic. Do not plan around a period of broken HTTPS as an unavoidable migration step. Check both the preferred hostname and any hostname that redirects to it.

Test the destination on a safe copy

Area Acceptance check
Pages Key URLs, images, styles, navigation, and mobile layout work
Forms A submission reaches the intended recipient or system
Accounts Login, password reset, registration, and permissions work
Commerce Test checkout, callbacks, stock, and notifications agree
Operations Scheduled work, feeds, search, and integrations behave correctly
Discovery Important redirects and canonical URLs are preserved

Temporary URLs can behave differently from the production domain. Repeat domain-dependent checks after cutover. Protect the test site from public access and disable real payments, customer emails, and other external side effects where appropriate.

Handle data created after the first copy

For a static brochure site, a short publishing pause may be enough. For stores, memberships, or active editorial teams, identify what can change: orders, registrations, comments, content, inventory, and queued jobs.

Agree either a final synchronization process or a controlled pause in writes with the responsible developer and host. DNS changes are not instantaneous for every visitor, so avoid accepting conflicting writes independently at both hosts. Do not improvise table copying without understanding the application and extension data.

The rollback plan must include transactions created on the new host. Sending traffic back to an old database can lose those transactions. See the backup guide for recovery planning and WooCommerce hosting for store-specific checks.

Cut over, observe, then cancel

Record the cutover time and the final data state. Apply the agreed DNS changes. Confirm which destination serves the live domain, then repeat HTTPS, forms, authentication, and transaction checks. Remove temporary indexing restrictions from production while keeping staging protected.

Monitor errors and important actions during the agreed overlap. Cancel the old service only after acceptance, any required retention, and its cancellation terms have been addressed. Keep the final backup and migration record. The move is complete when the website works as a business system, not merely when its homepage appears.