I started my “tedious” migration of all my WordPress sites from SiteGround cloud hosting to AWS early this May.

The key intention for this project is to reduce my hosting fee, other important factors for the migration to be viable are reliability and scalability.

Starting With Shared Hosting

Like most hosting beginners, I started off my shared hosting with a local (Singapore) hosting company – Cybersite for one of my business sites. That was 2-decade ago. Since then, I have tried a couple of shared hostings including one of my favourites (at that time) – Hostgator. 

Until when I started to build LMSes (Learning Management System) – starting with open-source MOODLE and now WordPress LMSes (primarily powered by LearnDash), I’ve outgrown shared hosting and needed the more powerful cloud servers to run the LMSes.

Upgrading to VPS Cloud Hosting

For a short while, I was with Hostgator VPS (upgraded from their Shared) until I needed an even better cloud hosting – I started my SiteGround Cloud in year 2017 (2 CPUs, 4 GB RAM, 50 GB SSD) and have been with SiteGround since then … wow, that’s more than 7-year now!

Of course, my specs with SiteGround have grown/upgraded to 80 GB SSD, 4 CPUs, 8 GB RAM, increasing from initial hosting fee of USD84 monthly to USD648 half-yearly (that’s USD1296 yearly). 

AWS Instance Creation

So for the provisioning of the instance in AWS, I’ve opted for t3.large (2 vCPU, 8 GB RAM, 60 GB SSD) – the key difference is in the CPUs which is 4 on SiteGround and now 2 on AWS – the reason for this “downgrade” is after analysing the actual CPU usage in SiteGround’s control panel which average at ~25% on 4 CPUs, hence, believe that 2 vCPUs on AWS is adequate.

FlyWP Cloud Server Control Panel

One of the key elements that makes this full hosting migration possible is FlyWP – a cloud server control panel for WordPress. FlyWP allows easy connection with cloud servers like AWS, Digital Ocean, Vultr, Google Cloud, Azure etc. In my case, it’s AWS – since my primary intent is on cost reduction and it should be the lowest with AWS infrastructure. 

The thing I like about FlyWP is that it’s a Docker powered WordPress server management platform which allows the spinning off of a WordPress installation (including multisite) super fast and easy.

For sure FlyWP control panel will not be as polished and feature-rich compared to SiteGround’s own proprietary control panel – one important thing that is not in FlyWP is the creation of email aliases – though it does include email integration for each WordPress site to have its own system email via third party email service.  And FlyWP got no DNS Zone Editor – which in this case, we’d to do it inside our domain name registrar (NameCheap).

One critical factor for this hosting switch to work will be the optimisation done in the AWS console. These are configurations one has to set inside the AWS console manually – for example, getting an Elastic IP address for the server so that in the case of instance reboot, the server IP will still remain the same. Else, I couldn’t imagine the time and tediousness to update each and every A Record to a new IP. 

UpdraftPlus vs BackupBliss

Then, it took me close to a week to have dozens of WordPress sites fully migrated to my AWS instance – all these with the help of 2 excellent WordPress backup & migration plugins – UpdraftPlus and BackupBliss. My favourite backup and migration plugin now is BackupBliss – it’s fast and simple – 1 file backup and 1 file restoration, as compared to UpdraftPlus which I’d to handle a minimum of 5 files ie. db, themes, plugins, options, others. For very big sites (5GB or more), I’d strongly recommend BackupBliss. I’ve a 30G site which Updraftplus fails but BackupBliss is able to clone/restore with no issue. 

AWS Instance Unreachable

I was about to “pop the champagne” (I don’t drink though, lol) to celebrate my completion of the migration. I was also supposed to run this AWS instance in parallel while my SiteGround subscription is still valid till October to monitor its stability. But to my dismay, my AWS instances became “unreachable” 3 times causing a total downtime of more than 20-hours. I’ve put in measures to monitor this alarm and configured auto-restart of the instance when this “unreachable” alarm was triggered. But to my disappointment, the instance did not restart (possibly because it needs to be Forced-stopped first before rebooting can be done). Also included an auto scaling group to spin off another instance if anything is wrong with the “active” instance – but this “spare” instance got to be “running” in order to standby for the so-called auto-scaling meaning I’d literally be paying for 2 running instances which shoot up my monthly fee.

Exploring Alternative Hyperscalers

With my AWS hiccups and technical difficulties, I’ve decided to revert everything back to SiteGround! I also started to explore other reputable hyperscale cloud providers beyond AWS such as Google Cloud, Azure, DigitalOcean, Vultr, Linode, Cloudways etc. After an intensive 3-day research and comparison, I’ve narrowed down to Vultr (High Frequency) and DigitalOcean (Premium).

Vultr

I’ve signed up for Vultr first (cost consideration) but my instance provisioning was delayed as their billing department requirement to perform account verification – it was a frustrating onboarding experience as they repeatedly requested the picture of me (physically) with my ID which I’ve uploaded the first time but somehow they just kept wanting the picture for 3 times claiming they were unable to download/open my attached JPG and wanted JPEG format (hmmm). Anyway, my account was finally verified and authorised.

DigitalOcean

During this period, I’ve concurrently signed up for DigitalOcean and the entire process was a breeze … my instance (known as droplet in DigitalOcean) was up on the same day! While DigitalOcean is more costly as compared to Vultr, it offers better, or rather, faster ticketing support. I also like the fact that DigitalOcean offers paid support plans with guaranteed support turnaround time. 

At this point of writing, I’ve completed ~90% of my migration. And I’m very glad that I’ve finally settled down with DigitalOcean. I’ve also opted to include Plesk via DigitalOcean as the control panel – this means that I’ve now a full fledge versatile control panel which include webmail, DNS editor, app installers (including one-click WordPress install of course), SSL issuance and so much more!

Reaching KPI

Back to my set target or “KPI” for this hosting migration project. I’ve originally anticipated up to 60% subscription fee cost reduction (off SiteGround) with AWS (after instance “commitment”; committing to paying the instance for ie. 1-year in advance). But due to AWS “reliability” (and sustainability; actually AWS is quite a costly hyperscaler) and an extensive (period) of testing, I’m now with DigitalOcean with an absolute cost saving of ~30% off SiteGround. But to be fair, my current cloud server specifications with DigitalOcean are higher and if I were to upgrade SiteGround to the same specs, my actual cost savings should be ~50%. 

Conclusion

So yes, I would declare this hosting migration project a great success! Not only have I managed to have a huge saving for my hosting fee, I’m very happy with the robust cloud infrastructure, in terms of reliability and scalability, that I’m now with DigitalOcean. Most importantly, it’s the practical knowledge that I’ve acquired that is highly invaluable – especially my deep dive into AWS, other hyperscalers, instance/server management, WordPress backup & migration, Plesk control panel, domain/DNS management, integration with my other servers (Email, apps, game etc.; webfront with WordPress) etc.