When Platform Switching Costs Approach Zero

Posted on:

The Plan That Looked Impossible

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 carefully considered 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, it was done. All of it. Deployed. Live. Working.

The commit history tells the story better than I can:

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 happened in one day.

The Real Thesis Here

Yeah, 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.

However, the interesting part is that switching costs are becoming negligible for people with access to AI coding tools. The things that used to trap you in a platform, the accumulated technical debt, the platform-specific code, the “we built it this way and now we’re stuck” inertia, those barriers are dissolving.

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 sat down with Claude Code and said “let’s move to SQLite.” By the end of the day, I had:

The commit log shows the whole migration in one commit. 340+ lines of migration code, complete schema conversion, the works. One day.

That MongoDB migration made this Cloudflare migration easier (the database abstraction layer was cleaner), but it’s the pattern that matters. Both times, the thing that “should have taken weeks of planning” took a day.

I had better-sqlite3 with its native C++ compilation requirements, I had Replit App Storage sync logic, I had pending-writes crash recovery, I had Express routes and Pug templates. All the typical “we built this for Platform A and migrating to Platform B would take weeks of planning and implementation” stuff. Gone in a day.

With Claude Code, the conversation went like this:

“Let’s port the Express routes to Astro API endpoints.”

And then it just… did it. Read all the Express route handlers, understood the patterns, converted them to Astro’s format, handled the D1 async/await differences, kept the same validation logic.

“Now convert the bot from long-running Node.js process to Cloudflare Durable Object with polling.”

Done. WebSocket streams became polling loops, better-sqlite3 became D1 with proper async handling, the 24-hour bot lifecycle became alarm-triggered wake-ups.

Until You Do It, You Can’t Tell the Hype From Reality

I’ve been using Claude Code for a few months now. I’ve done small refactors, bug fixes, feature additions. But until you do a major architectural migration, the kind of thing that would traditionally require a wiki page full of design docs and a month of weekends, it’s genuinely hard to disambiguate the hype from reality.

People say “AI coding assistants will change how we work” and you think “yeah, they’re helpful for boilerplate” or “nice for explaining error messages.”

But then you complete in one day something you had estimated at 8-11 sessions, and you realize: oh. Oh, this is different.

The Shift That’s Coming

This feels like this year will have a huge shift in how knowledge workers work. Not because AI will replace programmers (it won’t, well, 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 fundamentally changing.

That side project you’ve been meaning to modernize? The microservice you want to pull out of the monolith? The database migration you’ve been putting off? The framework upgrade that “would take weeks”?

Those projects don’t take weeks anymore. They take a day. Maybe two if it’s complex.

When switching costs approach zero, you start optimizing for different things. Not “what can we tolerate” but “what do we actually want.” Not “we’re stuck with this architecture” but “let’s just move to the better platform.”

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. It took one day.

Here’s what becomes possible when you can rebuild your infrastructure in an afternoon: you can experiment. You can try the new platform. You can test whether that architectural idea actually works. You’re not locked in by the weeks of effort it would take to migrate. You can move toward what you want, not just live with what you have.

The constraints that shaped software decisions for decades are shifting rapidly. 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. The judgment of when and how to use them still matters.