Can I migrate off Kinsta without SSH access?

Yes, but it's slower. Use MyKinsta's dashboard to download a full site backup as a zip, and export the database through phpMyAdmin if it's under the size limit. SSH with WP-CLI is faster and avoids export size caps, so it's worth enabling if your plan supports it.

Will my email break during the migration?

Only if you forget to copy the MX, SPF, and DKIM records into Getwebup's DNS zone before cutting over. Kinsta never hosted your email, so as long as you mirror the existing mail records exactly, mail keeps flowing through the same provider the whole time.

Why does my site show fatal errors right after moving to Getwebup?

This almost always comes from Kinsta's must-use plugins or its Redis object-cache drop-in still sitting in wp-content. Delete the kinsta-mu-plugins folder and any object-cache.php file, then reload — those files reference Kinsta's internal infrastructure and won't work anywhere else.

Do I need to change my domain's nameservers or just the A record?

Either works. Pointing the A record to Getwebup's server IP is faster to reverse if something goes wrong. Switching nameservers hands over full DNS management, which is cleaner long-term but takes longer to propagate — plan for up to 24-48 hours either way.

How long should I keep the old Kinsta site running after cutover?

At least 24-48 hours. DNS changes don't reach every visitor and resolver instantly, so some traffic will still hit the old server during that window. Don't delete or downgrade the Kinsta site until traffic to it has dropped to near zero.

Kinsta to Getwebup Migration Guide

Kinsta doesn't give you cPanel, doesn't host your email, and locks a few things down in ways that trip people up mid-migration. If you're moving a WordPress site from Kinsta to Getwebup, here's the whole process — files, database, DNS, and the Kinsta-specific gotchas — without the site going dark.

Why a Kinsta migration isn't like the others

Most "migrate to Getwebup" guides assume you're coming from shared cPanel hosting, where you can just zip the whole account and pull it over. Kinsta is different on a few fronts:

No cPanel, no File Manager. Everything goes through SFTP/SSH or the MyKinsta dashboard.
Email isn't hosted there. If your mail currently works, it's already on Google Workspace, Zoho, or similar — the migration won't touch it, but your DNS cutover has to preserve those MX records carefully.
Kinsta's own edge cache and object cache sit in front of WordPress. A page that looks fine on Kinsta might load a stale or broken version right after cutover if you don't clear caches on both ends.
Database size limits. Kinsta caps phpMyAdmin exports around 2GB in some plans, so large stores or sites with years of post revisions often need a different export method.

Before you start: the checklist

A Getwebup hosting account (or VPS) with PHP version matching what the site currently runs — check MyKinsta → Site → Info for the current PHP version.
SFTP or SSH credentials from MyKinsta (Site → Info → SFTP/SSH Access).
Admin access to WordPress itself, in case you need a migration plugin.
Your domain's current DNS records noted down — especially MX, TXT (SPF/DKIM), and any CNAMEs for third-party services (help desks, verification records, etc.). You'll need to recreate all of these on Getwebup's DNS.
A maintenance window mindset, even though the goal is zero downtime — do this when traffic is lowest, just in case.

Step-by-step migration

1. Get your files off Kinsta

SSH in and tar the whole WordPress root — it's faster and more reliable than dragging thousands of files over SFTP:

ssh kinsta-user@yourserver.kinsta.cloud -p PORT
cd /www/yoursite_123/public
tar -czf ~/site-files.tar.gz .

Then pull it down with scp or sftp, or use MyKinsta's built-in "Download" option under Site → Info if you'd rather avoid the command line.

2. Export the database

For most sites, WP-CLI is the cleanest route if you have SSH access:

wp db export site-db.sql --path=/www/yoursite_123/public

If the export is large (WooCommerce stores with years of order history, or sites with bloated wp_options), compress it before transferring:

gzip site-db.sql

If you hit phpMyAdmin's export size limit in MyKinsta, WP-CLI is the workaround — it doesn't go through the browser at all.

3. Set up the destination on Getwebup

Create the hosting account or addon domain, add the site's domain (as a temporary/parked domain if you're not cutting DNS yet), and create a fresh MySQL database and user through cPanel's MySQL Database Wizard. Note the new database name, username, and password — you'll need them in wp-config.php.

4. Upload and import

Upload site-files.tar.gz into the new account's public_html (or the addon domain's folder) via SFTP, then extract it through cPanel's File Manager or SSH:

tar -xzf site-files.tar.gz

Import the database through phpMyAdmin (for smaller files) or via command line for larger ones:

mysql -u dbuser -p dbname < site-db.sql

Update wp-config.php with the new database name, user, password, and host (usually localhost on Getwebup shared/VPS setups).

5. Fix URLs and Kinsta-specific leftovers

If the domain isn't changing, your URLs in the database should already match — but two things from Kinsta commonly need cleanup:

Kinsta MU plugins. Kinsta auto-installs must-use plugins into wp-content/mu-plugins/ for their caching and monitoring. These reference Kinsta's internal APIs and will throw errors or do nothing useful on Getwebup — delete the kinsta-mu-plugins folder.
Object cache drop-in. If the site used Redis via Kinsta's managed object cache, delete wp-content/object-cache.php — it points at a Redis instance that no longer exists. WordPress will fall back to normal caching without it.

Then test the site using a hosts-file override (point your domain to the new server IP locally) or Getwebup's temporary preview URL before touching DNS.

6. Preserve email while you cut over DNS

This is where most "zero-downtime" migrations actually break something — not the website, but email. Before changing nameservers or the A record, copy every MX, SPF (TXT), and DKIM record from the old DNS zone into Getwebup's Zone Editor exactly as they were. If you're using Google Workspace, that typically means the five ASPMX.L.GOOGLE.COM MX records plus your SPF TXT record.

Record type	Purpose	Common mistake
MX	Routes incoming mail	Forgetting a priority value or copying only one of several MX records
TXT (SPF)	Authorizes sending servers	Creating a second SPF record instead of merging into the existing one
TXT (DKIM)	Signs outgoing mail	Missing the selector prefix (e.g. `google._domainkey`)
CNAME	Third-party service verification	Skipping records for tools like Zendesk, Calendly, or a CDN

7. Cut over DNS

Once the site is verified working on Getwebup and email records are mirrored, update the A record (or nameservers) at your registrar. Keep the old Kinsta site running and untouched for 24–48 hours — DNS propagation isn't instant, and some visitors will still hit the old server during that window.

Common post-migration issues

Site loads but looks broken/outdated: almost always a caching issue. Purge any CDN (Cloudflare, etc.) and clear the WordPress cache plugin if you installed one on the new host.
Fatal error on load: usually a leftover Kinsta MU plugin or object-cache drop-in — see step 5.
Emails stop arriving: compare the new DNS zone against your notes from before you started; a missing MX priority is the usual culprit.
Login redirect loop: check that WP_HOME and WP_SITEURL aren't hardcoded to the old Kinsta staging URL in wp-config.php.

Prevention: what to do differently next time

Keep a written copy of your DNS zone before any migration, not just for this one. Test the destination server on a temporary URL before flipping anything live. And once you're on Getwebup, set a calendar reminder to double-check MX and SPF records a week after cutover — a lot of "email suddenly stopped working" tickets trace back to a record nobody re-checked after go-live.

Migrating a WordPress Site from Kinsta to Getwebup