The migration was faster than the old excuses
This website started as a lightweight setup: mostly vanilla JavaScript, a little Preact where interactivity helped, and a lot of custom glue. That stack made sense at the time. It was direct, understandable, and easy to bend.
But once the site started needing real pages, direct-linkable articles, prerendering, and stronger SEO, the old shape became friction. Not impossible friction. Just the kind that keeps whispering: keep patching what you already have.
So I did the migration anyway.
And the interesting part is not that it worked. It is how fast it worked.
From custom glue to route-native pages
The old site relied on hash navigation and SPA-like overlays for parts of the experience. That is fine until you want pages that behave like actual pages.
The blog was the clearest case. Articles existed as content, but they were not first-class documents on the web. Search engines want paths. Links want paths. Sharing wants paths. A route like /blog/my-article is simply a better unit than #/blog/article/my-article.
With Astro, that became straightforward. The content already existed. The migration mostly meant giving the content a route structure, a shared layout, proper metadata, and static output.
That is what stood out to me: the work was less about fighting integration and more about making clearer architectural choices.
Why this matters now
For a long time, teams treated stack changes as inherently expensive. The cost was not just rewriting code. It was setup, adapters, build tooling, deployment friction, and all the little incompatibilities that made "best tool for the job" sound good in theory but expensive in practice.
That excuse is getting weaker very fast.
In this migration, integration cost was close to zero compared to what it would have been a few years ago. Content stayed in JSON. Preact still worked where I needed islands. Static generation, routing, sitemap generation, and page metadata came almost for free once the structure was moved into Astro's model.
The hard part was not integration. The hard part was deciding to stop defending the old choice.
The old mindset was optimization for switching cost
A lot of projects still carry an outdated instinct: once a tool is in the repo, everything should be forced through it.
That made sense when every new tool meant days of friction and a serious risk of breaking the whole system. But that is no longer the environment we are working in.
Today, the cost of combining the right tools has collapsed. Not to literal zero, but close enough that it changes how decisions should be made.
That means a simpler rule starts to win: use the tool that fits the job best.
Not the tool you already happen to have.
Not the tool you know best.
Not the tool that avoids a migration conversation.
The one that fits the job.
What the migration actually proved
Moving from vanilla JavaScript with a little Preact to Astro did not require a dramatic rewrite of everything.
It required:
- identifying the parts that should become real pages
- preserving the parts that were already useful
- isolating interactivity into small islands instead of dragging the whole site into client-side complexity
- letting the build tool do what modern build tools are now very good at doing
That is the important shift.
The web stack is no longer a place where one wrong early choice traps you for years. If the architecture is reasonably clean and the boundaries are understandable, changing direction is far cheaper than many teams still assume.
This changes how I think about architecture
I do not find it very convincing anymore when people argue for a weaker fit just because it avoids mixing technologies.
Uniformity still has value. Simplicity still matters. But there is a difference between coherence and inertia.
If one tool is better for static pages, another is better for client-side interaction, and another is better for automation or content workflows, the default should be to compose them well, not to flatten everything into one compromised system.
That is especially true now that integration layers are so much better than they used to be.
Final view
This migration reinforced something I keep seeing across modern development: integration cost has dropped so much that tool choice can be driven far more by fitness than by fear.
That does not mean chasing novelty. It means being honest about purpose.
Vanilla JavaScript was useful.
A little Preact was useful.
Astro was the better tool for where the site needed to go next.
In this day and age, that is increasingly the real standard: choose the best tool for each purpose, and stop pretending the cost of doing so is still what it used to be.