DriverSoul.com — Automotive Blog & Migration Story
My personal automotive blog. The technical highlight: a clean migration from WordPress to a Cloudflare-hosted static stack with zero downtime and zero broken pages.
- Domain
- driversoul.com
- Status
- Live, revival phase, not monetized
- Stack
- Astro, Cloudflare Pages, Tailwind CSS
- Demonstrates
- Willingness to modernize legacy stacks, low-risk technical migrations, comfort with static-site architecture
My personal automotive blog. I review tires, carbon fiber accessories, and aftermarket gadgets I install on my own cars. The site is currently in revival phase — not yet monetized, but technically modernized and ready to scale when I’m ready to put time into it.
The technical highlight isn’t the content. It’s the migration: a clean move from WordPress to a Cloudflare-hosted static stack with zero downtime and zero broken pages.
Why I Migrated
DriverSoul started life on WordPress like most blogs do. Over time, the WordPress experience deteriorated in the ways every long-running WordPress site does:
- Plugin conflicts that broke the front end after routine updates
- Database queries slowing under load
- Security patching anxiety — every CVE in the WordPress ecosystem became my problem
- Backup and recovery overhead
- Page speed degrading as plugins accumulated
The site wasn’t generating revenue, so the maintenance overhead was unjustified. I had two options: archive it and walk away, or modernize it onto a stack I’d actually maintain.
I chose to migrate.
What I Migrated To
The new stack:
- Astro as the static site generator
- Cloudflare Pages for hosting (free tier, global CDN, automatic SSL, zero-config)
- Markdown content collections for the blog posts
- GitHub for version control and continuous deployment
This is the same stack I’d recommend to anyone building a content-focused site in 2026 — fast, durable, near-zero hosting cost, and with a vastly smaller security surface than WordPress.
How the Migration Went
The migration itself was the most interesting part of the project. I planned it as a low-risk technical exercise but documented it carefully because most migration stories in the wild are horror stories.
The Plan
- Export all WordPress content to markdown using a one-time export script
- Manually clean up the markdown, fixing the inconsistencies WordPress had introduced over years of plugin churn
- Build the new Astro site with a layout that closely mirrors the old design
- Map every old WordPress URL to a new URL with explicit redirects
- Stage the new site on a subdomain and validate with crawls before swapping
- Cut over by changing DNS, with the old WordPress instance still up as a fallback for a week
What Went Well
- Zero broken internal links after migration
- Zero 404s for organic search traffic
- Page load times dropped from 4+ seconds to under 1 second
- Lighthouse scores went from low-70s to 95+ across the board
- Security surface effectively eliminated — no plugins to patch, no database to harden
What I Learned the Hard Way
- WordPress had introduced years of inconsistent content formatting that the export didn’t surface until I rendered it. Cleaning that took longer than building the new theme.
- Image handling in Astro is more deliberate than in WordPress. Worth the effort, but added a day of work I hadn’t budgeted.
- Some of the old WordPress plugins had been silently injecting tracking scripts I didn’t know about. Migration was a forced cleanup of garbage I should have removed years earlier.
The total migration timeline was about a week of evening work. Total downtime during the cutover: zero.
What This Project Demonstrates
For anyone evaluating my technical judgment:
- Comfort with risk-managed technical changes — I migrated a working (if struggling) production site to a fundamentally different architecture without breaking it
- Modern stack literacy — Astro, Cloudflare Pages, static-site CDN architecture, JAMstack patterns
- Willingness to cut my losses — I don’t romanticize legacy systems. WordPress served the site for years; when it stopped working, I replaced it instead of patching forever
- Documentation discipline — I planned the migration on paper before touching anything, validated each step, and could have rolled back at any point
These aren’t dramatic results. They’re the kind of competent, low-drama technical work that compounds over a career.
What’s Next
DriverSoul is in revival phase. The technical foundation is in place. The content needs refresh — some product reviews are years old and the products themselves have moved on. When I have time post-Security+, I’ll restart publishing on a regular cadence.