Kinsta Setup and Migration Guide

Moving a WordPress site to Kinsta is one of two operations. If the site is fresh, you spin up a new install inside MyKinsta and point a domain at it. If the site is already live somewhere else, you migrate it, either by handing Kinsta the keys (the white-glove migration is free and included on every plan) or by running the move yourself with Migrate Guru or a manual file-and-database transfer. Both paths converge on the same DNS cutover and the same post-launch checks, and both share a handful of gotchas that catch most teams the first time. This guide is the operating manual for that work.

Setting Up a New Kinsta Site

New sites are created from MyKinsta, the dashboard that replaces cPanel on Kinsta. After your account is provisioned, go to Sites, click Add site, then Create new site. You will pick a site name (it forms the temporary domain at sitename.kinsta.cloud), choose Install WordPress for a turnkey install or Empty environment if you plan to push code in with WP-CLI or Git, and select a data center. Kinsta serves from 37 Google Cloud regions on the premium tier network, and the only rule that matters is "closest to your audience". A site for a UK e-commerce shop served from us-east1 will give up 80 to 120 ms of round-trip latency for no reason.

The first install will provision in a few minutes. While you wait, decide whether you want the included Cloudflare integration on by default (it is) and whether you want WordPress search-engine visibility off until launch. After provisioning, your site is live on the temporary kinsta.cloud subdomain with a free SSL certificate, ready to be built out or used as a staging target for a migration.

Migrating to Kinsta: Two Paths

Kinsta runs unlimited free migrations on every plan, including the $35 Starter. There is no per-site cap; if you have ten sites to move, all ten qualify. The catch is that the migration request goes into a queue, and the engineering review adds a few hours after Kinsta's team finishes the copy. For most sites, the full handover is 1 to 3 hours of active work plus 1 to 3 hours of testing.

The free migration is the right default for almost everyone. Hand Kinsta either your existing host's login credentials or a full-site backup file, and an engineer copies the files, database, and configuration to a fresh kinsta.cloud staging URL. You test, sign off, then cut DNS. The advantage is that Kinsta's team has run thousands of these moves and knows the source-host quirks for every major provider on the list, including the ones that break naive plugin migrations.

The DIY path is right in three situations: the site is small and you would rather not wait in the queue, the source host blocks SFTP or backup-export in a way the white-glove team cannot work around, or you need to coordinate the cutover with a specific maintenance window. The two DIY routes are Migrate Guru (a free plugin written by BlogVault that handles the file-and-database copy in one click) and a manual SFTP plus MySQL transfer. Migrate Guru works for most standard installs; manual is the fallback when the site is large, encrypted, or running multisite. Picking among them is mostly about how much control you want over the timing.

The DNS Cutover Playbook

Whether the move is white-glove or DIY, the cutover follows the same five-step pattern, and skipping any of the steps is how teams end up with a half-broken site for hours.

1. 12 to 24 hours before cutover, drop your DNS TTL to 300 seconds at your registrar. This is the single most impactful pre-launch step. If your A record TTL is the default 3600 or 14400 seconds, the cutover propagation will stretch across hours instead of minutes, and rollback during that window will be just as slow.
2. Test the kinsta.cloud staging URL end-to-end. Hit the homepage, log in to wp-admin, check checkout flows if it is an e-commerce site, and verify that media files load. Anything broken on the staging URL will still be broken on the real domain.
3. Add the production domain in MyKinsta before changing DNS. Sites, then your site, then Domains, then Add domain. This warms Kinsta's edge so the SSL certificate provisions during the propagation window, not after it.
4. Update the A record (or CNAME) at your registrar to Kinsta's target. With TTL at 300 the swap is visible to most resolvers in 5 to 15 minutes.
5. Force-renew SSL inside MyKinsta after propagation completes. Kinsta's Let's Encrypt issuance needs the domain to actually point at Kinsta first; if you skip this, you get an SSL warning for the first few minutes.

Rollback in the same window is simple: change the A record back to the old host. With TTL at 300, the swap takes minutes. Reset TTL to your normal value 24 to 48 hours after the launch settles.

Migration Gotchas We've Seen

The free migration team handles most of these for you, but they show up constantly in DIY moves and are worth knowing either way.

• File ownership and permissions: Kinsta uses specific user and group ownership on /public. A raw SFTP push of files copied from a cPanel host will land with the wrong owner; the symptom is plugins that cannot write to wp-content/uploads or autoupdates that silently fail. The fix is a one-shot Reset File Permissions from MyKinsta (Sites, Tools, Reset File Permissions) after upload.
• The mu-plugins drop-in: Kinsta ships a kinsta-mu-plugins folder containing the Cloudflare integration, the cache purge logic, and the staging-banner. If you drag-copy wp-content from the old host, you will overwrite it. Always copy wp-content/plugins, wp-content/themes, and wp-content/uploads, never the entire wp-content directory.
• WP cron is disabled by default. Kinsta replaces WP-Cron with a real server-side cron every 15 minutes. Plugins that schedule sub-minute jobs (WooCommerce action scheduler, some backup plugins) need to be reviewed; most are fine on 15-minute granularity, a few need their own external pinger.
• Search-replace serialized data correctly: Any migration that changes the domain (and almost all do, even from www to non-www) needs a search-replace pass on the database. The MyKinsta search-replace tool has a dry-run preview and handles PHP-serialized data; the WP-CLI wp search-replace command does the same. A raw SQL find-replace will corrupt serialized arrays and silently break plugin settings.
• Mixed content after HTTPS migration: If the source site was HTTP-only and Kinsta forces HTTPS, every hardcoded http:// URL in the database (and in widget HTML) needs to be rewritten. Run search-replace from http://oldsite.com to https://newsite.com, then audit with the browser console.
• WooCommerce-specific: Disable transactional email plugins before the cutover so customers do not get duplicate order emails from the staging URL. Clear WooCommerce transients (wp transient delete --all) after the move; stale transients are the most common cause of "products show wrong stock" reports the day after launch.
• Multisite: The wp-config.php constants (DOMAIN_CURRENT_SITE, PATH_CURRENT_SITE) need updating, the wp_blogs table needs a domain rewrite, and subdomain installs need Kinsta to enable a wildcard SSL via the support chat. Multisite is exactly the case to send to the white-glove team.

Migrating From Specific Hosts

Source-host quirks are predictable enough to plan around. Below is the short list for the providers we see most often in our review work and the sibling guides on this site.

• Bluehost and other shared-cPanel hosts: The /public_html path becomes /public on Kinsta. Cron jobs configured inside cPanel need to be recreated in MyKinsta. Bluehost's account-level email does not transfer; if you use it, move email to Google Workspace before cutting DNS. Our Bluehost guide covers the Bluehost-side prep.
• SiteGround: The SG Optimizer plugin must be deactivated and deleted before migration, otherwise it conflicts with Kinsta's server-level cache. SG's free CDN does not carry over.
• WP Engine: The closest match to Kinsta operationally, but WPE's must-use plugins (force-strong-passwords, wpe-update-notification) should be removed before copying wp-content. Their staging-to-production push tooling does not work post-migration.
• Cloudways: Cloudways runs the same Nginx-plus-Varnish style stack but on a different control plane, so the migration is largely cosmetic. Disable the Cloudways Breeze cache and Object Cache Pro before exporting, and re-enable Kinsta's equivalents afterward. The Cloudways guide covers their cache stack.
• GoDaddy and other budget shared hosts: Expect database exports to time out at 30 to 60 seconds. Use the white-glove migration with a backup file from UpdraftPlus or All-in-One WP Migration rather than handing GoDaddy credentials over, because their SFTP throttles aggressively.

Once the site is live on Kinsta, the next layer of work is performance tuning and account hygiene. Page-cache, CDN, Redis, and APM are all covered in the Kinsta WordPress optimization guide; user roles, 2FA, billing, and DNS at the registrar level are in the Kinsta account and domain management guide. For the pricing and review context behind picking Kinsta in the first place, start with the Kinsta pillar guide.

Ready to start? Try Kinsta and request a free migration directly from MyKinsta after signup.