My personal website has been around for years.
Like most long-running websites, it has changed along with me. The design has changed. The content has changed. The purpose has changed. And, periodically, the technology underneath it needs to change too.
Recently, I moved ChristopherSherrod.com from Jekyll to Astro.
The old site wasn’t broken.
That’s important.
I didn’t rebuild it because Jekyll suddenly became bad software or because I wanted to chase the latest web-development trend. I rebuilt it because the technology underneath a website should continue to fit the way the website is actually being used.
Mine no longer did.
The Problem
Jekyll had served me well.
It’s simple, mature, and particularly good at turning Markdown files into a fast static website. For a writer publishing essays, that basic model still makes a lot of sense.
But over time, my website became more than a collection of Markdown files.
I wanted more control over the design. I wanted cleaner ways to create reusable components. I wanted the freedom to build more interesting pages without fighting the underlying structure of the site.
Most importantly, I wanted to simplify the next several years of maintaining it.
That changed the question from:
“Can Jekyll still run this website?”
to:
“Is Jekyll still the best foundation for where this website is going?”
Those are very different questions.
The answer to the second one was no.
Why Astro
I chose Astro because it preserves much of what I liked about a static Jekyll website while giving me a much more modern development environment.
The site could remain content-focused.
I could continue writing primarily in Markdown.
Pages could still be extremely fast.
But I gained a modern component system and much more flexibility in how the site is assembled.
That mattered because I didn’t want to turn a relatively simple personal website into a complicated application.
Quite the opposite.
I wanted better technology without creating a more complicated website.
Astro gave me that balance.
The Migration
A website migration like this is not primarily about converting templates from one syntax to another.
The real job is deciding what deserves to survive the migration.
Years of working on websites have taught me that rebuilding a site is one of the best opportunities to question everything that has accumulated around it.
What pages still matter?
What code is still necessary?
What navigation makes sense now?
What exists simply because it has always existed?
Instead of recreating the Jekyll website exactly in Astro, I treated the migration as a chance to clean up the system.
The content remained the center of the site.
Essays stayed essays.
URLs and existing structure were preserved where they still made sense.
Reusable pieces of the interface became Astro components.
Old assumptions didn’t automatically make the trip.
The goal wasn’t:
Jekyll site → Astro site
It was:
Existing website → simpler, better foundation
Astro was simply the tool that made that possible.
Moving Hosting to Cloudflare
I also moved the production site away from its previous GitHub Pages setup and onto Cloudflare Pages.
That separated two things that are often unnecessarily treated as one:
where I keep and work on the website and where the finished website is delivered to visitors.
The source remains part of my development workflow, while Cloudflare handles serving the production site.
The result is a clean static deployment with very little infrastructure for me to think about.
That’s exactly what I want.
I don’t believe a website owner should need to become a systems administrator just to publish an essay.
What Changed for Visitors?
Ideally, not much.
And that’s another important lesson from this project.
Technology migrations are often enormously important to the people maintaining a website and almost completely irrelevant to the people visiting it.
A reader doesn’t care whether ChristopherSherrod.com is generated by Jekyll, Astro, WordPress, or something else.
They care whether the page loads quickly.
They care whether they can find what they’re looking for.
They care whether the words are readable.
They care whether the website works.
The technology should disappear behind the experience.
What Changed for Me?
This is where the migration matters.
I now have a foundation that better matches the website I want to build.
I can create reusable components without making the entire site complicated. I can continue treating writing as content rather than stuffing it into a page builder. I have more freedom to evolve the design. And I have a modern development environment that can grow with the site without requiring the site itself to become heavier.
That last distinction matters.
A more capable development stack does not have to produce a more complicated website.
In fact, I think the opposite should usually happen.
Better tools should allow us to make simpler things.
The Bigger Lesson
I’ve been building websites for roughly 30 years, and one lesson keeps becoming more obvious:
Don’t choose technology because it’s impressive. Choose technology because it gets out of the way.
There will always be a newer framework.
There will always be another hosting platform.
There will always be someone telling you that your entire website needs to be rebuilt around whatever became popular six months ago.
Most businesses don’t need that.
Sometimes the right decision is to leave the website alone.
Sometimes it’s to repair what already exists.
And sometimes the underlying system really has reached the point where changing it will make the next five years easier than the last five.
That’s where I was with ChristopherSherrod.com.
Jekyll wasn’t failing.
I had simply outgrown the way I was using it.
Astro gave me a cleaner foundation without sacrificing the qualities I valued in the old site.
That principle also guided my earlier client work at Who Defines You.
The goal isn’t to sell someone a particular framework.
The goal is to understand what the website needs to accomplish, remove unnecessary complexity, and choose the simplest technology that can do the job well.
Because your customers shouldn’t have to think about your technology.
And, most of the time, neither should you.