A few weeks ago, I began my journey to migrate an existing blog from WordPress to Hugo. I waited for that moment for a long time, and finally, it got me. This post will be a first of in a series of many about moving to Hugo.

There were several points why I decided to undertake such an activity:

  • WordPress is extremely slow and pages take seconds to load
  • Even when I have cache plugins I can’t lower the load time
  • Plugins have issues and sometimes works in contrary to each other
  • A few months ago a backup plugin, when upgraded, made my whole page crash
  • Making changes to the theme was very counterintuitive and timeconsuming
  • Debugging WordPress is extremely difficult
  • WordPress offered multiple options that exceed needs for a simple personal page and constrained these which were essential for me

After these years I perceive WordPress as a gateway drug – it is easy to start but maintaining this system makes a lot of pain to you. Therefore I decided to switch into a more adjusted option to my needs.

Static site generator

My eyes turned to the more basic option to create the page – static site. Because the blog is a package of defined pages there is no need for adding a dynamicity there. Therefore, a site generator can be used to create HTML content that I will provide to the end readers. Static site generators are not a new thing (interesting article in Smashing Magazine from 2015), but only a few choose them as a default option, typically preferring WordPress.

From my perspective there are meaningful advantages to use such a generator for creating a personal page:

  • Performance – your site is delivered from a pre-rendered HTML therefore there is no need for any backend actions.
  • Improved SEO – with performance boost you get better discoverability and accessibility for your readers.
  • Reliability – you provide static files and nothing more. It means that the almost whole site can be stored on CDN. Fewer points that may fail and crash your server.
  • Security – static site lowers the attack vectors because there aren’t many options to hack.
  • Version control – your whole page can be stored in Git and tracked accordingly.
  • Testing – it is much easier to set up a testing environment and test before pushing changes into the production site.

There are obvious disadvantages of such a static site generator, but from my perspective, they are not applicable in this context.

Hugo

There are multiple static site generators over the web: Jekyll, Hugo, Gatsby, Next.JS to name a few. All of them have different options and you need to choose your pick wisely. I decided to pick Hugo because of:

  • Native support for MD files – I want my posts to be programming language independent.
  • Build time – creating a site is extremely fast, even when I change 500 files at the same time (MD files generator).
  • Different taxonomies – Hugo doesn’t constraints you in terms of categories / tags / others. You define them and use whatever you like.
  • Simple structure – from the very beginning I can be productive and adapt the page to my needs. Documentation is very helpful.
  • Support for internationalization – the multi-language site is straightforward and doesn’t require to make a significant change to your posts.
  • Written in Go – I wanted to learn Go for a long time and it is an opportunity to start that journey.
  • Continuous deployment – there are plenty of materials on how to connect Hugo to your beloved CI/CD pipeline.

It can differ from your perspective, so check different generators and find most appropriate to your situation.

A plan for a migration

It is an easy thing to start a page based on a static site generator. When you have over 100 posts, pages, used different plugins and taxonomies things start to get complicated. Therefore, I divided my migration into a multiple-step to track the progress:

  • Transform posts and pages to MD files with images and taxonomies
  • Theme improvements – menus / code highlighting / multilanguage
  • Infrastructure – Setting up test / prod environment with Terraform on Azure
  • CI/CD – pipeline in Azure DevOps which uses GitHub triggers
  • Server-side functionalities – Disqus comments and Logic Apps contact form
  • Redirection – move DNS traffic from the current provider to Azure and handle previous page url

Wish me luck and wait for the next posts in this series 😉