Heroku-20 to Heroku-22 or Heroku-24 — when and how should I migrate?
Choose the least risky stack upgrade path for apps still on heroku-20 now that the stack is end-of-life and no longer suitable for ongoing deployments.
Blockers
- runtime/heroku-20 — EOL 2025-05-01
- requires_version: runtime/heroku-22 → runtime/ubuntu-22-04
- requires_version: runtime/heroku-24 → runtime/ubuntu-24-04
- breaking_change_in: package/heroku-buildpack-static → runtime/heroku-22
- breaking_change_in: package/heroku-buildpack-google-chrome → runtime/heroku-24
- breaking_change_in: package/heroku-buildpack-redis → runtime/heroku-24
- Lock-in via runtime/heroku-24
Who this is for
- low-ops
- cost-sensitive
- small-team
Candidates
Upgrade to Heroku-22 first
As of 2026-04-01, this is the lowest-risk recovery path for apps still on heroku-20. Heroku-22 is based on Ubuntu 22.04 and is supported through April 2027, so it restores deployability without forcing the newest base-image changes immediately. Stack choice itself does not introduce a separate stack surcharge on Heroku pricing pages; dyno pricing remains plan-based, with examples including Basic at $7/month and Standard-1X at $25/month as of 2026-04-01. The main blocker-level changes versus heroku-20 are OpenSSL 3.0 with no OpenSSL 1.1 runtime library, removal of system Ruby, removal of system Python 2, and lack of support for the legacy static buildpack.
When to choose
Use this when you need the fastest path back to safe deployments and want the smallest jump from Ubuntu 20.04. It is the better choice when your app may still depend on older binaries, third-party buildpacks, or startup scripts that are likely to break on Heroku-24-specific changes.
Tradeoffs
Pros: smallest compatibility jump, restores builds now, fewer new platform deltas than Heroku-24. Cons: shorter runway because support ends in April 2027, so you are likely signing up for another stack migration sooner.
Cautions
Check for `libssl.so.1.1` dependencies, custom binaries linked against OpenSSL 1.1, buildpacks or scripts assuming system Ruby, and any use of `heroku-buildpack-static`. This is a tactical move, not a long-lived endpoint.
Jump directly to Heroku-24
As of 2026-04-01, this is the better long-run target if your app can absorb a larger compatibility test cycle now. Heroku-24 is based on Ubuntu 24.04, is supported through April 2029, is the default stack for newly created Cedar apps, and is the only base image available for Fir apps. Stack choice itself does not add a separate pricing premium; Heroku pricing remains dyno-plan based, with examples including Basic at $7/month and Standard-1X at $25/month as of 2026-04-01. The blocker-level migration caveats called out by Heroku include changed APT sources format and location, removal of legacy `US/*` time zones, the legacy Google Chrome buildpack being unsupported, the Redis Stunnel buildpack being unsupported, and system Python being build-time only rather than runtime-available.
When to choose
Use this when you want to minimize future stack churn, especially if you are already modernizing buildpacks, custom binaries, or moving toward Fir. It is the better choice when you can afford a fuller regression pass now and want the longest supported runway.
Tradeoffs
Pros: longest support window, aligns with Heroku defaults, avoids doing two migrations. Cons: higher near-term breakage risk than Heroku-22 because both the Ubuntu baseline and several operational assumptions change at once.
Cautions
Audit any use of `/etc/apt/sources.list`, any startup/runtime reliance on system Python, any `US/*` timezone names, `heroku-buildpack-google-chrome`, and `heroku-buildpack-redis`. If your app is still fragile on Heroku-20-era assumptions, direct migration can turn a stack upgrade into a broader remediation project.
Try with your AI agent
$ npm install -g pocketlantern $ pocketlantern init # Restart Claude Code, Cursor, or your MCP client, then ask: # "Heroku-20 to Heroku-22 or Heroku-24 — when and how should I migrate?"