Some of you may prefer to migrate your WordPress site yourself, maybe due to sensitive data or perhaps you just want to do it immediately rather than coordinating with us. For migrating your site to Kinsta we highly recommend using the free WordPress Duplicator plugin, and therefore we’ve put together this in-depth guide for you.
However, please note that Duplicator may not be fully compatible with some WordPress sites. Our support team is always happy to help with basic migration questions, but cannot assist with failed migrations after the fact, as this falls outside of the scope of our support.
All of our plans include one or more free migrations. If you’re at all worried about the integrity of your data, we highly recommend using our professional migration team. Additional migrations can be purchased for a one-time fee of $100 and we also offer bulk migration pricing.
Overview of Duplicator Migration
Duplicator generates two files: a zip file containing an archive of all files + database, and an installer.php file that can be used to restore the site using the archive.
Once you’ve generated the archive file and downloaded both the archive file and the installer.php file, you simply upload those two files to your new Kinsta site and then run the installer.php file by accessing it using your temporary Kinsta URL.
Duplicator will then walk you through the restoration process. During the restoration process, you will be asked for the new database connection details. You will need to copy and paste the database access details found on the Info tab for the site inside your MyKinsta dashboard.
Duplicator will then update your wp-config.php file and rewrite the URLs in the database with the temporary Kinsta URL (e.g., example.kinsta.cloud). Rewriting the URLs will allow you to test your site as hosted on Kinsta without actually pointing your live site to Kinsta. (We’ll do that at the end once you’ve confirmed the site was migrated without issue, at which point we’ll also reverse the URL rewriting process to swap the temporary URL with your live URL in the database.)
- Preparing for the migration
- Creating the archive
- Restoring the archive
- Previewing your site before updating DNS
- Updating DNS
- Install Kinsta MU-plugin
Preparing for the Migration
Migrating a Multisite
If you’re migrating a WordPress Multisite network, there are a few things you’ll need to take into consideration. If you’ll be migrating a subdirectory multisite, you’ll need to contact Kinsta support to have them enable the necessary Nginx configuration for subdirectory multisite.
We also recommend reviewing the WordPress Duplicator plugin documentation for migrating WordPress Multisite. Other than the additional steps noted in Duplicator’s documentation, the steps below still apply.
Create a Backup on your Current Host
If your existing web hosting company has a way to create a full-site backup, go ahead and do that before proceeding with the migration. The migration process itself should not have any effect on your live site, but it doesn’t hurt to create a backup beforehand and backups are always a good idea.
If your existing web hosting company does not have an option to create a full-site backup, then you can skip this step.
Create the Site on Kinsta
Create a new site inside your Kinsta account for this migration. On the MyKinsta Dashboard, select Sites → Add Site and be sure to choose “Don’t install WordPress” (we’ll be migrating your existing WordPress site over so there’s no need to install WordPress).
Important: Do not select the “Custom domain” option.
Creating the Archive
The next step is to create an archive of your current site using the Duplicator plugin. In this section, we’ll install the WordPress Duplicator plugin on your site, build an archive package that includes all your files and database, and download the archive and the installer.php file.
Disable Caching Plugins
Caching can cause problems during migrations, so it’s best to disable any caching plugins (e.g., Autoptimize, W3 Total Cache, etc.) before creating the archive that you’ll transfer to Kinsta. We have a list of banned plugins that you’ll also want to review.
Install and Activate the Duplicator Plugin
On the WordPress Dashboard for the website you want to migrate, visit Plugins → Add New and search for “Duplicator”. Install and activate “Duplicator – WordPress Migration Plugin”.
Create the Site Archive
Once you have activated the Duplicator plugin, visit Duplicator → Packages and click the Create New button to create a new archive package.
Follow the prompts through the three steps to build an archive package. In most cases, you should be able to use the default settings.
It’s highly recommended that under the Installer option you enable password protection.
Download the Archive and Installer File
Once the archive package has been built, download both the Archive file and the Installer file to your local computer. You’ll need to upload these files to your new Kinsta site in the next step.
Restoring the Archive
Transfer the Archive and Installer File to Kinsta
The next step is to upload the archive package and the installer file to your new Kinsta site via SFTP (see how to use SFTP). Upload both files to the the public/ directory. The public/ directory should be empty. If it’s not empty, you might already have a WordPress installation on this site and you should remove that before uploading and restoring the archive.
Restore the Archive
Once you have uploaded the archive file and the installer file, you can run the Duplicator installer by visiting the installer.php file in your browser using the temporary Kinsta URL. You’ll find the temporary Kinsta URL on the Domains tab for your site inside the MyKinsta dashboard.
In this example, the temporary URL is example.kinsta.cloud so the URL to the installer file that we need to visit is http://example.kinsta.cloud/installer.php.
On Step 2 of the Duplicator process, ensure that you enter the Database details for your new Kinsta site. You’ll find the Database Access details for your Kinsta site on the Info tab for the site inside the MyKinsta dashboard.
Use the Test Connection button to confirm that you have entered the correct Database Access details on the Duplicator form before proceeding with the restoring by clicking the Next button.
In Step 3 of the Duplicator process, Duplicator will update the database to use the Kinsta temporary URL. This step ensures that you will be able to login and test the site when the migration is completed. If your existing site is using SSL (HTTPS), please ensure that the temporary URL in the URL field is updated to include https://.
Once the Duplicator process has finished, click the Site Login button to login to your site.
Important: Make sure that the login page you are redirected to includes the Kinsta temporary URL and not your live site URL. If it contains your Live site URL, then your migrated database likely contains references to the Live site that will need to be replaced manually.
If everything went OK you should see a message indicating a successful migration upon login.
Cleaning Up the Archive Files
Once you have finished restoring the site on Kinsta, it is recommended that you delete the Duplicator archive and installer files for security purposes. If you’d rather not delete them, you can temporarily move them outside the public/ directory and into the private/ directory. The following files should be deleted or moved out of the public directory:
Previewing Your Site Before Updating DNS
At this point in the migration process, you should be able to browse and test your site on Kinsta using the temporary Kinsta URL (e.g., http://example.kinsta.cloud/).
The next step will be to test your site using the actual domain (e.g., http://example.com/). This involves two steps: adding the www and non-www version of the domain to the site inside MyKinsta and pointing that domain to the Kinsta IP in your local hosts file.
Step 1: Add Domains to Kinsta
For the Nginx web server to recognize your domains, you must add them to the domains tab for the site. If you see a message about “No Site for this Domain”, that likely indicates that the web server does not recognize the domain.
On the Domains tab for the site, add both the www and non-www version of the domain to the list (e.g., both www.example.com and example.com) and then set whichever one you prefer as the Primary Domain.
Step 2: Update the URLs in the Database
Now you’ll need to do a search and replace on your WordPress database to ensure that WordPress uses the actual domain for your site and not the Kinsta temporary domain.
There are various ways to do a Search and Replace on the WordPress database, but we recommend using the Search and Replace tool available inside MyKinsta on the Tools tab for the site. For instructions, please see how to perform a WordPress search and replace.
Step 3: If Your Site Uses SSL (HTTPS)
If your site is currently using SSL (HTTPS), it’s important to note that it won’t be possible to preview the site over HTTPS using the live domain until you either install a Custom SSL certificate on the Kinsta site or until you point the DNS for the domain at the Kinsta IP address, at which time you can generate a free Let’s Encrypt SSL certificate. Generating a free Let’s Encrypt SSL certificate requires that the domain is pointing at the Kinsta IP address.
If you have a Custom SSL certificate with the .crt and .key files, you should be able to install that SSL certificate on the Tools tab for the site under Enable HTTPS and that should allow you to preview the site over SSL using the method described in the next step.
If your current site uses a Let’s Encrypt certificate, you will need to generate a Let’s Encrypt certificate on the Kinsta side, however generating a Let’s Encrypt certificate requires that the domain is pointing at the Kinsta IP address, which you won’t want to do until after you’ve tested the site.
If you don’t have a Custom SSL certificate and you cannot generate a Let’s Encrypt SSL certificate, then you have two options. The first option is to go ahead and update the DNS to point at the Kinsta IP address. However, note that once you update DNS visitors will see an SSL warning until the DNS has propagated and a Let’s Encrypt certificate has been generated.
If your site is behind a proxy service or WAF such as Cloudflare or Sucuri, you’ll also want to ensure you follow the additional recommended steps for issuing a Let’s Encrypt certificate.
The second option is to run a search and replace to update the URLs in the database to use http:// so that the site loads over http:// instead of https://. Then you can update the DNS, generate the Let’s Encrypt SSL certificate, and finally, run a second search and replace to switch the domains back to https://.
Step 4: Updating Your Local Hosts File
Once your WordPress database has been updated with the correct domain, you can point the domain at Kinsta’s IP address for the site using your local hosts file.
If after updating your local hosts file you’re still seeing the domain pointing to the original web host, please try clearing your local DNS cache and your browser cache:
When you’re ready to point your domain at Kinsta, you’ll need to update the DNS for your domain to point it at the Kinsta IP address for your site. Please see the following article:
Install Kinsta MU-Plugin
Our Kinsta MU-plugin is automatically installed on fresh WordPress installations done here at Kinsta. However, since you’ve migrated your site yourself, you’ll need to download and install the Kinsta MU plugin manually. This includes our full page caching and other functionality such as the ability to deploy the Kinsta CDN.
Step 1: Download and Unzip the Plugin
First, download the Kinsta MU-plugin and unzip it.
Step 2: Upload to Site
You’ll then need to connect to your site via SFTP and upload the
kinsta-mu-plugins folder and
kinsta-mu-plugins.php file to the
/wp-content/mu-plugins/ directory doesn’t exist, create it first and then drop in the above file and folder.
Save time, costs and maximize site performance with:
- Instant help from WordPress hosting experts, 24/7.
- Cloudflare Enterprise integration.
- Global audience reach with 28 data centers worldwide.
- Optimization with our built-in Application Performance Monitoring.