Mistakes to avoid when moving your site
There are a few reasons I wanted to move my WordPress blog off of my previous host, GoDaddy, to AWS.* For one, my BS in Cloud Computing at WGU requires me to take a course on and pass the exam for the AWS Certified SysOps Administrator certification. What better way to get acquainted with AWS than by actually using it? Additionally, I made it to a second round of interviews with AWS for a Senior Technical Trainer, so I wanted to fluff my non-existing knowledge on AWS–which I fully disclosed to them–and I figured, if I’m comfortable with Azure and O365 administration, those skills will likely translate over pretty well with a little bit of hands-on work. AWS is a ubiquitous platform and whether my job search brings me to work for Amazon or not, it’s a skill that will only help in the future.
A quick search on Google pulls up many guides on migrating a WordPress blog to AWS. I think I just skimmed the first two guides and went off my merry way. It wasn’t until I ran into my first roadblock that I went back to these guides thinking that I missed some major steps, but no–these tips just weren’t there. And I know I wasn’t the only person having these issues because many were asking the same questions in the comments section.
So before you start migrating your WordPress blog to AWS on a Bitnami AMI (Amazon Machine Image), check out these tips listed in order to help you avoid any potentially frustrating mishaps in your migration journey.
1. Export your backup before pointing your domain to the new blog
Sure, you can just pop back into your old site through cPanel, or typing in the IP, but save yourself the trouble by installing the All-in-One WP Migration plugin and backup your site in advance.
2. Increase the upload limit on your new instance if the WordPress blog you’re migrating is large
Fortunately (or unfortunately?), I faced this issue before where importing my site’s backup would fail because the upload limit was reached. With an AWS EC2 instance, you have the ability to add an .htaccess file that ups your PHP limit or edit your wp-config file to raise the upload file limit. If you’re uncomfortable with those methods, you can also add the All-in-One import extension plugin, which will quickly get your site imported without additional back-end configuration.
3. Watch for the built-in example.com SSL cert on Bitnami
If for some reason you don’t plan on installing an SSL certificate on your blog anytime soon, beware of the example.com SSL cert that already lives on the Bitnami AMI. When navigating to your page, you’ll receive a error from your browser:
Bitnami has a pretty neat tool that will walk you through generating and installing a Let’s Encrypt cert, as well as setting up a cron job for automatic renewals and enabling redirects. You can quickly run it by logging into your VM and pasting this in:
sudo /opt/bitnami/bncert-toolAnd speaking of redirects…
4. Don’t get stuck in a loop! Ensure your AWS Route 53 records don’t clash with your redirects
I somewhat mindlessly followed the guide’s instruction, thinking I can always go back and refine the settings to my needs later. Well, that is, in fact, what I had to do. I created a CNAME record that pointed www to my naked domain. However, in allowing the defaults in the Bitnami bncert tool (see above), the domain was redirecting non-www to the www URL format. Being that I worked on this project over a couple of days, I had forgotten that I created the CNAME record and didn’t realize that the bncert tool’s defaults would cause a redirect loop. Of course while testing the changes, I immediately got the error and saw the loop playing out in the network panel in Chrome’s DevTools. Easy enough to fix, but if you can avoid it, even better!
5. You might need to search and replace hardcoded assets
Depending on in which order you may have done things (in my case, I imported my backup before I set my domain in the wp-config file), your assets may have stuck to its IP address URL instead of the domain. I’m not sure why this happens, as it wasn’t consistent across all my photos and other files, but if it does, a simple search and replace will take care of this. I typically jump on to my host’s phpMyAdmin portal to do this, but a plugin can accomplish just as well, especially if you’re not into touching your database directly.
Migrating your WordPress site to AWS is an easy enough task, and if you’re able to get this done without a hitch, great! For those of you who are doing a little more planning or have stumbled upon this post because you’ve come across these problems yourselves, I hope this helps, even if just a little! Feel free to also ask any questions in the comments, and I’ll help as much as I can! 😁
*As an aside, I much prefer Flywheel hosting, but for a personal, non-revenue generating site, I usually stick to something dirt cheap without any extra bells and whistles. This also gives me experience with different hosting platforms so I’m not too out of my elements when working with clients on that specific host.
No Comments