The Tool Desk
Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →Move a WordPress site from Kinsta by copying both the complete WordPress file tree and its SQL database, freezing changes while the copy is made, testing the new server privately, and changing only the DNS record that points web traffic to the destination. Keep the Kinsta installation and a separate backup until the new site has handled real traffic successfully.
Antihost offers managed WordPress hosting with free migration, one-click staging and a 14-day free trial.
A media export or WordPress content export is not a like-for-like migration: it omits settings, plugin data, theme files, uploads outside the library, and other database tables. The procedure below covers a standard single-site installation and identifies the extra work required for multisite, ecommerce, membership, and heavily customized deployments.
As an Amazon Associate I earn from qualifying purchases.
Free tools Windows power users keep installed
One-click scans. No signup required.
What a complete Kinsta migration contains
A working WordPress site is a combination of files, database records, server settings, and external services. Copying only one part can produce a site that appears online but is missing content, logins, media, or integrations.
| Component | What to move or recreate | Why it matters |
|---|---|---|
| WordPress files | The entire document root, including wp-content, plugins, themes, uploads, mu-plugins, and custom files |
These files contain the code and media that the database references. |
| SQL database | All WordPress tables, custom plugin tables, options, users, and content | Posts, pages, settings, accounts, orders, and plugin state live here. |
| Configuration | Database credentials, salts, environment variables, PHP settings, scheduled tasks, and web-server rules | The destination must be able to connect to the imported database and run the same application. |
| Domain services | DNS records, SSL, CDN, email routing, API callbacks, and redirects | These services are usually outside the file-and-database backup. |
Kinsta describes its downloadable backup archives as snapshots of site files and database content. Keep the archive intact and retain a separate SQL copy as a rollback asset; store at least one copy outside your Kinsta account.
#1 Best Overall
Plan the move and freeze changes
Build an inventory
Before downloading anything, record every dependency that must exist on the new host:
- Primary domain, www variant, subdomains, parked domains, and multisite mappings.
- Redirect rules, canonical URL settings, robots.txt, XML sitemaps, and any custom Nginx or Apache rules.
- Active plugins, themes, mu-plugins, PHP extensions, image-processing requirements, and licensed integrations.
- Uploads, private downloads, custom directories, server-side scripts, and writable directories.
- WP-Cron tasks, system cron jobs, queues, webhooks, payment callbacks, analytics, CDN settings, and transactional email.
- Where DNS is hosted, which records deliver email, and whether any service depends on the current IP address.
- PHP and database versions, available disk space, SSH or SFTP access, SSL support, caching behavior, and backup/restore tools at the destination.
Choose a low-risk window
Schedule the copy during a quiet period and decide how long the private test will last. Kinsta’s migration guidance says not to change the site after migration begins because updates made after that point will not carry over. For a store, membership site, forum, or any site that receives comments or registrations, enable maintenance mode or another write-blocking mechanism before the final export. This prevents orders, accounts, comments, and form submissions from diverging between the two databases.
Create portable backups on Kinsta
Use Kinsta’s downloadable backup facility to create a full snapshot, then download it before touching DNS. Also export the database as a standalone SQL file when possible. The archive protects the complete filesystem; the SQL file gives you a straightforward way to inspect or restore database content independently.
- Open the site’s backup area in MyKinsta and create or select a recent backup.
- Download the backup archive to a computer or storage location that is not dependent on the Kinsta account.
- Export the database through phpMyAdmin or an equivalent database tool and save the resulting
.sqlfile. - Record the backup timestamp, WordPress version, PHP version, database name, and the size and checksums of the downloaded files.
- Do not delete the Kinsta site, its backups, or its DNS information while the destination is being tested.
If the site is large, verify that the download completed rather than assuming a browser transfer succeeded. An incomplete archive can look plausible but fail during extraction or omit late files.
Prepare an empty destination environment
Create a new, empty WordPress-capable site at the destination host. Do not install a second copy over an existing production database unless you have deliberately reserved it for this migration. Confirm the following before uploading:
- The PHP version and required extensions are compatible with the current WordPress core, theme, and plugins.
- The database engine and version can import the exported SQL, including its character set and collation.
- There is enough storage for the full file tree, database, backups, logs, and temporary import files.
- You have SFTP or SSH credentials, database credentials, and a way to edit environment variables or
wp-config.php. - HTTPS certificates can be issued for the domain, and the host supports the PHP workers, memory limits, upload limits, and timeouts your site needs.
- Scheduled tasks, object caching, page caching, queues, and server-level cron jobs can be configured rather than silently disabled.
- Multisite, Bedrock/Trellis, reverse-proxy, or custom Nginx requirements are supported. If they are not, obtain a specialist migration plan before copying files.
Copy the files and database
Download and upload the file tree
- Connect to Kinsta with SFTP and download the complete WordPress document root. Include
wp-content, all plugins, themes, uploads, mu-plugins, hidden files, and any custom directories. Do not limit the download to the media library. - Extract the archive locally if necessary and compare its size with the source directory. Preserve file permissions and symbolic links where the destination supports them.
- Upload the files to the destination document root with SFTP or SSH. Ensure the web-server user can read WordPress files and write to directories that need updates or uploads.
- Keep the original
wp-config.phpas a reference, but do not blindly overwrite destination-specific settings. Database credentials, salts, paths, cache drop-ins, and environment variables may need adjustment.
Export and import SQL
- Export every table in the site’s WordPress database as SQL. Include custom tables created by ecommerce, membership, form, search, or analytics plugins.
- Create an empty database and database user at the destination. Grant that user the permissions required by WordPress.
- Import the SQL file through phpMyAdmin, the host’s database tool, or the command line. Large databases may require a command-line import or an increased upload and execution limit.
- Update
wp-config.phpor the host’s environment variables with the destination database name, user, password, host, and table prefix. Keep the existing salts unless you intentionally want to invalidate every logged-in session. - Check that the imported table prefix matches the prefix configured in WordPress. A mismatch can make a complete database appear empty.
Do not run a search-and-replace across the SQL file until you know whether the domain is changing. WordPress and plugins store serialized data; use a serialization-aware tool for URL replacements rather than a blind text substitution.
Do these 3 things before closing this tab:
1Fix the driver behind crashes, sound loss and screen glitches2Clear out junk files and repair common Windows errors3Scan for outdated or missing drivers - takes under a minuteConfigure the domain, URLs, SSL, and services
Keep the existing domain during the move
For a migration to a new host with the same domain, leave the database URLs unchanged. Add the domain to the destination, issue an SSL certificate, and use a preview address or hosts-file override for testing. Changing URLs unnecessarily creates extra redirects and can break serialized settings.
Change URLs only when the domain itself changes
If the domain is changing, update both the WordPress Address and Site Address after the destination is reachable. Replace old URLs in posts, menus, options, and plugin data with a serialization-aware search-and-replace process, then test redirects and canonical links. A domain change is a separate SEO and redirect project, not merely a hosting change.
Recreate application services
- Install and verify the SSL certificate before public cutover; test both HTTP-to-HTTPS redirection and the canonical hostname.
- Recreate server cron jobs if the site relies on real cron rather than WP-Cron. Confirm queue workers run at the expected frequency.
- Configure transactional email with the provider’s required DNS records and credentials. Send test messages to more than one mailbox.
- Reattach the CDN, image optimization, object cache, payment callbacks, webhooks, analytics, and any allowlisted IP addresses.
- Review cache rules so logged-in users, checkout pages, account pages, and form endpoints are not served stale or publicly cached responses.
Test privately before changing DNS
Never make the first test after the DNS switch. Use the destination host’s preview or staging URL, or map the domain to the new server only on your own computer with a hosts-file entry. A hosts-file test uses the destination IP and domain, for example:
203.0.113.42 example.com www.example.comReplace the example address with the actual destination IP. Flush the local DNS cache after editing the file, test in a private browser window, and remove the entry when finished. Other visitors will continue reaching Kinsta while you test.
Private-test checklist
- Open the homepage, representative posts, pages, categories, search results, archives, author pages, and custom post types.
- Sign in and perform administrator actions: edit content, upload media, update a plugin, and save settings.
- Test pretty permalinks, pagination, feeds, robots.txt, XML sitemaps, canonical tags, redirects, and 404 handling.
- Check every important image, download, video embed, responsive layout, menu, and accessibility-sensitive interaction.
- Submit forms and verify delivery, spam protection, confirmation pages, and CRM or webhook callbacks.
- For stores or memberships, test registration, login, password reset, cart, checkout, payment return, order email, account pages, and entitlement checks in the provider’s safe test mode where available.
- Review PHP, web-server, database, and application logs for warnings, fatal errors, missing files, blocked requests, and database timeouts.
- Confirm analytics receives page views without counting the same visit twice and that staging or preview access is not accidentally indexable.
Change DNS without breaking email
When testing passes, lower the relevant DNS record’s TTL ahead of the cutover if your DNS provider permits it. At the change window, update only the web record that should point to the destination: usually the domain’s A record or a CNAME for the www hostname.
Do not replace the entire DNS zone or change nameservers merely to move a website. Nameserver changes can remove MX, SPF, DKIM, DMARC, verification, API, or other records used by email and third-party services. If you must move DNS hosting, copy and verify every existing record first, including records for subdomains and mail.
Kinsta documentation gives approximately one hour as a typical DNS propagation time, while another Kinsta reference notes that propagation can take up to 48 hours depending on TTL and network conditions. Treat these as ranges, not guarantees. During propagation, different networks may reach different servers.
Monitor the cutover and keep a rollback path
After changing DNS, check the site from multiple networks and locations. Verify the certificate, canonical hostname, redirects, login, forms, orders, email, analytics, uptime, cache behavior, and error logs. Watch both the destination and the old Kinsta site for unexpected traffic or missed writes.
Outdated Drivers Are Slowing You Down
One free scan finds every outdated or missing driver and matches the right update for your exact hardware.Free scan · exact hardware matchPC Slower Than It Used to Be?
A free scan shows the junk files, broken settings and background clutter dragging Windows down - then fixes them in one click.Free scan · Windows 10 & 11Keep the Kinsta environment publicly usable, or at least recoverable, until the destination has remained stable through the period in which DNS caches could still direct visitors to the old server. Preserve the downloaded archive and SQL backup as well. If a critical defect appears, you can point the web record back to Kinsta, restore the destination from backup, and investigate without losing the original installation.
How to evaluate the destination host
Price alone does not determine migration risk. Compare the operational features that affect your particular site:
| Decision area | Questions to ask the destination host |
|---|---|
| Migration assistance | Is a hands-on migration included, what information is required, and is expedited service available? |
| Preview and staging | Can you test the copied site privately without changing public DNS, and can staging be refreshed safely? |
| Backup and restore | Can you download complete file-and-database backups and restore them independently? |
| Access | Are SFTP, SSH, database tools, logs, and environment-variable configuration available? |
| SSL and DNS | Does the host automate certificates while allowing you to keep DNS elsewhere and manage records precisely? |
| Performance services | How are page cache, object cache, CDN integration, image processing, PHP workers, and resource limits configured? |
| Application behavior | Are multisite, cron, queues, webhooks, long-running tasks, and custom server rules supported? |
| Does the host provide sending infrastructure, or must you connect an external transactional mail service? | |
| Rollback | How quickly can you restore a backup or reverse the DNS change if the migration fails? |
Kinsta’s 2026 documentation lists an expedited migration price of $49 per site and an eight-hour target during a stated weekday UTC window. Those figures describe that service’s stated objective and price at that time; confirm current terms directly if you are considering assisted migration.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Special cases that need extra planning
WooCommerce, membership, and community sites
These sites receive writes continuously. Put the site into maintenance mode for the final export, or use a controlled synchronization strategy handled by an experienced administrator. Record the exact time writes stop, export after that point, and do not reopen transactions until the destination has been tested.
Multisite networks
Migrate the network as one unit: database tables, uploads, network settings, domain mappings, and rewrite rules must agree. A single-site export cannot reproduce a multisite network. Test subsites, mapped domains, network administration, signup or registration behavior, and media paths before cutover.
Bedrock, Trellis, reverse proxies, and custom Nginx
These deployments may keep configuration outside a conventional document root and may depend on Composer, environment files, deployment hooks, or proxy headers. Recreate the deployment structure rather than copying files into a standard one-click WordPress directory. Have a specialist review the plan when the destination cannot reproduce those assumptions.
Large or high-write databases
Browser-based exports can time out or exceed upload limits. Use a command-line export/import path, compress the SQL file, and schedule a final short write freeze. Check table counts and application behavior after import instead of relying only on a successful upload message.
Troubleshoot common migration failures
“Error establishing a database connection”
Recheck the database host, name, user, password, port, permissions, and table prefix in the destination configuration. Confirm the database service is running and that the imported tables exist.
Recommended Free Tools
Homepage works but inner pages return 404
Save the permalink settings once in WordPress to regenerate rewrite rules, then inspect the destination’s Apache or Nginx configuration. Verify that the web root points to the directory containing index.php.
Images or downloads are missing
Confirm that the full uploads tree and any private-download directories were transferred, that filename case matches the database references, and that file permissions allow the web server to read them. Check whether a CDN still points at the old origin.
Redirect loops or mixed-content warnings appear
Ensure the SSL certificate covers every hostname in use, set one canonical HTTPS hostname, and remove conflicting proxy or cache rules. Update hard-coded HTTP asset URLs only after confirming the domain and protocol configuration.
Forms, cron jobs, or webhooks stopped
Recreate scheduled tasks, verify environment variables and API secrets, allowlist the new server IP where required, and send a real test submission. Inspect logs for blocked callbacks and authentication failures.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Users are logged out
Check that the domain, cookie settings, salts, HTTPS state, and proxy headers match the source configuration. Changing salts deliberately logs out every user, so treat that as a planned security action rather than an accidental migration side effect.
Quick Recap
Recommended runbook
- Inventory domains, services, code, scheduled work, and DNS records.
- Schedule a low-traffic window and freeze writes when the transfer begins.
- Create and download a complete Kinsta backup plus a separate SQL export.
- Build an empty, compatible destination and configure access.
- Upload the full file tree and import every database table.
- Adjust destination credentials and recreate SSL, cron, cache, email, CDN, and integrations.
- Test through preview, staging, or a hosts-file mapping while Kinsta remains public.
- Lower TTL if practical, then change only the required A or CNAME record.
- Monitor both environments through DNS propagation and verify real user journeys.
- Retire the Kinsta site only after the destination and its backups are demonstrably stable.
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
