Blog/(updated Aug 1, 2026)

How to Migrate WordPress to Kinsta: A Safe Cutover Guide

A source-backed guide to Kinsta's managed WordPress migration, testing, DNS cutover, email checks, and rollback planning.

wordpresskinstamigrationtutorial
MethodDesk research
Checked
Sources4

Limits: This workflow was not executed on a live WordPress site or a paid Kinsta account. DNS interfaces, source-host access, plugins, stores, memberships, multisite networks, and custom stacks can require additional steps. No migration can be promised to have zero downtime or zero data loss without accounting for the site's write activity and DNS behavior.

Editorial verdict+++ Recommendedmedium confidence

For a standard WordPress site, Kinsta's included managed migration is the sensible default, provided the owner plans write control, testing, DNS, email, credential cleanup, and rollback rather than treating the transfer as automatic cutover.

Best for
  • Standard WordPress sites moving from another host
  • Site owners who want Kinsta's migration team to copy files and the database
  • Teams able to schedule testing and DNS changes on a weekday
Avoid if
  • You cannot pause or synchronize new orders, memberships, or content during cutover
  • You lack access to DNS and the current hosting account
  • The site uses a complex reverse proxy, custom stack, or unsupported migration arrangement without specialist review
On this page

Kinsta includes managed migrations for standard WordPress installations. For most buyers, that is a safer starting point than immediately installing a third-party migration plugin: Kinsta’s team copies the site, the existing site remains live during the copy, and the customer tests before changing DNS.

That does not make the move automatic or guarantee zero downtime. The customer still owns access, change control, testing, DNS, email, and the final cutover. Stores, membership sites, community sites, multisite networks, reverse proxies, and other custom configurations need extra planning.

This guide reflects Kinsta’s documentation as of August 1, 2026. It was not executed on a live site.

Choose the migration route

Kinsta documents four routes: its managed migration service, a manual migration, Duplicator, and Migrate Guru. Its migration overview says unlimited free managed migrations are available from all hosting providers for standard WordPress installations.

Use the managed route unless there is a concrete reason not to. It gives Kinsta responsibility for copying the files and database, but not for DNS, third-party services, or email setup. Kinsta performs migrations Monday through Friday. A $49 expedited option is documented for eligible requests, with an eight-hour target during specified weekday UTC hours and a refund of that fee if the target is missed. Complex or large sites can take longer.

Use a self-service route when you need direct control, cannot provide the required source access, or have a workflow already validated for that site. If you migrate yourself, Kinsta’s go-live guide says you may need to install the Kinsta MU plugin manually.

Before submitting the request

1. Confirm plan capacity

Kinsta creates a new site for the migration, so the account needs an unused WordPress install slot. Confirm that storage and the selected visit or server-bandwidth tier fit the site. The Kinsta pricing guide explains the current plan boundaries.

2. Inventory the full service

Record more than WordPress files and tables:

  • All production domains and subdomains
  • DNS provider and account access
  • Current DNS records and TTL values
  • Email provider and MX, SPF, DKIM, and DMARC records
  • Redirects, cron jobs, firewall rules, and IP allowlists
  • CDN, proxy, object storage, and external database dependencies
  • Ecommerce webhooks, payment callbacks, licenses, and API integrations
  • Bedrock or Trellis, multisite, reverse proxy, custom .htaccess or Nginx rules, and WP Engine LargeFS use

Kinsta asks customers to disclose special requirements in the migration request. Its managed service does not include pointing DNS, configuring third-party services, or setting up email.

3. Create an independent backup

Take a current backup of both site files and the database, and verify that it can be accessed. This is an operational precaution, not a substitute for Kinsta’s copy. Record the current host’s restore procedure as part of the rollback plan.

4. Decide how writes will be handled

Once Kinsta begins copying the site, later changes on the old host are not automatically present in the migrated copy. A static brochure site can use a short publishing freeze. A store, membership site, forum, or frequently edited publication needs a defined maintenance window, a second migration, or another synchronization method agreed with Kinsta.

Kinsta recommends maintenance mode for ecommerce, membership, and community sites to prevent lost orders, registrations, profile changes, or content. Do not promise a zero-downtime move when writes cannot be frozen or synchronized.

5. Prepare access safely

Gather the credentials requested for the source host, commonly hosting-panel, SFTP or SSH, and WordPress admin access. Follow Kinsta’s provider-specific source instructions. Some providers support adding the Kinsta migration team as a collaborator, which avoids sharing the owner’s login. Other arrangements may require a temporary account or changes to two-factor authentication.

Grant only the access required. After the migration, remove collaborators and temporary accounts, restore two-factor authentication, and rotate any credentials that were shared.

Request the managed migration

Only a Kinsta Company Owner or Company Administrator can submit the request.

  1. Sign in to MyKinsta.
  2. Open Sites, choose Add site, then select Request migration.
  3. Choose As soon as possible, a scheduled date, or an expedited migration if offered and needed.
  4. Choose migration from another host or from a backup.
  5. Enter the requested source access, WordPress, domain, HTTPS, and site details.
  6. Identify ecommerce, membership, community, multisite, Bedrock or Trellis, reverse proxy, LargeFS, and custom rule requirements.
  7. Select the Kinsta data center and add complete special instructions.
  8. Review the request for incorrect credentials, paths, domains, and timing before submitting.

Kinsta says as-soon-as-possible requests are usually completed within one business day. Treat that as the vendor’s target, not a guaranteed completion time. Watch the migration in Sites > Migrations and respond promptly if the team asks for more information.

When Kinsta confirms that copying has started, enforce the agreed publishing freeze or maintenance mode. Changes made after that point will not appear on the destination unless a second synchronization is performed.

Test before changing DNS

Kinsta will notify you when the copy is ready. Use its Site Preview tool so requests use the live domain against the Kinsta copy without moving public traffic. A temporary sitename.kinsta.cloud URL also exists, but testing through the intended hostname can expose domain-sensitive behavior more accurately.

Use a written acceptance checklist:

  • Compare representative pages, posts, menus, media, and downloads.
  • Log in and test each user role.
  • Submit forms and confirm delivery to the intended mailbox or CRM.
  • Check search, redirects, canonical URLs, robots directives, and the XML sitemap.
  • Test checkout, tax, shipping, coupons, payment callbacks, account pages, and transactional email on stores without creating untracked production orders.
  • Check membership login, gated content, subscriptions, and scheduled jobs.
  • Confirm plugin licenses, API credentials, webhooks, object storage, and third-party allowlists.
  • Inspect browser and application errors, mixed content, and failed network requests.
  • Verify mobile layouts and key supported browsers.
  • Compare recent users, orders, comments, and posts with the source database at the agreed freeze point.

Do not update DNS because the homepage loads. Get approval from the site owner and the person responsible for revenue or data workflows.

Prepare the DNS cutover

Kinsta recommends lowering DNS TTL to 300 seconds 12 to 24 hours before migration, then raising it to about 3600 seconds after launch. It says this TTL change is unnecessary when using Cloudflare. A low TTL can shorten resolver caching, but it cannot guarantee immediate propagation everywhere.

Before cutover:

  1. Add and verify the production domain in MyKinsta.
  2. Obtain the exact DNS records shown for that site in MyKinsta. Do not reuse an IP address from a generic tutorial.
  3. Preserve mail and domain-verification records unless an intentional provider change requires otherwise.
  4. Confirm how the apex and www hostnames should resolve.
  5. Arrange a final data sync or maintenance period for a write-heavy site.
  6. Record the old DNS values and define who can authorize rollback.

Go live

At the approved time:

  1. Enable maintenance mode or stop publishing if that is part of the plan.
  2. Complete the final data synchronization and validate its cutoff.
  3. Change only the required web DNS records to the values supplied by MyKinsta.
  4. Confirm the production domain serves the Kinsta environment.
  5. Verify HTTPS. Kinsta says a free Cloudflare SSL with wildcard support protects the domain after it is pointed correctly.
  6. Test critical pages, logins, forms, checkout, callbacks, and email again from outside authenticated administrator sessions.
  7. Confirm redirects in MyKinsta and enable the Kinsta CDN if it was disabled during testing. New sites have it enabled by default.
  8. Remove maintenance mode only after the application and data checks pass.

Expect some resolvers to use cached old DNS answers until their prior TTL expires. During that overlap, a write-heavy site can receive traffic at both environments. That is why maintenance mode or a synchronization plan matters more than a blanket “zero downtime” claim.

Monitor and retain rollback capacity

Monitor the site, business transactions, forms, email, application logs, and third-party callbacks through the cutover window. Compare fresh orders, users, and content against the expected sequence.

Keep the old hosting account intact until DNS has propagated and stakeholders have accepted the new site. If a severe issue requires rollback, restore the recorded DNS values and account for any writes received by either environment. DNS rollback alone does not merge divergent orders or user data.

After acceptance:

  • Restore normal TTL values.
  • Remove temporary source-host users and Kinsta collaborators no longer needed.
  • Re-enable two-factor authentication and rotate shared credentials.
  • Update IP allowlists and monitoring services.
  • Confirm backups and perform a documented restore review.
  • Cancel the old host only after the retention period in the migration plan.

Common failure points

Email stops working

Kinsta hosting does not replace the customer’s email provider during migration. Preserve the existing MX and authentication records, then test inbound, outbound, form, and transactional mail separately.

New orders or content are missing

The source site continued accepting writes after the copy began. Keep the old environment, stop further writes, and coordinate a second migration or controlled data reconciliation before reopening.

The site works on preview but not on the domain

Check the exact MyKinsta DNS values, proxy settings, domain verification, SSL state, and cached resolver answers. Do not repeatedly make unrelated DNS changes while propagation is still in progress.

Redirects or custom rules disappear

Rules implemented at the old host do not necessarily travel with WordPress. Recreate and test them in MyKinsta, especially canonical-host, HTTPS, path, and legacy URL redirects.

A self-migrated site does not use Kinsta caching correctly

Kinsta’s go-live checklist says self-migrated sites may need the Kinsta MU plugin installed manually. Confirm the plugin and CDN state before diagnosing performance.

Bottom line

Kinsta’s included managed migration is the recommended route for a standard WordPress site, but the service copies the site rather than owning the entire release. A safe move requires a write strategy, preview testing, exact DNS records, preserved email, monitored cutover, and a rollback plan.

If you are still deciding between hosts, compare Kinsta and WP Engine before starting the migration.

Sources

  1. MigrationsKinsta Docs, accessed Aug 1, 2026
  2. Kinsta MigrationKinsta Docs, accessed Aug 1, 2026
  3. Source Details by Hosting ProviderKinsta Docs, accessed Aug 1, 2026
  4. Go Live ChecklistKinsta Docs, accessed Aug 1, 2026