I’m Back: Why I Went Quiet in 2025 and How I Migrated This Blog to New Hosting

If you’ve been following this blog for a while, you probably noticed something uncomfortable: I didn’t publish a single post in all of 2025. This is the first thing I’m writing in 2026, and I owe you an explanation — because the story of why I disappeared and the story of why this site suddenly got a lot faster are actually the same story.

Let me catch you up, and along the way I’ll walk through the exact hosting migration I just finished. If you’re thinking about moving your own blog to a new host, this should save you some pain.

What happened in 2025

The short version: life, then infrastructure, then a feedback loop I couldn’t escape.

I started 2025 with a full posting calendar. I had drafts, ideas, a content backlog. Then real life showed up — the usual suspects: a demanding day job, a cross-town move, and a stretch where every free hour went to sleep instead of writing. That part is boring and universal, so I’ll skip the violin solo.

The interesting part is what happened to the blog itself. My old hosting plan renewed at a price I hadn’t agreed to (an introductory rate that quietly tripled after the first term). On top of the bill, the site had gotten sluggish:

• Pages were taking 4–6 seconds to load on a cold cache.
• The dashboard timed out half the time I tried to log in.
• Uptime monitor flagged at least one outage a week.

So every time I sat down to write, I’d first spend 20 minutes fighting the CMS, watching the editor lag, or restarting a failed deploy. Writing became work before the work. The momentum died, and once you lose momentum on a personal blog, a week off becomes a month, and a month becomes a year.

I’m not proud of the gap. But I’m back now — on a host that doesn’t make me dread the editor — and that’s what matters.

Why I finally migrated hosting

By early 2026 I had two choices:

1. Keep paying more for less. Renew at the inflated rate and keep fighting the same slow stack.
2. Migrate. Move the blog somewhere faster and cheaper, eat the one-time pain of switching, and never think about it again.

Migration is scary because of the two things everyone worries about: losing content and losing SEO rankings. I’d built up years of indexed posts and backlinks, and the idea of breaking URLs made me procrastinate for months. Eventually I realized that not migrating was the bigger long-term risk — slow, flaky hosting hurts rankings and readers far more than a careful migration does.

So I did it. Here’s how.

My hosting migration, step by step

1. I chose the destination first

I moved from shared hosting to a small VPS with a managed control panel. The appeal: predictable flat pricing, dedicated resources, and SSD storage that’s roughly 5–10× faster for a write-heavy CMS than the spinning-disk shared box I was leaving.

Takeaway: pick the new host before you touch the old site. You want a warm target to migrate into, not a half-configured one.

2. Full backup — twice, in two places

Before anything else, I grabbed:

• A database dump of every post, comment, and setting.
• A file backup of

  1	wp-content

  (media, themes, plugins).
• A second copy on a different provider (cloud storage), because “I have a backup” until you’ve tested restoring it is just a feeling, not a fact.

This is the single step you cannot skip or rush. Everything else is reversible; data loss isn’t.

3. I locked URL structure to protect SEO

This is where most migrations bleed search traffic, and it’s the step I obsessed over.

• Permalinks stayed identical. Every old URL (

  1	/posts/old-slug

  ) resolves to the exact same path on the new host.
• For the handful of posts whose slugs I genuinely wanted to clean up, I set up 301 redirects (permanent) from the old path to the new one. A 301 passes roughly 90–99% of link equity — a 302 or a broken link passes none.
• I exported and re-imported all metadata: titles, meta descriptions, image alt text, and canonical tags.

Rule of thumb: if Googlebot can’t tell you moved, you did it right.

4. DNS cutover with a low TTL

The day before the switch, I lowered my DNS TTL (time-to-live) to 5 minutes. That way, when I repointed the domain to the new server, visitors and crawlers picked up the change almost immediately instead of being stuck on cached records pointing at the old host for up to 24 hours.

I kept the old site live and serving during the propagation window so nobody hit a dead page. Once traffic confirmed flowing to the new box, I shut the old one down.

5. Test, then test again

Before flipping DNS, I verified the new site end-to-end:

• Loaded 20 representative posts and checked images, internal links, and formatting.
• Ran the site through a broken-link checker.
• Confirmed the XML sitemap regenerated and robots.txt was correct.
• Checked that HTTPS/SSL was valid site-wide (no mixed-content warnings).
• Submitted the sitemap to Google Search Console so re-crawling started immediately.

What’s better now

The results, two weeks in:

• Load times dropped from ~5s to under 1s on most pages. Core Web Vitals are green across the board.
• Hosting cost is down about 40% versus the renewed old plan.
• The editor is responsive, so writing doesn’t feel like a chore before the chore.
• Uptime has been 100% since cutover.

The site feels like mine again, instead of a sluggish tenant in someone else’s overcrowded server.

What’s next for this blog

I’m not promising a rigid schedule — I’ve learned that’s how you stall. But the plan is one solid post every 2–3 weeks, focusing more on depth than frequency. Some of what’s queued:

• A deeper technical write-up of the migration itself (with the actual commands and config I used).
• Performance before/after benchmarks.
• Whatever I’m building and breaking this year.

If you’ve stuck around through the silent year, thank you. Subscribers, RSS readers, the occasional commenter — you’re the reason this was worth bringing back instead of letting the domain lapse.

What I’m exploring now: AI, vibe coding, and new languages

The honest reason the blog gap became productive: I spent a big chunk of that silent year learning instead of writing. My background is solidly .NET — C#, ASP.NET, the Microsoft stack I’ve worked in for years. But in 2025 I deliberately stepped outside that comfort zone, and it’s reshaping what this blog will be about.

Artificial Intelligence

I went from “using AI tools occasionally” to genuinely studying how they work — prompt design, context windows, RAG pipelines, and how LLMs actually fit into a real codebase rather than a demo. This isn’t hype-chasing; it’s the most consequential shift in how we build software since the cloud, and I wanted to understand it under the hood, not just consume it.

Vibe coding

If you haven’t heard the term, it’s the new workflow where you describe what you want in plain language and an AI coding agent writes, edits, and iterates the code with you in the loop. It changed how I think about programming — less typing syntax, more architecting and reviewing. It didn’t replace my .NET skills; it amplified them. I’ll be writing a lot more about this.

New programming languages

Beyond .NET, I’ve been picking up:

• Python — for AI/ML work, scripting, and data. The lingua franca of the AI ecosystem, so non-negotiable.
• Go — for its simplicity, concurrency model, and how it forces clean, readable code. A refreshing contrast to C#’s richness.
• TypeScript — because the modern web runs on it, and full-stack awareness makes me a better backend dev too.
• A little Rust on the side, mostly to rebuild my intuition around memory and systems.

The throughline: I’m not abandoning .NET. I’m adding tools to the belt and learning where each language genuinely shines. Expect more posts that blend my .NET experience with these new explorations — practical comparisons, not hot takes.

So that’s the reboot: new host, new topics, same person. Have you started exploring AI tools or a new language this year? I’d genuinely love to hear what’s on your list — drop it in the comments.

Thinking about migrating your own blog?

The short version of everything above:

1. Back up everything twice.
2. Keep your URLs identical (or use 301 redirects).
3. Lower DNS TTL before cutover.
4. Keep the old site live during propagation.
5. Test the new host thoroughly before pointing the world at it.
6. Resubmit your sitemap to search consoles after.

Do those six things and you can migrate with near-zero risk to your content and your rankings. The fear of moving is almost always bigger than the move itself.

Welcome to 2026. The blog is back, the server is fast, and there’s a lot more to come. If you found this useful — or you’re mid-migration and panicking — drop a comment below and I’ll help where I can.