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.

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

  1. Export all WordPress content to markdown using a one-time export script
  2. Manually clean up the markdown, fixing the inconsistencies WordPress had introduced over years of plugin churn
  3. Build the new Astro site with a layout that closely mirrors the old design
  4. Map every old WordPress URL to a new URL with explicit redirects
  5. Stage the new site on a subdomain and validate with crawls before swapping
  6. 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.