Migrating a Site to a SpinupWP Server

Whether you’re moving a site from a managed WordPress host or a server you’ve set up yourself, this doc will guide you through the process of moving a site to your SpinupWP server with as little downtime as possible.

Overview

Moving a site to a SpinupWP server involves copying the site from the old server to the new server and testing it thoroughly. Once satisfied the site is working well on the new server, you put the old site in maintenance mode so that all visitors to the site are presented with a maintenance page. Then you copy the latest files and database from the old server to the new server again, do a quick test, then update the DNS for your domain name to point at the new server. Then do a final round of testing.

Of course that’s a high level description and it actually involves quite a few more individual steps:

Create and verify backups
Verify access to change DNS
Plan for downtime
Create new site on the SpinupWP server
Connect to the SpinupWP server via SSH
Copy site files to the SpinupWP server
Recommended WordPress plugins
Server configuration (optional)
HTTPS certificate installation (optional)
Testing
Staging mode
Copy database to the SpinupWP server
Test again
Enable full page cache
Maintenance window
Copy files and database again
Update DNS to point at the SpinupWP server
Final testing

We’ll use “old server” to refer to the server your site is currently running on, the server you’re migrating from. And “new server” will refer to the SpinupWP server, the server you’re migrating to. We’ll use IP addresses 199.229.249.140 and 216.3.128.12 for your old and new servers respectively, but obviously you’ll need to modify the commands with your servers’ IP addresses.

Be careful not to mix up your old server and new server as syncing files in the wrong direction could result in unwanted deletions. Also, be sure not to skip step 1, backing up your site and verifying that the backup works just in case you do make a mistake.

Let’s get started.

1. Create and verify backups

Before undertaking a major operation like moving a live site, you should first make sure that you have a backup of the site’s files and database. You should also try using that backup to set up a staging site to make sure that it works. If the backup is corrupt, you might as well not have one at all.

2. Verify access to change DNS

Moving a site to a new server almost always* involves changing the IP address that the site’s domain name is pointing to. Before you do anything to move your site, you should verify that you can login to your DNS provider and add/update DNS records for the domain name of the site you’re about to move.

Even if you’re pretty sure you have a login for this, it doesn’t hurt to test it. What if you’ve shared it with someone on your team and they’ve reset the password. Better to find that out now than when you’re ready to point your domain name at the new server.

And while you’re in there, have a look at the TTL of the DNS record for your site’s domain name. If the TTL is 5 minutes, it means a change in IP address should take effect within 5 minutes, which should work fine for your migration. If the TTL is 24 hours, that’s going to be a problem and you should update it to something shorter then wait 24 hours before starting your migration. If you can’t update your TTL to 5 minutes, we recommend switching your DNS to Cloudflare’s free DNS service.

If you don’t know who your DNS provider is or how to update your DNS, you’ll need to do some Googling and learning. Start with your domain name registrar’s documentation.

* If you’re using a floating IP address then you don’t have to update your DNS, but hey, you’re already ahead of the game and already knew that. 🙂 If you don’t know what a floating IP is, you’re probably not using one and will need to update your DNS.

3. Plan for downtime

Migrating a site to a new server almost always involves at least a few minutes of downtime. The database is always a bottleneck. Your downtime is going to be a function of the time it takes to export the database from the old server, copy it to the new server, and import it.

If you don’t have SSH access to your old server and aren’t able to use the rsync command to sync your site files directly to the new server from the old server, your downtime will increase. You’ll need to copy your site files from the old server to your local machine and then upload them to the new server which is far slower than syncing file changes with rsync.

If you can’t use rsync, you may be able to enforce a policy of no changes to the files on the server without putting the site in maintenance mode. Then you would only have to copy the files once. It really depends on the site though, so this is for you to determine.

Media files usually make up the bulk of site files and so are responsible for almost all of the file copy time. One strategy to reduce this time is to not have to copy media at all. By offloading all your media to cloud storage with a plugin like WP Offload Media, you won’t have to copy any of your media when moving servers ever again.

Once you estimate how long your downtime is going to be, you can decide if it needs to be scheduled for off-peak hours (who loves working at 3am?) and whether it’s necessary to email customers.

It’s also a good idea to prepare a simple HTML page named index.html for when you need to put the site on your old server in maintenance mode. Something like this:

<!doctype html>
<html>
    <head>
        <title>Back Soon</title>
        <style>
          body { text-align: center; padding: 150px; }
          h1 { font-size: 50px; }
          body { background-color: #e13067; font: 20px Helvetica, sans-serif; color: #fff; line-height: 1.5 }
          article { display: block; width: 650px; margin: 0 auto; }
        </style>
    </head>

    <body>
        <article>
            <h1>Back Soon!</h1>
            <p>
                We're currently performing server maintenance.<br>
                We'll be back soon!
            </p>
        </article>
    </body>
</html>

4. Create new site on the SpinupWP server

If you’re spinning up a server and/or adding a site for the first time, you may want to check out our Getting Started doc first.

When adding a new site via SpinupWP:

Enter the primary domain name of the site you’re moving and any additional domain names that will point at the site
Leave HTTPS enabled (unless you want your site to be slow)
When asked “Are you ready to point your domains at this server?”, select “No, I’d like to add TXT records to my DNS for now”
Add TXT records to the DNS of each of your domains so that an SSL/TLS certificate can be issued
Choose the Don’t Install any Files option
In the remainder of this guide, we’re going to assume you’re not setting up a git repository, so if you are, you’ll need to adjust.
Toggle the Create New database option and update the database name, username, and password to the values in your site’s wp-config.php
Temporarily disable full page cache to make testing easier

The rest of the default settings are fine, but you can update them as you see fit.

Once the site has been created on your new server it’s time to copy files over.

5. Connect to the SpinupWP server via SSH

Connecting to your new server via SSH and running commands is going to come up later in these instructions, so if you haven’t connected to your server via SSH yet, now’s a good time to try that. You should start with the Site User screen in SpinupWP for the site you set up in the previous step:

From this screen you can define an SSH key or password that will allow you to login to the server with the site user via SSH. Refer to the Helpful Hints in the sidebar if you need help with this.

Once you successfully login to your server via SSH from your local machine, you’re ready to proceed.

6. Copy site files to the SpinupWP server

There’s a big difference between copying site files to a new server via SSH and by other means. With SSH access to both servers it’s going to be a lot faster as you can copy directly from one server to the other. And later when you’re ready to switch over to the new server, you can quickly sync only the files that have changed since the original copy.

Without SSH you’ll have to download the files to your local machine and then upload them to the new server. And later when you’re ready to switch over to the new server, you’ll have to do it all again to ensure you get any files that have changed on the old server.

6a. Copy site files over SSH

First we need to allow our new server to connect to our old server. SSH into your new server (like you just did in step 5) and generate a key pair:

ssh siteuser@216.3.128.12
cd ~/.ssh
ssh-keygen -t rsa -b 4096 -C "216.3.128.12"

Now output the public key and copy it to your clipboard:

cat ~/.ssh/id_rsa.pub

Now SSH into your old server and add the public key to the authorized keys:

sudo echo "ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQ..." >> ~/.ssh/authorized_keys

Switch back to the command line of your new server and try connecting to your old server from there.

ssh username@199.229.249.140

Once you’re able to connect to your old server from your new server, we can copy your site files. We’ll copy the files directly from the public folder (a.k.a. web root) on your old server to the public folder on your new server:

rsync -azv username@199.229.249.140:/path/to/public/folder/ ~/files/

How long this takes depends on the amount of files as well as the speed of the connection between servers. If both servers are in the same data center it will be capable of very high speed.

If the rsync command completes quickly and it seems nothing has happened, it’s most likely that you’ve set up the command to run in the wrong direction. That is, you’re syncing your new server (an empty folder) to your old server instead of the other way around

6b. Copy site files without SSH

First you’ll need to determine how to get a copy of your site files from your old server.

Using a WordPress plugin to copy the files and database could work. If you’re already a WP Migrate DB Pro user, you could set up a fresh install of WordPress on your new server and run a migration to copy the database, media files, theme files, and plugin files to your new server.

Although we don’t recommend backup plugins for scheduled backups, they can be useful for backing up a site and restoring it in a new location. You might want to try a backup plugin. We don’t use backup plugins ourselves, so aren’t comfortable recommending any specific ones.

If your host offers downloadable backups, you could snag one of them. If they offer cPanel, Plesk, or another control panel, you can use their built-in backup tools to backup your site files and database and download it.

As a last resort (it’s painfully slow), you could download your site files via FTP/SFTP.

Once you have your site files downloaded to your local machine, you need to upload them to your new server. The best way to do this is via SSH.

If your site files are contained in a zip or gzipped tar archive (.tar.gz), upload that file and then decompress it on the server. To do this via the command line, you can use the scp command:

scp filename.tar.gz username@216.3.128.12:~/

If you don’t have scp on the command line, you can find an scp app easily enough for your operating system by Googling for it.

Once the upload is complete you can SSH to the server, create a new folder, move the compressed file into it, and change to that folder:

mkdir tmp
mv filename.tar.gz tmp
cd tmp

Now decompress the file. If it’s a tar.gz file:

tar -xzf filename.tar.gz .

For a zip file:

unzip filename.zip

This will decompress the files into the current folder.

Now you’ll need to sort out all the files that were in that archive. For example, if it’s a cPanel backup of your site it will have a copy of your database and some other stuff in addition to your site files.

Once you identify the site files, move them to the ~/files folder.

As for the remaining non site files that were in the archive, you might want to hang on to at least some of those for the next steps.

Whether you copy the site files over SSH, or use the scp command, your last step should be to make sure that the file and directory permissions are correct. You can do this by logging into your new server via SSH with the site user you created in step 5, and running the following commands:

cd ~/files
find . -type f -exec chmod 644 {} +
find . -type d -exec chmod 755 {} +

7. Recommended WordPress plugins

Some SpinupWP features will only work if you install a few WordPress plugins on your site. See the Recommended WordPress plugins doc for instructions.

8. Server configuration (optional)

A common reason for needing to modify the Nginx configuration on your new server is that you are coming from a host that used Apache and have some rewrite and redirect rules in an .htaccess file.

If it’s just redirect rules, you can add them as Path Redirects. Alternatively, you might prefer to use the Redirection plugin.

Only the root user can change Nginx configuration files on your new server. As such, you’ll need to create a sudo user and SSH to your new server as that user to run commands as root.

ssh username@216.3.128.12

Once you SSH into your new server with your sudo user, you can change to the Nginx configurations folder and edit the files with your preferred editor:

cd /etc/nginx/sites-available/sitename
vi sitename

9. HTTPS certificate installation (optional)

SpinupWP offers free Let’s Encrypt certificates for your sites so there’s almost never a need to move certificates from your old server. You can easily enable HTTPS by ticking a checkbox in SpinupWP and avoid this hassle.

Alternatively, if you already have custom SSL certificates, you will need to copy them to your new server. In order to do this, you will need to configure the old server to access the new server via a sudo user.

If you haven’t already, you will need to create a sudo user, and add your public SSH key to the sudo user.

Adding a sudo user

Next, SSH into the new server using the sudo user.

ssh sudo-username@216.3.128.12

Once you have logged in as the sudo user, you can create the location for the SSL certificates. We recommend creating a folder in the /etc/nginx/ssl/ directory, named for the site they will be securing.

sudo mkdir -p /etc/nginx/ssl/sitename

You will also need to create SSH keys for the sudo user:

ssh-keygen -t rsa -b 4096 -C "sudo@216.3.128.12"

Make sure to store the passphrase you enter for the SSH key, as you will need it when you SSH from the older server.

Output the newly created public key, and copy the output.

cat ~/.ssh/id_rsa.pub

Now SSH into your old server and add the public key to the authorized keys, just as you did for the site user earlier:

sudo echo "ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQ..." >> ~/.ssh/authorized_keys

You can now copy your existing custom SSL certificates to the new server, in the location you specified earlier.

scp /path/to/existing/ssl-certs/certificate-bundle.crt sudo-username@216.3.128.12: /etc/nginx/ssl/sitename/
scp /path/to/existing/ssl-certs/private-key.key sudo-username@216.3.128.12: /etc/nginx/ssl/sitename/

Once the certificate files are copied correctly, you can configure the certificates in SpinpWP by following the instructions in our Custom HTTPS Certificate help doc.

10. Testing

It’s a good idea to test your site on the new server as we go. You can do this by spoofing your local DNS, which will ensure your visitors are still using the site on the old server while you test the site on the new server.

On your local machine, add an entry to your /etc/hosts file that points your domain name at the new server’s IP address:

216.3.128.12    yourdomain.com

Once your hosts file is updated, you should see a WordPress installation screen when loading your site in a browser because we haven’t imported the database yet. Let’s handle that next.

Before continuing, remember that your domain name now points to the new server’s IP address. If you usually SSH to the server using the the domain name this will no longer work. Instead, you should SSH to each server using their IP addresses until the migration is complete.

11. Staging mode

When working on your site in a development environment or testing a copy of your site in a staging environment, there’s certain things you want to prevent. For example, you don’t want a staging site sending emails to your customers or processing live credit card transactions.

Usually developers have a way to put sites into “dev mode” or “staging mode” to prevent unwanted events from occurring. If you have such a mechanism, now is the time to enable it.

12. Copy database to the SpinupWP server

Whether you have SSH access to your old server or not, the basic process here is the same:

Export database from old server
Copy export file to new server
Import database on new server

However, if you have SSH access to your old server, you will be able to copy the export file directly to your new server. Otherwise you’ll have to download the export file to your local machine and upload it to the new server.

12a. Copy database over SSH

To export the database, issue the following command from the old server, replacing the database-username and database-name with those found in your wp-config.php file:

mysqldump --no-tablespaces -u database-username -p database-name > ~/export.sql

You will be prompted to enter your database password.

Now SSH to your new server, download that export file from the old server, and import the database:

scp username@199.229.249.140:~/export.sql ~/
mysql -u database-username -p database-name < ~/export.sql

12b. Copy database without SSH

If you already copied a full backup of your site in step 6, the site database may have been contained in that backup. You should take a look at the files that were decompressed to see if there’s a database export file (.sql) there.

If you already have a database export file on the new server, you can import with the following command:

mysql -u database-username -p database-name < export.sql

If you don’t have a database export file on your new server yet, you’ll need to download it and upload it to your new server. You’ll need to figure out how to access the database at your current web host. Most web hosts that don’t offer SSH access offer phpMyAdmin or some other web-based database software that allows you to download an export of the database.

Another option is to use our free WP Migrate DB plugin or another WordPress plugin to download an export of your database.

Once you have an export file downloaded, you’ll need to upload it to your new server:

scp export.sql username@216.3.128.12:~/

Then SSH to your new server and import it:

mysql -u database-username -p database-name < export.sql

13. Test Again

Now that your database has been imported, refresh the site in your browser to confirm that the database credentials are correct. If everything is working, you should now see the site.

You now have an exact clone of the live site running on the new server. It’s time to test that everything is working as expected. For e-commerce sites, you should confirm that the checkout process is working and any other critical paths.

We’ll be replacing this entire database shortly, so don’t save any new content for your site that you want to go live when you flip over to the new server. If you have new content that needs to go out, you should add it to the live site now. But remember, you’ll need to comment out that entry in your /etc/hosts file to access the live site on your old server.

14. Enable full page cache

When we created your new site in SpinupWP in step 4, we disabled the full page cache to make it easier to test your site. But now, before you migrate your site, you may want to enable the page cache and test your site again. If you’re running an ecommerce site or a membership site, you’re going to want to make sure that none of your dynamic pages (e.g. checkout and account pages) are being cached.

We highly recommend enabling the full page cache. There is a lot of unnecessary overhead in serving a page request otherwise. It’s slow to load WordPress, query the database and build the desired page on every single request. Instead, you should serve a static HTML version, a cached version of the requested page.

Once you’re happy that everything is working as expected, it’s time to perform the migration.

15. Maintenance window

Now that we have the site running smoothly on the new server, we need to put up the maintenance page we prepared in step 3 while we copy the latest files and database over to the new server.

As we mentioned earlier, if you’re confident no files have changed on the live server, you could skip copying over the files again. However, we do not recommend you skip copying the latest database over even if you suspect nothing has changed. Better safe than sorry.

15a. Modify old server Nginx config

If you have access to edit the Nginx configuration files on your old server, you can put up the maintenance page with the following instructions.

Upload the index.html file to the site’s public folder on the old server.

scp index.html username@199.229.249.140:~/files

On the old server, modify your site’s Nginx configuration file:

sudo vi /etc/nginx/sites-available/yourdomain.com

Ensure that the index directive looks like the following:

index index.html index.php;

This will ensure that our maintenance page handles all requests instead of WordPress. Once you’re done editing the configuration, be sure to reload Nginx.

15b. Update 404 handler

If you don’t have access to edit the Nginx configuration on your old server, your best bet is to rename your public folder, create a new empty public folder, place the index.html maintenance page in there alone, and update the 404 handler to that page.

mv files files2
mkdir files
scp index.html username@199.229.249.140:~/files

Now every request will be handled by your maintenance page.

To find out how to update the 404 handler at your web host, you’ll need to search their documentation or maybe even open a support request. If you have cPanel, Plesk, or another control panel, you could search its documentation.

15c. Confirmation

Your live site should now be in maintenance mode, but we should make sure it is. Remember that because of the change you made to your /etc/hosts file earlier, your machine is still pointing your domain name at your new server, so you should verify your maintenance page on your phone, tablet, or another computer. You could also just comment out the entry in your /etc/hosts file, check the maintenance page, and then uncomment it again.

If you don’t see the maintenance page, is your old server configured for full page caching? You might need to visit a page that isn’t cached to see the maintenance page. You could clear the cache to show the maintenance page for all requests or continue to serve most of your pages from the cache while you finish the migration.

It’s also worth noting that requests to admin-ajax.php and the WordPress REST API will be serving the maintenance page now so you will not be able to use plugins such as WP Migrate DB Pro to perform a push/pull migration.

16. Copy files and database again

Now that you’re sure all requests to your live site are being served by the maintenance page (or a cached page) you can copy the latest site files and database to your new server again. Go back and perform steps 6 and 12 again.

If you’re running rsync (step 6a), be sure to add the --delete switch to the command so that any files removed from the old server will be removed from the new server as well:

rsync -azv --delete username@199.229.249.140:/path/to/public/folder/ ~/files/

Once you’ve copied the latest site files and database from your old server to your new server, do a quick skim test to make sure everything is still working. If you have a critical path (e.g. the checkout of an ecommerce site), be sure to test that.

17. Update DNS to point at the SpinupWP server

Once you’re confident that everything is working as expected, log into your DNS control panel and update your A record(s) to point to the new server. This should start routing traffic to your new server, but remember the TTL we discussed in step 2. Anyone who has visited your site recently may still be routed to the old server and see the maintenance page. It will take the length of your TTL before all traffic is routed to your new server.

18. Final testing

While you’re waiting for all traffic to be routed, might as well do some more testing. Once you’ve fully tested the site and are satisfied, remove the entry from your /etc/hosts file that we added earlier and load the site in your browser.

If you still see the maintenance page, your DNS cache has still not expired and your domain name is still pointing at your old server. If that keeps up, you should double check your DNS to make sure that your A record update has taken effect. Then you could use a site like dnschecker.org to see what IP address other DNS systems are reading for your domain name. If it’s showing your new IP, chances are most of your traffic is seeing your new site even though you are still seeing your old site.

Finishing up

Now that your site is live on your new server, you might have some files to clean up and you should probably configure SpinupWP’s site backups, but otherwise, you’re good to go.