Sometime in 2016, I moved my blog (this one) to an AWS EC2 instance (t2.micro) running Amazon Linux. It seemed like a good idea at the time, since my prior hosting (Gandi.net) was shutting down their US-based datacenter. I had to move it somewhere, and running it on my own server for ~$10/mo had the added “benefit” of a dedicated host to tinker with. I think I was bored when I made that decision or I would have chosen something with less risk/overhead.
In the intervening months, I found myself returning to a time when server/application “health” was achieved by routinely rebooting the server running it. Apparently a t2.micro isn’t really enough for even a lightweight blog and LAMP setup like mine, because every few weeks, I’d refresh it to find the database connection failing (out of memory, maybe?). So I’d hit the AWS Console and reboot the instance (because it never happened when I had free time). That brought it back to life for another few weeks before it’d crash again. And so 2017 went.
The Christmas season presented me with a bit of time to finally escape this relatively expensive sub-par experience, so I finally executed on my plan to move my domain to Google Domains and my hosting to Namecheap. Fill in “Namecheap” with almost any generic hosting provider using cPanel, and you’ll be able to apply the steps below. There are other ways to do this (some surely easier), but this is the path I took. Feel free to chime in with others!
Step 1: Pre-move housekeeping
Just like moving apartments or houses, the shift can be easier if you get rid of junk you don’t need before you shovel it to your new home. In WordPress land, that can be achieved by:
- Deleting unused themes
- Deleting retired or unused plugins
- Pruning your media library–especially unattached items
With the bit bucket full and your WP site lean, let’s move to Step 2.
Step 2: Install the UpdraftPlus plugin
Updraft is a great backup tool for WordPress. It writes the backups locally but can also ship them to any number of external locations like Google Drive, Dropbox, etc, so your site is safe, whether from a bad update or from a malicious actor. It does have a restore/migrate feature if you pay for it, but that’s a different blog.
Anyways, after you install it, go to Current Status and click Backup Now. This isn’t necessarily the backup you’ll use, but it’s good before proceeding with Step 3.
Step 3: Update WordPress and any plugins
WordPress has come SO far in the past years, but I’m still skittish every time I update the core of WP itself. Like Left Ear with dogs in The Italian Job, “I had. a bad. experience.” The years since haven’t erased that desperate feeling when the update bombed and I was left staring at a 500 error, hoping I could find my way back (I did). Anyways, that’s what UpdraftPlus is for.
So, go on, hit Dashboard > Updates, update the Plugins first (assuming all say “100% compatible” with 4.9.1 or whatever’s latest when you read this), and then hit the big kahuna of WordPress itself. Whatever you do, don’t get impatient and click Back or anything while it’s updating or you will have a bad experience, too.
Updating WordPress itself might not be necessary, but since your new hosting likely standardizes on and tests the latest version (if you were to deploy a clean, new WP site), it seems prudent to get up to the latest before making the leap.
Step 4: Run another backup
You’re on the latest version now, so it’s time to run another backup to load on the truck and begin the move. Go to UpdraftPlus (at the top of your admin console) > Current Status > Backup Now.
Step 5: Download the database
While you might have phpMyAdmin on your EC2 instance, UpdraftPlus makes this so easy. Within UpdraftPlus, go to Existing Backups and click Database next to the most recent backup. This will download it in a gzip format.
Step 6: Download the WordPress files
Since WordPress is often composed of thousands, even tens of thousands of files (depending on your themes, translations, plugins and media), it is prudent to tar and gzip the files before downloading them to your computer. Yes, UpdraftPlus does backup most of the files, but it focuses on content, assuming that you’ll deploy wp-core from WordPress.org and then restore on top of it. This blog is about doing an entire lift-and-shift without a core install first.
- SSH to your EC2 instance (remember to chmod 400 your pem file if you don’t connect often…or ever)
- From /home/ec2-user (or your home directory), run
tar -czvf wordpress.tar.gz /var/www/vhosts/www.yourblog.com
(if it errors, you might be in a path where you don’t have permission to write; hence, run from your home directory)
- Use scp or Filezilla to download the tarball of your site (so much faster than the individual transfer of thousands of tiny files)
Step 7: Create and prepare the MySQL database in cPanel
- In cPanel, scroll down to DATABASES and click MySQL Databases.
- Under Create New Database, provide a name for your database (i.e. “blogname”)
- Click Create Database — this creates a database with name <prefix>_<name>
- Scroll down to MySQL Users and Add New User
- Provide a username and password for the account WordPress will use to connect to the MySQL database, and click Create User
- Now go to Add User To Database, select the user and database just created, and click Add
- On the Manage User Privileges page, select ALL PRIVILEGES and click Make Changes
- Time for phpMyAdmin
Step 8: Import your WordPress database
- Back on the cPanel dashboard under DATABASES, click phpMyAdmin (see image in Step 7-1)
- On the left, expand your MySQL instance name, and click your newly created database (i.e. prefix_blogname)
- At the top of the right pane, click Import
- Click Choose File, browse to the gzip file you downloaded from UpdraftPlus in Step 5, and click Go at the bottom (default values elsewhere)
Step 9: Upload your WordPress files
Here you have a few options. If you have good luck with the cPanel File Manager and want to try, you can upload the tarball you downloaded from your EC2 instance and then use the Extract option to unpack it into your site’s home directory. I’ve seen cPanel bomb out with large content, though, so I opted for unzipping the tarball and uploading the files via Filezilla.
cPanel actually makes that quite easy.
- On the cPanel dashboard, scroll to FILES and click FTP Accounts
- Scroll down to Special FTP Accounts and click Configure FTP Client next to the main user (not the _logs one)
- Download the configuration file for your preferred FTP client
- Import the file into Filezilla, CoreFTP or Cyberduck
- Before proceeding, note the hostname in the config
- Add this to your /etc/hosts or C:\Windows\System32\drivers\etc\hosts file or create an A record in your domain’s DNS management
- –or– Replace the hostname with your hosting’s IP address (likely found in your hosting account management console)
- Finally, connect via FTP and upload the WordPress files (wp-admin, wp-content, wp-includes, and all the root files) to your new hosting
Step 10: Edit wp-config.php
This could be done prior to uploading the files (probably more easily), but if you uploaded first, you can edit wp-config.php by opening File Manager in cPanel, navigating to the root of your site/WordPress, selecting wp-config.php, and clicking Edit. at the top.
The key pieces are DB_NAME, DB_USER, and DB_PASSWORD. The values need to match what you created in Step 7. If they don’t, WordPress won’t be able to connect to the MySQL database, and you’ll encounter an HTTP 500 error. Edit and click Save in the upper right.
Step 11: Test your site (before changing public DNS)
Referencing Step 9-5, you should add a line to your hosts file for your blog fully-qualified domain name (i.e. www.blogname.com) so you can confirm it works before pointing the world at it. Add a line similar to the following, where “18.104.22.168” is the IP address of your new shared hosting:
Then confirm you are resolving to the new IP using ping, dig, or nslookup. If all looks good, fire up an Incognito or InPrivate Browser (to avoid the chance of your browser also caching the old IP or content) and go to your site URL (i.e. www.blogname.com).
If it loads properly, looks good, and you’re ready to jump, proceed to Step 12.
Step 12: Change your public DNS record(s)
This one varies depending on who is authoritative for your DNS. I use CloudFlare, so my process was to edit the Value of the first record and change the IP address to the new hosting. Do whatever is appropriate in your situation and let the propagation begin (it may take up to a day for the far reaches of the world to update DNS caches). If your TTL is low, you should see a quick turnaround.
Step 13: Relax
Congratulations! You made the leap back to status quo! Your geek-fu dropped a belt or two because you no longer have shell access to your hosting, but you’ve hopefully gained some stability, a lower monthly rate (mine changed from $10 per month to $10 per year), and some time back for other projects.