Static Site vs Traditional CMS: When Should You Switch?

After moving this site from Laravel (a custom CMS with a database) to Astro (a static site), I get asked fairly often: when is it actually worth switching from a traditional CMS to a static site? Usually the person asking is someone tired of maintaining a server for a blog that only they write for anyway.

Here’s what I weighed at the time, and still weigh when a client asks something similar:

How often content changes, and who’s changing it. If content gets updated multiple times a day by many non-technical people — a marketing team publishing articles daily through a visual editor, say — a traditional CMS with an admin panel still makes far more sense. A static site fits when you, or a small team, write the content and don’t mind committing to git every time something new goes up. For this blog, I’m the only one writing, so git isn’t a barrier at all — if anything, it feels more natural than opening an admin dashboard.

How big the editorial team is. A Markdown+git-based static site is most comfortable for one or two people. Once the editorial team is bigger than that and needs an approval workflow — draft, review, publish, with different people at each stage — a CMS or headless CMS becomes more efficient, because they usually already have a UI for that approval flow without needing to teach non-technical staff git.

How much minimal maintenance actually matters. This was my main reason for switching, and the one whose impact I felt most after a few months. No server to patch, no database to back up regularly, no PHP dependency needing an update because of a new CVE. Back on Laravel, I remember one week where I had to stop client work to deal with an emergency security patch on my personal blog’s server — that’s the moment I started seriously thinking about migrating. Now, this site has essentially zero “server maintenance”; the closest thing is an occasional npm update.

What kind of dynamic features you actually need. If you need user login, real-time comments, or per-user content personalization, a pure static site isn’t enough — you’ll need additions like a serverless function or a third-party service (Disqus for comments, say). This blog has none of that, and I’ve deliberately left it out — not because it’s technically hard, but because I’m not convinced it adds real value for a personal blog this size. If I ever need comments, I’ll look for a third-party service first rather than build my own and end up needing a backend again.

One thing I didn’t anticipate before migrating: how much mental overhead went into just “worrying about the server” even when nothing was actually wrong. On Laravel, every security update notification from the hosting provider meant stopping to check whether it was urgent for my blog. Those notifications don’t exist anymore — not because I stopped caring about security, but because the surface area that needs watching is so much smaller now.

The takeaway: a static site isn’t objectively “better” than a CMS — it’s about fit with your constraints. For a personal site with limited maintenance time and content I write myself, the static site wins decisively. For a client with a bigger team that needs non-technical people publishing their own content, I still recommend a CMS or headless CMS fairly often, even though I personally now prefer static sites for my own work.