The Forced-Migration Playbook: What Railway's Great Metal Migration Teaches About PaaS Lock-In

On June 13, 2025, Railway sent its users an email that every platform team should read twice. "This is the last call to migrate your workloads to Railway Metal," it said, "before we migrate them for you." Non-Metal regions in Southeast Asia and US East were already deprecated. US West and EU West were next. If you still had workloads on legacy GCP instances, they would shortly be moved for you — whether you had scheduled the work or not.

This is the story of the Great Metal Migration: how Railway moved more than a million users' workloads off Google Cloud and onto its own hardware, executed it about as cleanly as a forced migration can be executed, and still proved the point that every managed platform shares. Your region, your host, and your migration date are the vendor's decision. The only question is what happens to your workloads the next time the vendor — not you — decides to move them.

The email that moved a million workloads​

Railway's "last call" changelog entry is worth quoting in full, because the mechanism is the message. After six weeks of escalating reminders, the company told users plainly that the migration window was closing and that remaining workloads on legacy GCP instances would be moved by Railway itself. Users who wanted control over timing were told to move now; users who wanted help were pointed at a support ticket queue.

Note what made this email remarkable. It was not a deprecation notice with a date eighteen months out. It was a booked window with a vendor-operated default: act now, or we act for you. The deprecated surface was named region by region — Southeast Asia and US East first, US West and EU West to follow — so every team could see exactly where their workloads stood in the queue.

The timing added context. That same week, at least three major public clouds suffered significant outages, including the GCP incident that drove a surge of signups to Railway itself — enough that Railway briefly paused its lowest tiers to absorb the onrush. Railway's framing was explicit: the outages were why the company was exiting the public cloud entirely, under the banner its founder had set months earlier — you can't build a cloud on another cloud. The forced migration was, in Railway's telling, the cure for exactly the kind of upstream dependency that had just taken down half the internet.

The playbook, step by step​

The last-call email was only the final act. The full arc ran about eight months, and it is worth studying as a complete specimen of the vendor-led migration playbook:

The mechanism underneath the timeline is the part other vendors will copy. Railway assigned each host a date on which all workloads would be removed, and communicated it through a four-email sequence per host and region: an ask to move with a booking link for a handheld migration, a notice that moving would begin, a notice with the date, and a notice when migration was underway. Trial and Hobby tiers were auto-migrated first against a published timetable; Pro and Enterprise followed with assigned dates.

Credit where it is due: this was a forced migration executed well. The company dedicated its entire support and solutions team to migration assistance for the month, with full timezone coverage and off-peak and weekend windows. It shipped stateful migration tooling — volumes following their associated service to the new region — before forcing the move, rather than telling stateful customers to figure out their own data. And it named dates per host instead of flipping the whole fleet at once, so each team got a concrete window instead of a vague quarter.

That is precisely why the episode is instructive rather than scandalous. Railway did nearly everything right, and the structure underneath was still coercive: migrate on our timetable, or we migrate you. Clean execution does not change who holds the decision. It only changes how it feels.

Why the forced move was also a cheaper move​

Here is the part of the playbook that made resistance irrational: the destination was better than the origin, on price and on paper. Completing the move unlocked a pricing refresh that cut network egress by 50 percent — from $0.10 to $0.05 per GB — and volume storage by 40 percent, removed team-seat charges on the Pro plan, opened regions to users on all plans, and promised improved CPU and read/write performance on Railway-managed hardware.

Railway even tied the discount to migration progress: hit 80 percent of workloads on Metal and the reduced pricing applied automatically. The incentive design is worth admiring — the vendor's infrastructure goal and the customer's bill moved in the same direction, so the coercion arrived wrapped in a discount.

But notice the asymmetry this reveals. The same vendor that unilaterally cut your bill can unilaterally raise it, or move you again. Railway's migration happened to go from rented GCP capacity to owned hardware, which structurally lowered costs. The next forced migration — at Railway or anywhere else — might go from one rented substrate to another, with the savings going to the vendor instead of you. A forced move to a cheaper destination is still evidence that the destination is not yours to choose.

The fine print every managed PaaS shares​

Railway is not an outlier. It is just unusually transparent about a forcing function every managed platform reserves. Compare three recent specimens:

The pattern is consistent across all three. The vendor names the date. The vendor defines the acceptable destinations. The user's choices are timing and preparation — never whether, and rarely where.

Heroku's variant is arguably the strictest: after the builds deadline, an app on Heroku-20 keeps running but cannot be deployed to at all, with no extensions granted for any customer class. Render's is the gentlest, a managed-database version window with an in-place upgrade path. Railway sits in the middle: full vendor operation of the move, but to a destination the vendor also owns.

None of these are betrayals. They are the product working as designed. A managed platform sells freedom from infrastructure decisions, and the price of that freedom is that infrastructure decisions get made without you. The lock-in fine print is not a clause in the terms of service. It is the architecture: your region, your host, your runtime version, and your migration date are fields in somebody else's database.

The exit-questions checklist​

The right response is not outrage — it is diligence. Before you commit a production workload to any PaaS, managed or otherwise, get written answers to these seven questions. Railway's migration is the concrete case to test each one against:

1. Who picks the migration date? Railway assigned per-host removal dates and moved stragglers itself. Ask your vendor: when the underlying substrate changes next, do I get a vote, a window, or an email?
2. What happens if I refuse? Heroku's answer was frozen deploys; Railway's was a vendor-operated move. "Nothing, forever" is never the answer — find out what the actual default action is.
3. How do I export everything, including state? Railway shipped volume-following migration before forcing the move. Your vendor should offer a documented, tested path to extract databases and volumes — not just stateless code.
4. Are my regions guaranteed? Railway deprecated regions one by one. Ask whether your region is a contractual commitment or a current convenience, and what notice a region retirement carries.
5. What does leaving cost? Railway cut egress to $0.05/GB — still a per-GB tax on every byte that exits, including the bytes of your own departure. Model the egress bill of a full exit, not just the monthly one.
6. Is my configuration portable? Config-as-code that only one platform can execute is documentation, not portability. Prefer manifests, Dockerfiles, and Postgres you can run anywhere over console-click state.
7. Is there a self-hosted or BYOC exit? The strongest answer to every question above is the ability to run the same stack on machines you own. If the vendor offers no bring-your-own-cloud path, your exit is a rewrite, not a migration.

Keep the answers with your architecture decision record, next to the pricing page screenshot. Pricing pages get refreshed — Railway literally shipped a new one the week the migration completed. The exit answers are the part of the contract that matters when the next last-call email arrives.

Own the date, or be assigned one​

Railway's Great Metal Migration deserves its celebratory changelog. Moving a million users' workloads across substrates in eight weeks of forced window, with handheld migrations, off-peak scheduling, and a cheaper bill at the end, is genuinely good operations. The company proved that a vendor-led migration can be competent, communicative, and even generous.

It also proved that competence is not the same as control. Every workload moved because Railway decided it would move, on dates Railway assigned, to hardware Railway owns. The next migration will work the same way — at Railway, at Heroku, at Render, at every managed platform — because that is what "managed" means. The teams that sleep well through the next last-call email will be the ones that answered the seven questions above before they needed to, and the ones that kept a path to machines of their own.

Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own. Star the repo on GitHub or deploy your first app today.