WP Engine to Kinsta Migration in 2026: The Honest Playbook (With Every Gotcha)

Why this guide exists

Kinsta already documents the migration wizard step by step. Their docs are good. What they don't tell you — because no host will candidly describe a competitor's quirks — is what specifically goes wrong when the source is WP Engine.

This guide is the WP Engine-specific layer on top of Kinsta's official process: the failure modes, the credential traps, the file-system gotcha that costs people their media library, and the exact sequence to cut over a WooCommerce store without losing orders.

I've confirmed every step inside MyKinsta with a live test account, cross-checked the failure modes with Kinsta's migrations engineering team (via Katalin Juhasz, Kinsta affiliate manager), and reviewed WP Engine's own LargeFS and SSL documentation for the source-side behavior.

Before you start: is moving actually the right call?

WP Engine is not a bad host. It's an expensive host with a few specific limitations that show up at specific traffic levels. Before you spend a weekend on this, run the cost picture honestly.

The migration usually makes sense if you're on WP Engine's Essential tier — Startup, Professional, Growth, or Scale — and you're hitting one of these: visit overages billed at $2 per 1,000, Smart Plugin Manager as a paid add-on, Global Edge Security as a paid add-on, no published uptime SLA, or no phone support below the ~$50/mo Professional plan. Kinsta's overage pricing is $0.50 per 1,000 visits or $0.50 per GB depending on which billing model you choose — about a quarter the cost. Redis is a $100/mo add-on at Kinsta but it's truly Redis, not a caching layer rebranded.

The migration is harder to justify if you're on WP Engine Core ($400/mo+), have Global Edge Security configured with custom rules, run phone support workflows, or have a heavy LargeFS dependency you'd need to replicate. Kinsta has no direct LargeFS equivalent — you'd be moving to a standard WordPress filesystem and either upgrading disk space ($20/mo per add-on) or offloading media to S3 yourself with a plugin like WP Offload Media.

If you're an agency with 10+ sites, the calculus shifts again. Anchor's well-known case study moved 500 sites and noted that bulk WP Engine migrations have specific rate-limit issues on the destination side that I cover later in this guide.

The four WP Engine-specific landmines

These four issues come up on most WP Engine migrations and none of them are obvious from the wizard. Handle each one before you submit a request — fixing them mid-migration adds days, not hours.

1. LargeFS files will be silently left behind

WP Engine's LargeFS feature offloads older media to an external Amazon S3 bucket that you own (typically files older than 10 days, or 60 days on legacy setups). The serving layer rewrites URLs so on the live site it looks seamless — images load, everything works.

Kinsta's migration team copies files from your WP Engine server. They cannot see or access files that LargeFS has moved to S3. Those files are not on the server anymore. When the migration completes, your new Kinsta site will have a media library where older images return 404 errors — and you may not notice until weeks later when someone visits an older post.

This is confirmed by Kinsta's migrations engineering team and matches WP Engine's own LargeFS documentation, which notes that "if you copy one environment to another images will be missing on the site you've copied to."

What to do: Before submitting, check the WP Engine User Portal for LargeFS status. If active, you have two clean options. Option A: Use AWS CLI to aws s3 sync the entire LargeFS bucket back to your local machine, then upload to Kinsta via SFTP after migration. Option B: Continue using S3 with a plugin like WP Offload Media on Kinsta — the bucket already exists. Note this in the "Special instructions" field on the wizard's Kinsta settings step so the migrations team flags any LargeFS-related anomalies during review.

2. WP Engine 2FA on the User Portal blocks credential-based access

Per Kinsta's migrations engineering team, this is the single most common cause of failed or delayed migrations across all hosts. WP Engine accounts with 2FA enabled on the User Portal will block Kinsta's team from logging in with username/password — they'll receive a 2FA challenge they can't answer.

Kinsta gives you two access methods in the wizard. The first — "Add Kinsta as user" — invites migrations@kinsta.com to your WP Engine account without billing access. It bypasses 2FA entirely, no password sharing, and the migrations team can start within hours. This is the recommended path and the one Kinsta explicitly flags as faster in the wizard.

The second tab — "WP Engine User Portal credentials" — asks for your username and password. Kinsta warns directly on that screen that this method requires additional security checks and takes considerably longer. There's also an optional checkbox to "proceed without full access" which lets the team attempt migration with limited access — useful as a fallback but not a primary plan.

What to do: Use the "Add Kinsta as user" method. Inside WP Engine's User Portal, go to your account → Users, add migrations@kinsta.com as a user with site access but no billing permissions. Confirm the invite was accepted before submitting the Kinsta migration request. This single change removes the most common failure mode.

3. You can't take your WP Engine SSL certificate with you

WP Engine doesn't grant access to the SSL certificates it manages on your behalf. Anchor's bulk migration write-up documented this clearly: when you cut over DNS to Kinsta, you need a new SSL certificate, and Kinsta will issue one via Let's Encrypt or Cloudflare automatically.

For a single site, this isn't an issue — Kinsta provisions a free Cloudflare-issued certificate on the new site, and the wizard offers two HTTPS options on the site details step: generate a new free certificate that auto-renews, or upload your own certificate by pasting .crt and .key file contents. The toggle below ("Force HTTPS") handles the redirect rule once DNS flips.

For agencies moving 20+ sites at once into the same data center, this becomes a problem. Let's Encrypt rate-limits new certificates at 10 per registered domain per hour and 10 failures per 3 hours per account. If you queue a batch of 20 sites overnight all pointing at the same data center, you'll wake up to half your sites without SSL.

What to do: Single site — no action needed, free Cloudflare cert is the default and works fine. Agency bulk move — cap at 10 sites per hour per data center, or split across multiple data centers (Kinsta has 27 locations available), or stagger DNS cutovers across days even if the migrations themselves complete in batches.

4. WooCommerce orders placed during the cutover window will be orphaned

This is the most painful failure mode and the one most likely to cost you actual money. Here's the sequence: Kinsta's team copies your WP Engine site to a temporary Kinsta URL. You test it. You sign off. You update DNS at your registrar. DNS propagates over the next 1–24 hours depending on TTL. During that window, some visitors hit the old WP Engine site, some hit the new Kinsta site. Orders placed on WP Engine after the migration started are not on Kinsta. When DNS finishes propagating and WP Engine traffic dries up, those orders are stranded on a host you're about to cancel.

Kinsta's wizard handles this with an opt-in maintenance mode checkbox that appears when you flip the ecommerce/community/membership toggle on the site details step. When enabled, the migrations team sets up maintenance mode on your WP Engine site so customers see a "we'll be back soon" notice instead of being able to check out. The key detail: Kinsta does not remove maintenance mode automatically after migration — it stays active on WP Engine until you manually cut DNS and the propagation completes. That's intentional. Without it, you have a window of order loss.

WooCommerce subscriptions get flagged separately. The renewal cron, payment gateway webhooks, and subscription state all need to be quiesced on one side and resumed on the other in a clean handoff. Note "WooCommerce subscriptions" in the special instructions field so the migrations team handles the cutover with awareness.

What to do: If you run WooCommerce, enable the ecommerce toggle on the site details step and check the maintenance mode option. Schedule the migration during your lowest-traffic window (typically 2–6am in your primary market's local time). Plan for a 3–7 hour total downtime window: 1–3 hours for migration, 1–3 hours for team review and testing sign-off, 1+ hour for DNS propagation. Don't cut DNS until you've tested checkout end-to-end on the temporary Kinsta URL.

The migration wizard, step by step (what actually matters)

Kinsta's wizard is a 6-step flow: Introduction → Set migration source → Source details → Site details → Kinsta settings → Review & submit. You access it from MyKinsta → Sites → Migrations tab → "Request new migration" button. I'll focus on the decisions that matter rather than re-documenting every click.

Step 1: Pick your timing — and don't pay $49 unless you actually need it

The Introduction step asks when to run the migration. Three options:

• As soon as possible — Free. Kinsta sends a heads-up before starting but doesn't wait for your approval. Requests are processed in the order received, so actual start time depends on queue depth.
• On a specific date — Free. The team verifies the timeframe is available and confirms back. Better for WooCommerce or coordinated cutovers where you need to control the window.
• Expedited 8-hour migration — $49 USD. Monday–Friday only, 9am–11pm UTC. Full refund if Kinsta misses the 8-hour deadline.

The $49 expedited option sounds tempting but it's narrowly useful. The window is UTC business hours only — useless if you're trying to migrate during off-peak in IST or PST. And the standard "specific date" option is free and lets you pick exactly when. The expedited option earns its fee in one scenario: you discovered today that your WP Engine renewal hits in 48 hours and you want to migrate before paying another month. Otherwise, free + scheduled is the right call.

Step 2: Confirm source — select "WP Engine"

Kinsta's wizard has a dropdown of supported source hosts. WP Engine is listed alongside A2 Hosting, Bluehost, Cloudways, DreamHost, Flywheel, GoDaddy, HostGator, Pagely, Pantheon, SiteGround, tsoHost, and WPX Hosting. Selecting WP Engine specifically tunes the next step — you get the WP Engine-specific access methods rather than generic SSH/SFTP fields.

Step 3: Source details — pick the access method

Two tabs: "Add Kinsta as user" (recommended) and "WP Engine User Portal credentials." I covered this in the landmines section — use the first one. The wizard literally tells you the second one is slower and triggers extra security checks.

If you must use the credentials path, the optional "proceed without full access" checkbox lets the team attempt migration even if some access points fail validation. It's a fallback for when you can't fully grant access (corporate accounts, MFA requirements, etc.) — not a recommended default.

Step 4: Site details — the WooCommerce, multisite, and Bedrock toggles matter most

This step is the densest. Fields:

• Domain name — the production domain. There's a wildcard subdomain option (*.domain.com) which is genuinely useful if you have many subdomains; it saves you from adding each one post-migration.
• WordPress username, password, admin URL — standard. Test these before submitting. Incorrect WordPress admin credentials are the second most common cause of migration delays per Kinsta's team.
• Bedrock/Trellis toggle — flip this if you're using Roots' Bedrock or Trellis stack. It reveals a root path field pre-filled as ~/public/current/web, which is the correct Trellis convention. WP Engine doesn't natively use Bedrock, so most readers will leave this off — but if your dev team set up a custom structure, this is where you flag it.
• Ecommerce/community/membership toggle — flip this for any WooCommerce, BuddyBoss, MemberPress, LearnDash, or similar site. It reveals the maintenance mode checkbox covered earlier.
• Multisite toggle — subdirectory or subdomain dropdown. WP Engine does support multisite on most plans, so this is a real choice. Pick the layout your existing multisite uses.
• HTTPS toggle — generate a new free Cloudflare certificate (auto-renews on Kinsta) or upload your own by pasting .crt and .key contents. New cert is the right default for nearly everyone.
• Force HTTPS toggle — handles the HTTP → HTTPS redirect rule. Leave on unless you have a specific reason.

Step 5: Kinsta settings — change the data center, always

This is the step where most migrations go wrong silently. Three fields matter:

• Site name — internal MyKinsta label only. Not public-facing, doesn't affect your domain or URL. Use something descriptive for your dashboard view; clients won't see it.
• Data center location — defaults to Chicago (US). This is the single biggest configuration trap in the wizard. If your audience is in India, the EU, Brazil, Singapore, or anywhere outside North America, leaving the default means your site gets hosted thousands of miles from your users. Kinsta has 27 data centers — Mumbai, Frankfurt, São Paulo, Tokyo, Singapore, London, Sydney, and 20 others. Pick the one closest to your traffic. This setting is changeable later but only by Kinsta support, not self-serve, so get it right now.
• Special instructions — free-text field. This is where you put: LargeFS status, any Nginx rules from WP Engine that need replication, plugin conflicts you know about, WooCommerce subscription requirements, custom redirect rules, and any reverse proxy setup needs.

Step 6: Review & submit

The review screen summarizes everything. Submit. Status drops into MyKinsta → Sites → Migrations tab with a "Waiting for migration" label and Type column showing "Regular" or "Expedited."

What happens after you submit

For "as soon as possible" requests, Kinsta sends an email when the migration starts, then keeps you updated on progress. All actual follow-up happens in MyKinsta, not email. Engineers may ask questions — about credentials, about a plugin conflict they hit, about a database table that's flagged. If you don't respond, the job stalls.

Kinsta's migrations team recommends checking MyKinsta at least twice per hour for the first two hours. After that, it's mostly the team doing the work.

Once migration completes, Kinsta emails you testing details — the temporary URL where your site lives on Kinsta before DNS cutover. Don't skip this step. Test:

• Front-end loads correctly on the temporary URL
• WordPress admin login works
• All key pages render (homepage, top 10 traffic pages, checkout if applicable)
• Forms submit correctly
• WooCommerce checkout end-to-end if applicable
• Older blog post images load (this is your LargeFS check — if any 404, you have a problem)
• Cron jobs are scheduled correctly (check via WP Crontrol plugin or wp cron event list via SSH)

Only after you sign off does Kinsta send DNS instructions. The cutover is your responsibility — Kinsta provides the records, you update them at your registrar.

The cutover playbook for WooCommerce stores

For non-ecommerce sites, the cutover is unremarkable — point DNS, wait, done. For WooCommerce or any site processing transactions, here's the sequence I recommend:

T-24 hours: Lower DNS TTL at your registrar to 300 seconds (5 minutes). This means when you flip DNS, propagation completes in minutes rather than hours. Most registrars let you do this without affecting anything else.

T-2 hours (off-peak): Confirm Kinsta maintenance mode is active on the WP Engine site. Visit the WP Engine site directly via its .wpengine.com URL or your live domain — you should see the maintenance notice.

T-0 (cutover): Update A records (and any CNAMEs) at your registrar to point to Kinsta. Because TTL is 5 minutes, propagation typically completes within 15 minutes.

T+30 minutes: Verify the new Kinsta site is serving traffic by checking from multiple geographic locations (use a free tool like dnschecker.org). Confirm SSL certificate is valid. Place a test WooCommerce order end-to-end.

T+2 hours: Once you're confident traffic is fully on Kinsta and DNS has propagated everywhere, restore TTL to a normal value (3600 or 86400) at the registrar.

T+24 hours: Keep WP Engine maintenance mode active for one more day as insurance. Check Kinsta analytics to confirm traffic is flowing as expected. Then cancel WP Engine.

The real cost picture after migration

The Kinsta plan you pick is rarely the whole bill. Here's what I see on real WP Engine refugee accounts:

A site migrating from WP Engine Professional ($50/mo annual, 3 sites, 75k visits) typically lands on Kinsta's WP 2 plan ($70/mo, 2 sites) or Single 65k ($50/mo, 65k visits). Base pricing is roughly comparable.

The cost differential shows up in add-ons. WP Engine bundles a lot at the Core tier ($400/mo+) — Global Edge Security, Smart Plugin Manager, EverCache. Kinsta unbundles. If you need equivalent functionality on Kinsta:

• Redis caching: $100/mo per site (this is real Redis, not a marketing rebrand)
• Premium Staging Environments: $20/mo (matches live site resources)
• Hourly backups: $20/mo
• Kinsta Automatic Updates with visual regression testing: $3/mo
• Additional disk space: $20/mo
• PHP performance pool increase: $10/mo per 512MB
• External backups to AWS or Google Cloud: $2/site/mo
• Reverse proxy: $50/mo (requires support team setup, not self-serve)

If you're a heavy WP Engine Core customer, do this math before you migrate. If you're a typical Professional or Growth customer, you'll likely end up adding Premium Staging ($20) and maybe Automatic Updates ($3) — and that's it. The total is still lower than WP Engine's equivalent tier.

What Kinsta gets right that WP Engine doesn't

Three things stood out in my first-hand testing that aren't obvious from marketing pages:

The MyKinsta dashboard is genuinely better. The sidebar includes Info, Domains, Backups, Tools, Redirects, Plugins and themes, Add-ons, IP deny, Analytics, Caching, APM, Database, User management, User activity, and Logs — all without leaving the dashboard or installing plugins. WP Engine's User Portal is functional but more fragmented. The Tools screen alone (PHP version switcher, search and replace, debug toggle, force HTTPS, password protection, early hints) replaces what most WP Engine users handle via plugins or support tickets.

Support actually answers technical questions. In testing, I connected to a human agent within 20 seconds and got an accurate, documentation-linked answer to a Redis configuration question in under three minutes. The agent proactively sent screenshots and doc URLs. WP Engine support is competent but routes more aggressively to documentation or to Account Manager handoffs.

The data center choice is yours, not theirs. 27 locations, picked at site creation, changeable later via support. For non-US audiences, this matters more than any caching layer.

What WP Engine still does better

I won't pretend Kinsta wins everything. Three things favor WP Engine:

LargeFS for media-heavy sites with unpredictable growth. If you have a site that generates 50GB of new media per month and you can't predict growth, LargeFS with S3 backing is genuinely useful. Kinsta's equivalent (manual S3 offload via plugin) requires more setup and more attention.

Phone support starts lower. Phone support is available from WP Engine's Professional plan (~$50/mo annual). Kinsta is chat and ticket only — no phone support at any tier. For some teams, phone is non-negotiable.

Smart Plugin Manager on Core+ tiers. WP Engine's Smart Plugin Manager on Core ($400/mo+) does visual regression testing with automatic plugin updates. Kinsta has a similar feature called Kinsta Automatic Updates at $3/mo per site — functionally equivalent and cheaper, but only available as an add-on.

The honest bottom line

The migration itself is the easy part. Kinsta's team genuinely does this for free and they're genuinely good at it. The wizard is well-designed. The post-migration testing process is conservative in the right way — you sign off before DNS flips.

The hard parts are the four landmines: LargeFS files left behind, 2FA blocking access, SSL rate limits at scale, and WooCommerce orders lost in the cutover window. Handle all four upfront and the migration is genuinely a 3–7 hour window of low-effort waiting rather than a weekend of firefighting.

If you're sitting on a WP Engine renewal notice and the price hurts, the math usually favors moving. If you're on Core with everything dialed in and a team trained on the WP Engine workflow, the migration is real work and the savings need to justify it.

Start a free Kinsta migration →

Frequently Asked Questions

How long does a WP Engine to Kinsta migration take?

Plan for a 3 to 7 hour total window: 1 to 3 hours for the migration itself, 1 to 3 hours for Kinsta's team review and your testing sign-off, and at least 1 hour for DNS propagation. For most standard WordPress sites under 2GB, the actual hands-on time is under 30 minutes — the rest is monitoring and verification.

Is the WP Engine to Kinsta migration free?

Yes. Kinsta offers unlimited free migrations from WP Engine on every plan, handled by their engineering team. A $49 expedited 8-hour migration option is available for Monday through Friday 9am to 11pm UTC, with a full refund if Kinsta misses the deadline — but the standard "specific date" option is free and lets you pick exact timing.

What happens to my WP Engine LargeFS files during migration?

LargeFS files live in your Amazon S3 bucket, not on WP Engine's server. Kinsta's migrations team cannot see or access them and they will be silently left behind during migration. After cutover, older media will return 404 errors. Before submitting the migration request, either sync the LargeFS bucket back to local storage via AWS CLI and re-upload to Kinsta via SFTP, or continue using S3 on Kinsta with a plugin like WP Offload Media.

Will my WordPress site go offline during the migration?

No. Your WP Engine site continues serving traffic normally throughout the migration. Kinsta copies the site to a temporary URL where you test it, then you cut DNS over at your registrar when ready. With DNS TTL lowered to 300 seconds before migration, the cutover propagation completes in under 5 minutes. For WooCommerce stores, optional maintenance mode prevents orders being placed on the old host during the DNS propagation window.

How do I avoid losing WooCommerce orders during the cutover?

Enable the ecommerce toggle on the wizard's site details step and check the maintenance mode option. Kinsta's team activates maintenance mode on your WP Engine site so customers cannot check out during the migration window. Schedule the cutover for off-peak hours, lower DNS TTL to 300 seconds 24 hours beforehand, and only update DNS after you have personally tested checkout end-to-end on the temporary Kinsta URL.

Does Kinsta have an equivalent to WP Engine's Smart Plugin Manager?

Yes — Kinsta Automatic Updates at $3 per month per site. It runs plugin and theme updates with visual regression testing and automatic rollback if a visual change is detected. Functionally equivalent to WP Engine's Smart Plugin Manager (which is a paid add-on on Essential plans, included on Core at $400 per month and above) and significantly cheaper.

Can I keep my WP Engine SSL certificate after migrating to Kinsta?

No. WP Engine does not grant access to the SSL certificate files it manages on your behalf. Kinsta provisions a new free Cloudflare-issued certificate automatically when DNS cuts over, and the wizard offers an option to generate it during setup. You can also upload your own certificate by pasting .crt and .key file contents if you have a third-party cert.

Related reading: Leaving WP Engine — destination guide (Kinsta vs Rocket.net vs Cloudways) · Kinsta vs WP Engine — full comparison · Kinsta review 2026