This post is mostly to document the process and the gotchas for myself, but if someone else finds it useful, yay! It is written mostly in the second person, except for an occasional opinion or a personal anecdote.
I have been able to move my blog to AWS over a few days, a couple of hours of work each day, and I am happy with the results. In this series of posts I will try to replicate this process with another site, just to make sure I did not forget anything. And it will be a bonus if others find it useful.
*** Note: if you want to set up a whole new WordPress site, that process is somewhat simpler, and there are several good step-by-step guides online for exactly this case.
I’ve had my site, mastersmusings.zone (has nothing to do with the Masters, a golf event) hosted by my registrar, namesilo.com, for a few months. While they are an excellent registrar, super cheap, quick and convenient, and their customer service is beyond belief (someone competent tends to reply in an online chat within a few minutes, minutes!!! of contacting them), their hosting business seems more like an afterthought. My site was down almost daily for short intervals, sometimes very slow, and eventually would go down for many hours at a time. Granted, for 3 dollars a month one ought not to expect too much, and, according to their customer service, they have been a target of DDOS attacks, but that doesn’t really help me. So, while I would use them again for domain registration in a heartbeat, and happily recommend it to others, it was time to move my site somewhere more reliable.
And who is more reliable than Amazon Web Services? Right? And their content rules are very reasonable:
Offensive Content. Content that is defamatory, obscene, abusive, invasive of privacy, or otherwise objectionable, including content that constitutes child pornography, relates to bestiality, or depicts non-consensual sex acts.
Basically, they don’t want to deal with legal issues arising from the content being hosted, and nothing beyond that. They also give away a full year of basic (“free tier”) services, and, unless your blog is very popular, the costs after that are likely to be very reasonable.
So, free hosting for a full year, reasonable terms of service, unparalleled speed and reliability… Sounds perfect! And, after some internal deliberation, I took a deep breath and decided to take the plunge. It went smoother than I had expected, though, of course, not without hiccups. I was able to keep everything from the old site, including posts, comments, subscriptions and stats.
So, while the process is still reasonably fresh in my mind, I will try to describe the steps, how they went and any gotchas that I ran into along the way that I still remember.
There are a few assumptions that may or may not apply to you.
- You have a hosted WordPress.org site with your own custom domain, not a free one that WordPress.com sets up for you, such as yourdomain.wordpress.com or yourdomain.home.blog. These ones can be migrated to AWS, as well, and there are guides online how to do it, but you are likely to lose your stats and your subscribers, because the WordPress Jetpack plugin that handles these things will probably get confused by the domain name change.
- You are reasonably comfortable fiddling with the WordPress dashboard, adding plugins and fiddling with the settings. If you just write the content and someone else handles the technical details, you are better off letting them do the dirty work.
- You are unfazed by the failed attempts and are willing to persevere. And there will be issues along the way. There is no way around it.
A Twelve-step Program to get hooked on AWS.
This is an overview of what needs to be done to migrate your blog. Detailed instructions for each step will follow later. This is just a big picture.
- Sign up for AWS if you don’t have an account yet. You need your own email account for that, of course, the one you use for your usual email. And you need to create a new password. This is an AWS password, not the WordPress password that you will get assigned later automatically later. Don’t reuse your password from other places, that should go without saying.
- Create a WordPress free-tier instance, a virtual computer that will actually run your blog. You will be given a WordPress password during this step. You will also get a generic blog page, something you will replace later, and a numerical address, such as 188.8.131.52, eventually to be replaced with your actual address.
*** Note: with the recommended install you will not get to use the ubiquitous CPanel, but, in truth, you don’t really need it, there are plugins for everything.
- Check that you can get an “SSH command prompt” to your instance. If you are not sure what it is, it doesn’t really matter, but it’s important to have it, just in case.
- Configure the WordPress instance for the domain you use, but do not yet switch the domain from your old blog, that’s later, since once you switch, everyone will be redirected to your new site, ready or not! And, trust me, it is not yet ready.
- Enable sending mail from your new site: this is needed to confirm WordPress admin email change if you ever need one, and for other confirmation emails.
- Enable email forwarding from a “vanity” email address, such as email@example.com, to an email account you actually use daily, such as firstname.lastname@example.org, likely the one you used to sign up for AWS. You probably already have an account like that from your current site host, and you don’t want to lose all the emails that go there after you migrate.
- Now we can actually start working on migrating your blog, right?! …Almost, not quite yet. I recommend the “All-in-One WP Migration” plugin, with some tweaks to support blogs that are larger than 40MB (most are, if you have at least a dozen pictures there). So install that plugin, tweaks and all, on both the old site, and the AWS site.
- OK, now? Are we there yet? Almost! One more thing! If you use “Login with WordPress.com” to get to the Dashboard, please make sure the option to login with user name and password also works. Or you will be locked out of your new site if the other method hiccups, like it did for me.
- Finally! It’s time to use the All-in-One WP Migration plugin on your old site to export your blog and save it some place local, like your laptop’s drive, or maybe on your Google drive or One drive, or some other storage. Odds are, you can also do it all with your phone, but I have not tried it.
*** Note: now we are on the clock! If you have new comments, likes, etc. on your old site, they will not be ported over to the new site, unless you repeat the export/import process again. Which is quite likely, there is a bit of a learning curve there.
- We are getting somewhere! Now import the freshly exported blog to the new site, with the same pligin, but on the AWS site. If you look at your new site, still with the numerical address, it should look identical to your old one. You should be able to login to the Dashboard with the same account, too. Now, temporarily deactivate the Jetpack plugin, or it might get confused between two sites, or will start warning you unnecessarily.
- Now we can finally transfer the blog name from the old one to the new one! That’s usually as straightforward as changing the name servers from your old host to your new host through your domain registrar’s site. And wait a little while until the name server changes propagate through the whole internet. This tends to take a few minutes, but can be hours. Worst of all, your own computer is likely to be the last one to get the memo, since it will remember the old site, unless you force it to forget, which might not be trivial if your router and your ISP also remember your old blog. It can be frustrating to see your new blog visible under the new name to everyone but yourself!
- Set up encrypted access to your new site (also known as https), now that it has a name. This is a bit fiddly, but tends to work. I assume that your old blog had https prefix, but if not, then you don’t need this step. This is the standard now, though, so consider doing it later, at least. Moving from http to https will screw up your stats and possibly search engine hits.
- Did I say it was a 12-step program? And you believed me that migrating a blog is as easy as getting weaned off drugs? Hah! Silly you. Next step: enable Jetpack on your new site! It’s ready to be used. Check that all your stats have been preserved. If you care about such things.
- Check that all the plugins that you had on your old site still work on your new site, and enable/configure anything that’s missing (also disable anything you don’t need that your new site may have by default).
- Now that clock from step 9 has finally stopped ticking! Your site has been migrated! Write a post on the new site! Go for it, you deserve it! That was the whole point of this process, right?
A Word of Encouragement
The above process seems complicated and wrought with peril. And, truth to be told, this is not a yellow brick road. Or, rather, it is, but we can navigate it despite the poppy fields and other obstacles in the way. Feel free to leave me a comment or a question. You can do it. I have done it mostly by putting together bits and pieces from various other guides available online. While everything online is subject to change, the basic process is likely to stay the same.
Next post in this series will deal with the first couple of steps. If you get through those successfully, you are well on your way to the finish line.
The featured image is from another site, one that can guide you through the process of setting up a whole new WordPress site on AWS.