Choose by the publishing workflow
Choose Hugo when Markdown, Git review and a static deployment fit the people maintaining the site. Choose WordPress when a browser-based editorial workflow and CMS features matter more than a file-based build.
This is a comparison, not a measured migration case study. A detailed chronology, before/after metrics and author-approved lessons from the original migration are not recorded here. The current site's /articles/ uses its own Markdown generator; these Hugo notes are not its build instructions.
What changes in practice
WordPress is a database-backed CMS with an editorial interface. Hugo produces static pages from source files and templates. Neither removes the need to maintain dependencies, accessibility, content quality or deployment credentials.
| Decision | WordPress | Hugo |
|---|---|---|
| Editors | Browser-based editing and media workflows | Markdown/files by default; a separate CMS is an additional integration |
| Dynamic features | Plugins and server-side code can supply them | Usually require an external service or custom client/server component |
| Delivery | Server/database plus caching choices | Static hosting; large assets and scripts can still make pages slow |
| Maintenance | Core, themes, plugins, backups and hosting | Build tooling, templates, third-party services and deployment pipeline |
| Review and rollback | Depends on editorial and hosting setup | Git can version source; rollback still requires a working build/deployment |
| Cost | Hosting, maintenance and optional plugin/service costs | Hosting may be inexpensive; engineering and external-service costs remain |
Benefits have conditions
- Static delivery: removes a database query from normal page delivery, but does not guarantee fast page rendering or safe third-party scripts.
- Versioned content: works well when editors are comfortable reviewing diffs; it can add friction for non-technical authors.
- Smaller runtime: reduces one class of server maintenance, but build dependencies, forms and credentials still need care.
- Template control: gives developers flexibility, while making them responsible for implementing missing CMS features.
Before considering a migration
- Inventory posts, images, URLs, redirects, feeds, comments, forms and search.
- Build a representative sample, including a long post, a code article and image-heavy content.
- Verify internal links, old URLs, accessibility and the actual editorial workflow.
- Retain a restorable WordPress backup and a rollback plan until the new site is accepted.
- Measure your own build time, publishing effort and page performance; do not substitute generic platform claims for results.
Next decision
If a static Git-based workflow fits, follow Host Hugo on GitHub Pages. If editors require a CMS workflow, first evaluate whether your current WordPress setup can meet the need with fewer changes.
References: Hugo documentation and WordPress documentation . No migration result or performance gain is claimed by this comparison.