Salesforce Killed Functions, Then Froze Heroku: The Complete Exit Map for Every Workload They Left Behind

Salesforce spent fifteen years selling you places to run code next to your CRM. In eighteen months, it closed all of them. Salesforce Functions was retired on January 31, 2025. Then, on February 6, 2026, Heroku's chief product officer announced the platform was moving to a "sustaining engineering model" — no new features, no new Enterprise contracts — while Salesforce redirects investment toward AI. Every deploy target Salesforce ever offered you is now exit-only at the same time.

So here is the whole exit surface on one map — every workload type, where it actually goes, and the order to move in so you only migrate once:

That table is the whole article in miniature. The rest of this post substantiates every row — what exactly died, what "sustaining" actually means for the apps you still have running, what each move costs, and the sequencing that avoids migrating twice.

What actually died, and what "sustaining engineering" actually means​

Be precise about the two obituaries, because they demand different urgencies.

Salesforce Functions is dead, not frozen. Salesforce's own release notes state the retirement plainly: Functions retired on January 31, 2025, with subscriptions usable only through the existing Order Term, and customers told to "deploy an alternative solution" before the term ends. The Heroku Dev Center carries the end-of-life timeline and migration guidance. Note the irony in Salesforce's contemporary advice: customers were pointed toward Heroku-based services or external serverless platforms as the replacement — and one of those two lifeboats was then itself beached a year later. If you followed the official guidance in 2025 and landed on Heroku, you now need a second plan through no fault of your own.

Heroku is frozen, not dead — and frozen has a specific meaning. The February 2026 announcement, signed by Heroku CPO Nitin T Bhat, commits to "stability, security, reliability, and support" with "an emphasis on maintaining quality and operational excellence rather than introducing new features." Enterprise Account contracts will no longer be offered to new customers, though existing enterprise subscriptions are honored and renewable, and new pay-as-you-go signups still work. One exception proves the freeze is real but not a shutdown: Salesforce still intends to ship a previously announced revamp of Heroku's managed PostgreSQL service — a commitment made before the freeze, being completed after it.

Analysts read the signal the way operators should. InfoWorld's coverage attributes the shift to "declining innovation, rising relative cost, and growing opportunity cost of engineering resources," with investment moving to AI-centric services. As one analyst told The Register, developers loved Heroku — and advised teams to treat Salesforce's transition window as exactly that: a window to act, not a reason to relax. Maintenance mode is not an outage. It is the slow version of one: the platform keeps running while the ecosystem — buildpacks, add-ons, answers on Stack Overflow — quietly stops renewing itself.

The practical consequence: nothing forces you to move this weekend, but everything you build on Heroku from today on accrues migration debt at full face value. New features go nowhere. New Enterprise contracts go nowhere. Plan the exit on your calendar, not Salesforce's.

Row by row: where each workload actually goes​

Salesforce Functions code → queues plus workers, or external serverless. Functions were event-driven compute attached to your org: record-triggered flows, platform-event consumers, elastic scale-out without a server to feed. There is no Salesforce-native successor, so the honest replacement depends on the shape of each function. Short, stateless handlers map cleanly onto AWS Lambda or Google Cloud Run invoked from Salesforce via Named Credentials — the pattern Salesforce's own architect guidance now blesses. Anything long-running, stateful, or ML-adjacent was always a worker in a function's clothing: it belongs on a queue-plus-worker topology (a message queue with a pool of consumers on infrastructure you control), where retries, dead-letter queues, and backpressure are first-class instead of timeouts you negotiate with.

The inventory step matters more than the destination step: teams consistently discover "three Functions" are actually eleven once scheduled jobs and platform-event subscribers are counted.

Heroku web and worker dynos → a git-push platform, managed or owned. This is the most commoditized row on the map, which is good news. Heroku's concepts — dynos, Procfiles, config vars, pipelines, review apps — map almost one-to-one onto Render (whose Blueprints are the closest thing to a Heroku-native migration path), Railway, and Fly.io, and equally onto a self-hosted git-push PaaS (Coolify, Dokku, or a Cluster-API-based platform) running on machines you own. The decision is economic, not architectural, so price it with a representative workload rather than a hello-world. A typical small production Heroku app — two Standard-1X dynos at $25 each, Postgres Standard-0 at $50, Redis Mini around $15, plus monitoring and logging add-ons — lands around $130–160 per month; a larger setup with Performance-tier dynos climbs into the thousands. Against that anchor: Render and Railway reproduce the Heroku shape at roughly the same order of magnitude (about $7 per small service plus $5–7 for entry Postgres), Fly.io trades operational simplicity for global placement, and a self-hosted panel collapses the compute bill to a flat VPS — roughly $5–20 per month per machine — in exchange for you owning upgrades, disks, and TLS renewal.

None of these is categorically cheaper; the managed platforms charge per service while the owned machine charges per box, so the crossover point is simply the number of services you run. Count yours before choosing.

Heroku Postgres and Redis → data you choose directly. This row deserves its independence from the dyno row, because data outlives compute and constrains it: every app points at DATABASE_URL, so the data home is the decision everything else inherits. The market Salesforce's freeze leaves behind is richer than the one Heroku dominated — Neon and Supabase for serverless Postgres, Crunchy Bridge for managed Postgres with an operator's sensibility, Upstash for Redis — each selectable on its own merits rather than bundled with your compute vendor. The self-hosted end is equally viable (Postgres and Redis are among the most operator-friendly stateful workloads in existence) with the standard caveat: off-box backups, tested restores, and a second person who can run them.

And note the deliberate boundary some platforms draw here: an application platform can deploy your code from git without ever holding your data — if your shortlist includes one, confirm it treats BYO-database as a first-class posture, not a grudgingly tolerated connection string.

Heroku add-ons → standalone SaaS, and audit them first. Scheduler becomes any cron trigger. Log drains become any log pipeline. Email, monitoring, error tracking, and feature flags mostly already exist as standalone services — many Heroku add-ons were resold versions of exactly those. The risk in this row is not destination but discovery: add-on sprawl is the dark matter of Heroku estates, and the team that migrates "three apps" without listing add-ons per app discovers the fourth, fifth, and sixth bills mid-migration. heroku addons --all (or its dashboard equivalent) run today is the cheapest hour in the whole project.

The sequencing that avoids migrating twice​

Order of operations is the difference between one migration and two. The rule: move in dependency order, and commit to the data home first.

First, land the data. Provision the new Postgres and Redis, set up replication or a tested dump-and-restore path, and cut over reads before anything else moves. Data is the only workload with gravity — compute can be repointed with an env var, but a database re-migration mid-project means every app you already moved moves again.

Second, move workers before web. Background workers (Heroku worker dynos, scheduled jobs, Functions-derived queue consumers) have no user-facing traffic and tolerate cutover messiness; they also validate the new platform's env-var, secret, and logging story before customers depend on it.

Third, move web behind a traffic split. DNS cutover is the last step, not the first, with the old app scaled down — not deleted — until the new deployment has survived at least one full business cycle including a deploy of its own. (A migration that has never shipped code on the new platform is a demo, not a cutover.)

Fourth, decommission in reverse: delete preview apps and pipelines first, production last, add-ons only after the bills stop. The most common double-migration story is not technical at all — it is a team that moved apps to a managed platform, then moved them again to owned infrastructure a year later when the bill arrived, because they priced the hello-world instead of the representative workload from the previous section. Price honestly once, move once.

The honest footnote, then the way out​

One boundary deserves to be stated plainly because it shapes every recommendation above: no application platform should be your database vendor unless you explicitly want one. The entire Salesforce arc — Functions retired, Heroku frozen — is a lesson in bundled-platform risk: when compute and data come from the same vendor's roadmap, one roadmap decision migrates both. Choosing your data home independently, on open wire protocols (postgres://, RESP), is what makes every future compute migration a repointing instead of a re-architecture. Prefer platforms that respect that boundary over ones that blur it.

If the destination you priced above is "a machine, not a bill" — git-push deploys, preview URLs, and TLS on infrastructure you own, with your database staying wherever you put it — that is exactly what Bex.co is building: the open-source, AI-native Render alternative. Star the repo on GitHub or deploy your first app today.