The migration plan
A week ago, I had a detailed migration plan sitting in my codebase. The plan was thorough: migrate ScoreMyWordle (a Wordle scoring bot that runs on Mastodon and Bluesky) from Replit to Cloudflare. The estimated effort? 8-11 sessions across four phases.
Phase 0: Prep work. Phase 1: Build an async DB abstraction layer to make the codebase database-agnostic. Phase 2: Rebuild the bot as a Cloudflare Durable Object and port the Express/Pug web UI to Astro. Phase 3: Export/import the SQLite database to D1 with minimal downtime. Phase 4: Clean up Replit-specific code.
The migration plan was 243 lines of architecture decisions, risk assessments, and rollback procedures. I’d been thinking about this migration for months, mostly because Replit was costing me $75/year when Cloudflare could do it for $60/year. Sure, the savings weren’t dramatic, but it was the principle of the thing.
The plan sat there for a week. This felt like the kind of project you chip away at over weekends for a month or two.
What actually happened
Yesterday morning, I opened Claude Code and said “let’s start the migration.”
By yesterday evening, everything was deployed and working. Here’s what the commit history looks like:
- 3:46 PM: “Add Cloudflare migration Phase 0: Astro site + Worker scaffold”, 10,000 lines added, including the full D1 schema migration, ported templates, API endpoints, and a stub Durable Object
- I was away from the computer for most of the afternoon — playing with the kids, making dinner
- 8:17 PM: “Add Phase 2: Worker bot with Durable Object polling + Sentry”, 1,909 lines added, complete bot implementation with Mastodon and Bluesky clients
- A dozen more commits that same evening: CI/CD setup, observability config, search loading states, styling tweaks
Everything in the migration plan happened — the database abstraction layer, the Astro conversion, the Durable Object implementation, the cron triggers — but instead of 8-11 sessions over several weeks, it was one day.
The real thesis here
The cost savings are nice. Going from $75/year to $60/year isn’t life-changing, but Cloudflare’s generous free tier for D1 (25 billion reads, 50 million writes per month, my bot uses less than 0.1% of those limits) means I’m basically running for free.
What’s more interesting to me is that switching costs are becoming negligible for people with access to AI coding tools. The accumulated technical debt, the platform-specific code, the “we built it this way and now we’re stuck” inertia — those barriers are a lot lower than they used to be.
This isn’t even the first time I did this with the same bot. Two weeks ago, I migrated the entire thing from MongoDB to SQLite in a day. The bot was doing 60,000 writes and 300,000 reads per month. Simple stuff. But I was about to exceed MongoDB Atlas’s free tier, and more importantly, the complexity of writing to a separate service (MongoDB) along with Algolia for search was starting to show up with errors. The motivation was complexity and reliability, not just cost.
So on February 16, I started the SQLite migration with Claude Code. By the end of the day, I had:
- Replaced all MongoDB queries with
better-sqlite3 - Migrated the full production database
- Removed Algolia search (was using it for the web UI)
- Built a new search interface that queries SQLite directly
- Deployed it
The commit log shows the whole migration in one commit: 340+ lines of migration code and a complete schema conversion.
That MongoDB migration made this Cloudflare migration easier (the database abstraction layer was cleaner), and both times something that felt like a multi-week project compressed into a single day.
The codebase had better-sqlite3 with native C++ compilation requirements, Replit App Storage sync logic, pending-writes crash recovery, Express routes and Pug templates — all the typical platform-specific complexity that makes migrations feel daunting. I guided the overall architecture while Claude Code handled the mechanical translation: converting Express route handlers to Astro’s API endpoint format, adapting better-sqlite3 calls to D1’s async API, restructuring the long-running Node.js bot process into a Cloudflare Durable Object with alarm-triggered polling. WebSocket streams became polling loops, the 24-hour bot lifecycle became alarm-triggered wake-ups.
Recalibrating expectations
I’ve been using Claude Code for a few months now for small refactors, bug fixes, and feature additions. Those tasks are helpful but incremental — it’s hard to know from them alone whether the broader claims about AI coding tools hold up.
Completing a major architectural migration in one day, something I’d scoped at 8-11 sessions, changed my calibration on what these tools are actually good for.
What this means in practice
I think this will drive a shift in how knowledge workers approach software projects. Not because AI will replace programmers (it won’t, though the title and responsibilities might shift a bit; a post for another time), but because the relationship between “what you want to build” and “what you’re stuck maintaining” is changing.
That side project you’ve been meaning to modernize, the database migration you’ve been putting off, the framework upgrade you keep deferring — those are more tractable now than they were a year ago.
The bot is now running on Cloudflare. The Durable Object polls Mastodon and Bluesky every 30 seconds, the D1 database handles all the queries, the Astro site renders server-side, and the whole thing costs basically nothing. When switching costs get low enough, you start optimizing for different things — less “what can we tolerate” and more “what do we actually want.” You can experiment with a new platform without committing weeks of effort to find out if it works.
The constraints that shaped software decisions for decades are shifting, but we still need the lessons from those decades — the taste around human factors, the understanding of what makes software actually work for people. The tools are changing, and the judgment of when and how to use them still matters.