On 6 February 2026, Heroku announced a move to a sustaining engineering model focused on stability, security, reliability and support, rather than introducing new features. Enterprise Account contracts are no longer offered to new customers. Heroku is not closing: the announcement states there is no change for customers using Heroku today, that existing Enterprise subscriptions and support contracts will continue to be fully honored and may renew as usual, and that credit card customers see no changes to pricing, billing, service or day-to-day usage. No end-of-life date has been announced. What changed is the roadmap, not the lights.
What was actually said.
The panic posts and the shrug posts are both wrong. Here is the technical reading, point by point.
Your app keeps running exactly as it does today. What stops is forward motion: no new platform capability, while the languages, frameworks and libraries you build on carry on releasing. The gap opens slowly, and it opens in one direction.
This is where a frozen roadmap shows up first in practice. Newer runtime versions and stack images tend to arrive later, or eventually not at all. If your upgrade path depends on the platform shipping support for the next major version of your language, that dependency is now a risk worth naming.
Heroku states Enterprise Account contracts are no longer offered to new customers, while existing subscriptions continue to be honored and may renew as usual. Read it as a directional signal rather than an emergency: it tells you where the product sits in the portfolio.
To be clear about what is announced and what is not: Heroku says support is inside the sustaining engineering scope. What we are describing here is the general pattern of products in this phase, where organisational attention drifts toward what is being built. That is an inference from how these transitions usually go, not something Heroku has stated.
Worth saying plainly, because a lot of the current content forgets it. Heroku in September 2026 is a working platform with security and reliability attention behind it. If your app is small, stable and happy, nothing about this announcement requires you to do anything this week.
The thing you lose first is not uptime, it is choice. A platform that is not adding capability slowly narrows what you can build without leaving it. Migrating on your own schedule is cheap; migrating because something finally blocked you is not.
Source: Heroku, An Update on Heroku, published 6 February 2026. Every statement above about what was announced comes from that post. Where we are drawing an inference rather than quoting, we say so.
There is no announced end-of-life, so nothing is forcing a date on you. The risk in a sustaining engineering model is gradual rather than a cliff, which means the migration window is still yours to pick. That is the best position you will ever be in for this move, and it does not improve by waiting.
If you hold an Enterprise contract, carry compliance obligations, or are growing into real spend, start now while it is a planned project. These are the cases where a frozen roadmap turns into a blocked requirement soonest.
If your app is in production, earns money, and is not growing fast, you do not need to scramble. Put a migration window in next year's plan, decide the destination now, and stop paying the decision tax every time this comes up.
Side projects and small internal tools can sit where they are. Nothing has been announced that puts them at risk, and moving them now costs time you could spend on the thing they exist for.
Bring your Heroku setup to a free scoping call. You leave with an effort estimate and a mapped list of add-on equivalents on AWS, whether or not you engage us.
We do AWS migrations, so treat this with appropriate suspicion. Here is the version we would give you on a call anyway.
If what you want from Heroku is push-to-deploy, a managed Postgres and not thinking about infrastructure, these are reasonable homes and will feel familiar. For a side project or a small product, moving to one of them is a genuinely sensible answer and we will say so.
Containers without managing servers, which keeps much of the Heroku operational feel while giving you real scaling, cost control at volume and everything else AWS runs. This is our lane, and it is where most of the Heroku work we do lands.
Heroku to AWS ECSIf you need a compliance shelf, data residency control, or you expect to keep growing, AWS wins on the thing that matters most here: you will not be doing this again in two years. A second migration is more expensive than picking the durable destination first.
Summary level. The full method lives on the Heroku to AWS ECS page, and the wider practice on our AWS migration hub.
Your apps become container images and run as ECS services. Dyno formations map onto task definitions and service counts reasonably directly, which is why this migration is usually less dramatic than teams expect.
Heroku Postgres moves to Amazon RDS or Aurora. This is normally the part that sets the cutover plan, because the data has to move with minimal downtime and you want the rollback path decided before you start.
Every add-on needs an equivalent or a decision: Redis to ElastiCache, scheduler to EventBridge, logging and metrics to CloudWatch or your existing stack. Mapping this list early is what makes the estimate real rather than optimistic.
Pipelines get rebuilt so deploys stay as boring as they were, then the new stack runs in parallel and proves itself before DNS moves. Nothing switches until the replacement has handled real traffic.
Every answer about the announcement itself comes from Heroku's own post of 6 February 2026. Where we are speculating, we say we are speculating.
Bring what you run on Heroku: the apps, the database size, the add-on list. You leave with a realistic effort estimate and a mapped list of AWS equivalents for every add-on you depend on, yours to keep whether you engage us or not. If the honest answer is that you should stay put for now, we will tell you that too.
★ AWS Advanced Tier Services Partner · 9 apps migrated off Heroku in 6 weeks · Zero production outages
