For nearly a decade, I used InMotion Hosting as my VPS provider. They have great service and their selection of GUI-installed apps (including WordPress) goes pretty far. I hosted this blog with them, and a handful of other small sites and apps.

As time passed and my skillset expanded, I wanted more control over my VPS instance. I wanted to create sites in other programming languages. (IMH shared VPS only allowed you to use PHP.) I wanted to do Linux sysadmin stuff on my VPS instance like I’d learned to do at work. (IMH had hosting options available which would have given me such freedom, but they weren’t competitive with other providers.)

And so, I started looking at my options for moving.

What is this “jam” stack?

Though I was looking to migrate the aforementioned apps and small sites off of IMH, my primary concern was this blog. It was a WordPress blog at the time, and so my options seemed to be either move to WordPress.com or do my own setup and maintenance. Neither prospect was appealing: WordPress.com was more limiting than my IMH plan, but I also didn’t want to have to monitor the WordPress world for the latest security patches.

I investigated a handful of other blogging options and landed on Jekyll. Jekyll is a “static site generator”. You give it Markdown files and it produces a complete static website, including WordPress-like feed pages, indexes, tag clouds, etc.

Such “JAMstack” sites have some very enticing attributes: they’re fast (because no database latency), they’re secure (because no user inputs), and they’re low maintenance (because the setup can be as little as a firewall and something like NGINX).

Also, since all HTML is valid Markdown, Jekyll gives you more flexibility than the old WordPress editor and approximately the same ease of use as the new one.

The Migration

This blog is not enormous, and so after skimming the Jekyll docs, I thought the simplest route might be to just copy/paste the text of each post into a Markdown file and then add the requisite Jekyll boilerplate - but the process turned out to be much easier than that. There is a WordPress plugin that exports to Jekyll. It didn’t work perfectly, but the cleanup was pretty minimal.

Now if I ever want to change to something else, I have this blog as a handful of .md files, instead of rows in a MySQL database. I can edit or search them in Visual Studio Code with its collection of Markdown plugins, track them in Git, or do whatever other text file things I want.

Disqus

What about comments though? One of my articles has a lot of comments; losing them would have been no good. Surely, I’d need a database for comments, right?

Yes, but it didn’t need to be my database. Disqus is a service which provides comments functionality, and just as with Jekyll, there is a route to exporting your WordPress comments to it.

My one concern with Disqus was that I was transferring my users’ comments from a format that I controlled (IMH’s MySQL database) to a format that I didn’t (Disqus’s storage, whatever that is). I wanted to make sure that I could export from Disqus in the future. Fortunately, Disqus has export options.

LightSail

It was time to choose a new home for my new static blog.

Many Jekyll themes, including this one (“Beautiful Jekyll” at time of writing), are built with GitHub Pages free hosting in mind. I could have set up on GitHub Pages, and doing so would have reduced the total cost of hosting to nearly zero (rather than cutting it in half), but I would have lost some flexibility with subdomains. Instead, I went with a bare bones Amazon LightSail VPS instance.

There’s Always a Snag

The IMH/WordPress version of this blog had a “/wp” appended to the domain name before the article title in the URL. So the URL for a given article was https://explosionduck.com/wp/the-title. That structure didn’t match up well with the structure of this Jekyll theme. That was a problem because if I didn’t match the old URL structure, my humble blog would lose what little Google search ranking it’s acquired over the years.

Unfortunately, the structure didn’t mismatch in a simple enough way to make the problem a good candidate for a quick symlink or NGINX directive. So I solved it with a bash script. After my rebuild.sh runs bundle exec jekyll build, it proceeds to move a bunch of stuff around. Eh. It’s ugly, but it works.

Trap Baskets

As I mentioned above, it wasn’t just this blog that I was hosting with IMH. There were some small static sites, a bunch of private git repos, my personal Kanboard, a few private MediaWikis, a digital garden, and most importantly - my explosionduck.com email address.

IMH’s easy installs are just… so… easy. (I can have a Kanboard in one click? Yes please!) That kind of thing can become a liability. Just as you shouldn’t use Google’s services exclusively (especially not on a single account) because Google can take them away on a (probably automated and difficult to appeal) whim, so much reliance on IMH had also become problematic. Watch out for baskets that make you want to put all of your eggs in them.

Migrating My Email

After the blog, email was my next largest concern. I was afraid that I’d have to set up an SMTP server and deal with all the headaches involved with spam detection. Not so. My DNS provider, NameCheap, has a reasonably priced email service called Private Email. I went with that.

Migrating Everything Else

I followed the same strategy for everything else: I dispersed the rest among different providers, as much as made sense.

  • The other small sites got added to my NGINX config on the same LightSail VPS instance as this blog. Since they’re all static too, they add no security concerns and minimal additional upkeep.
  • [Free Tier] I moved my private git repos to GitLab.
  • [Free Tier] I converted my Kanboard to Trello. (Trello exports to json.)
  • [Free Tier] I transferred the wikis into BitBucket. (Another Atlassian service, but the wikis are small.)
  • [Free Tier] I changed the persistence settings on my digital garden to use GitHub Pages. (Like so.)

You might be thinking, “What a hassle! All those sites, all those logins to remember!” Well, if you’re not at least using a password system (but preferably a password manager) you’re doing it wrong. If you are doing password security correctly, new accounts add negligible upkeep.

Trade-Offs

Having all the now-migrated sites and apps under InMotion Hosting was very convenient, and a good way for me to get started years ago. Scattering it all across the cloud did add complexity, but with that complexity came flexibility, stability, and growth, which I think makes the trade-off well worth it.

As for the switch to JAMstack, I couldn’t be happier with the result. My blog is now prettier, more portable, and mostly tracked in Git. Would recommend.