The Migration You Keep Postponing Is Cheaper Than the Setup You Keep Tolerating

Developers stay on infrastructure they hate for years. The fear is rational, the math usually isn't. A field guide to the migration myth.

Every developer I know has one: the setup they complain about in standup, in Slack, in their sleep. The host that falls over under load. The deploy process held together with one shell script and a prayer. The server where a specific PHP version can never, ever be upgraded, for reasons lost to history.

And every one of them has a reason the migration can't happen this quarter.

I want to talk about that gap, because I've become convinced the fear of migrating is one of the most expensive emotions in software. Not because the fear is stupid. Because it's priced wrong.

The psychology, named

Three biases do most of the work of keeping teams on infrastructure they hate.

Sunk cost. You spent weeks getting the current setup to behave. Walking away feels like admitting those weeks were wasted. They weren't; they bought you the knowledge of what you actually need. But the brain files them under "investment to protect."

Risk asymmetry. The pain of the current setup arrives in small, survivable doses: a slow deploy here, a 2 a.m. restart there. Migration pain feels like it arrives all at once, in public, with your name on the incident channel. We're wired to prefer a slow leak over a possible bang, even when the leak costs more.

Known pain beats unknown pain. You've memorized the current system's failure modes. You can recite them. A new platform's failure modes are a mystery, and mystery reads as danger, even when the honest expected value says otherwise.

None of this is irrational on its face. It just quietly assumes the migration will be what migrations were in 2012: a weekend of downtime, a DNS cutover done by hand at midnight, and a rollback plan that was mostly vibes.

What actually changed

The tooling moved. The fear didn't.

Staging environments are table stakes now, so the whole move can be rehearsed before a single real user touches it. Snapshots and automated backups make "roll it all back" a button rather than a ritual. Managed platforms ship migration tooling, and many will do the move for you or sit with you while it happens. DNS cutovers stopped being cliff-edges the day we all learned to drop TTLs in advance.

# the least glamorous de-risking step in existence:
# drop your TTL to 300s a day before cutover,
# and the "scary DNS switch" becomes a five-minute window
dig +noall +answer yourdomain.com

Meanwhile the thing you're tolerating keeps charging interest. Every workaround becomes load-bearing. Every new hire inherits the folklore ("don't touch the cron box"). Every feature estimate silently includes a tax for fighting the environment. You stop noticing the tax because it's in everything, which is exactly how the setup survives another quarter.

Here's the back-of-envelope I wish more teams ran:

hours/week lost to the current setup (deploys, firefights,
workarounds, "waiting for the server")           =  H
loaded cost of an engineering hour               =  $C
weeks you've been saying "next quarter"          =  W

cost of not migrating so far  ≈  H × C × W
realistic migration effort     ≈  a few days of one person,
                                  rehearsed on staging

I've watched teams discover that the move they'd postponed for two years cost them, in tolerated drag, more than ten times what the migration itself took. The myth isn't that migrations have costs. The myth is where the bigger number sits.

A de-risking sequence that actually works

If you decide the math points at moving, the playbook is boring, and boring is the point.

1. Inventory before you touch anything. Versions, cron jobs, environment variables, the weird symlink. Half of migration fear is really "I don't fully know what's running," and the inventory dissolves it.
2. Move the least important thing first. A staging site, an internal tool, the marketing microsite nobody loves. You're not migrating it for its own sake; you're building the team's migration muscle where mistakes are free.
3. Rehearse the real one on staging, with real data shapes. The goal is to be bored during the actual cutover because you've already seen this movie.
4. Drop TTLs a day early, cut over at low traffic, keep the old environment warm. Rollback should be a decision, not a project.
5. Timebox the parallel-run. Old setup stays alive for a week as a safety net, then gets decommissioned on a date you set in advance, or it becomes the new cron box of legend.

Nothing on that list is clever. That's what makes it work.

When staying put is the right call

Fairness demands this section, so: sometimes the fear is correct.

If your setup is deeply customized and genuinely load-bearing in ways no platform accommodates, the inventory step will tell you, and you should believe it. If you're three weeks from a launch, this is the wrong month; migrate in the quiet after. If the current setup is annoying but cheap and your constraint is elsewhere (product-market fit, hiring, sleep), the honest priority call might be to tolerate it a little longer, on purpose, with a date attached.

The failure mode isn't staying. It's staying by default, year after year, without ever running the numbers, because the fear did the deciding for you.

The uncomfortable question

So here it is, the one worth bringing to your next retro: what is the setup you're tolerating actually costing per week, and when did anyone last check?

If the answer is "we haven't," you're not protecting the team from migration risk. You're protecting a shell script's feelings.

Disclosure: I work at a managed hosting company, so I watch a lot of migrations up close and I'm biased toward believing they're survivable. The checklist above works whatever you're migrating to, including your own bare metal. The math works even harder.