Migrating from WP Engine to Kinsta: Step-by-Step Checklist

Disclosure: See our affiliate disclosure for details. The Kinsta product link here is currently a plain, non-tracking link.

Moving a single WordPress site off WP Engine is annoying. Moving a client’s production site off WP Engine while that client is actively selling through it is a different problem entirely — one migration mistake and you’re fielding a support call instead of an invoice. This checklist covers moving from WP Engine to Kinsta, including preparation, testing, and the decision to change DNS.

Before you touch anything: audit what WP Engine is quietly handling for you

Make an inventory of plugins, caching configuration, redirects, scheduled tasks, email, and third-party services before the move. Treat this as a handoff checklist: record who will verify each item at the destination. Kinsta asks you to disclose special requirements such as custom server rules, WP Engine LargeFS, and multisite networks in the migration request. Its migration service does not include pointing your domain, configuring third-party services, or setting up email; assign those tasks explicitly. See Kinsta’s migration process (accessed September 6, 2026).

Step 1: Choose the migration route and reserve capacity

Kinsta offers unlimited free migrations for standard WordPress installations from other hosts. Customers can request a migration through MyKinsta using source-host information or a backup containing both files and the database. For a team-handled migration, check that the plan has an available site slot: Kinsta creates the new site for the migration. The requester must be a Company Owner or Company Administrator. Team migrations take place Monday through Friday, so agree on a weekday when your reviewer is available. Sources: Kinsta migration options and request preparation (both accessed September 6, 2026).

A manual migration can be sufficient when your agency can handle the transfer, test the result, and manage cutover itself; Kinsta also documents manual and plugin-based routes. Paid hosting is a fit only if the destination meets the site’s ongoing operational needs. Do not choose a higher hosting tier merely because you assume team migration requires it: the supplied migration documentation describes free team migrations, with expedited migration as a separate paid option.

Step 2: Test the migrated copy before changing DNS

When Kinsta’s team finishes the migration, it sends testing instructions. Follow those instructions and confirm the copied site works before pointing the public domain to Kinsta. Do not assume that previewing a migrated copy means you have created a separate staging environment. As an editorial acceptance checklist, test the contact form, checkout where relevant, scheduled tasks, important redirects, and access for the people who maintain the site. Record any failures and resolve them before cutover.

Step 3: DNS — plan the change before migration day

Record the current DNS settings, identify who can change them, and review the TTL with the DNS administrator before scheduling the move. Kinsta notes that propagation time varies with TTL settings. Avoid promising a fixed cutover duration to the client. Keep the old settings available as part of your contingency notes and coordinate DNS work with the migration reviewer.

Step 4: Agree on maintenance mode before copying transactional data

A 30–60 minute content freeze around DNS cutover is not a reliable migration plan for a store or membership site. Kinsta says changes made after migration starts will not carry over to the copied site. For frequently updated sites, its documented approach is maintenance mode during migration, testing, and DNS propagation. If taking the site offline is not possible, discuss alternatives with support before starting. If updates occur or go-live is delayed, a second migration may be needed. Source: Kinsta’s special-case migration guidance (accessed September 6, 2026).

For example, agree who will disable ordering, who will test the migrated checkout, and who will change DNS. Keep a written acceptance record before reopening normal activity. This is a proposed agency workflow, not a claim of a completed migration or a guarantee that no data can be lost.

Step 5: Confirm SSL, redirects, and the sitemap before declaring victory

Choose the SSL route during preparation: Kinsta documents generating a certificate through its Cloudflare integration or uploading an existing certificate. Do not assume SSL will become correct automatically at cutover. As final acceptance checks, verify HTTPS on the public domain, important redirect destinations, and sitemap accessibility. Confirm the separately assigned DNS, email, and third-party service tasks are complete before closing the migration.

Failure checks to include in the handoff

1. Check plugin and theme compatibility with the destination PHP configuration.
2. Compare important marketing URLs against the redirect inventory.
3. Look for hardcoded source-host URLs in theme files and generated assets.
4. Verify DNS settings and the agreed plan for changes made after the initial copy.

Use this list as an acceptance checklist, not a ranking of measured failure rates. Before buying hosting, send Kinsta your site’s traffic, storage, and special requirements to check destination fit. If you are already a customer, prepare the available site slot, source access or complete backup, maintenance plan, and reviewer before submitting the migration request in MyKinsta.

Related reading: Kinsta vs Cloudways for Agencies: Which Wins on Client-Site Management? and How to Migrate 20+ WordPress Sites to Kinsta Without Downtime. For contingency planning, see the migration rollback checklist.