Heroku Is in “Sustaining Engineering Mode.” What That Actually Means for Your App.

If you read between the lines: Heroku is done. Not today. Not necessarily next year. But done.

That’s actually the hardest part.

What “Sustaining Engineering” Actually Means

Sustaining engineering is a standard enterprise software designation. It means:

• No new features. The roadmap is frozen. Every engineering effort goes to security patches and keeping the lights on.
• No new enterprise contracts. Salesforce stopped selling new Heroku Enterprise licenses. Existing customers can renew, but under uncertain terms.
• Standard plans continue. If you’re on a standard paid plan with a credit card, nothing changes today.

In plain English: Heroku is in maintenance mode. Salesforce has decided the product doesn’t merit continued investment.

This is not a shutdown announcement. There is no end-of-life date. Heroku could run in this mode for another 2 years, or another 10.

Why “No Shutdown Date” Is the Problem

If Heroku had announced “service ends December 31, 2026,” every team would have a forcing function. Migrations would be planned, budgeted, and executed.

Instead, Heroku is dying slowly — and that creates a specific kind of organizational paralysis.

The developer says: “My app still works. I’ll deal with it when it becomes urgent.”

The CTO says: “We have bigger things to worry about. Heroku isn’t broken today.”

The finance team says: “Why spend migration budget when nothing is on fire?”

And then one day — six months from now, or eighteen months from now — something breaks. An add-on goes unmaintained. A security patch doesn’t land. A dependency gets deprecated. And now you’re doing an emergency migration instead of a planned one.

The cost of an emergency migration is 5–10x the cost of a planned migration. Every month you wait, the risk accumulates.

What to Watch For: The Trigger Events

These are the signals that should move your migration from “someday” to “this quarter”:

1. Add-on deprecation notices
Heroku’s add-on marketplace depends on third-party vendors maintaining compatibility. When a key vendor (SendGrid, Papertrail, ClearDB, Scout APM) stops investing in their Heroku add-on, you get a deprecation notice. If it’s for something critical (your database, your email), you’re doing an emergency migration.

2. Heroku Postgres going end-of-life on a Postgres version you use
Heroku Postgres is currently on older Postgres versions for many managed databases. If they stop supporting your version and you need security patches, you’ll need to migrate your database — possibly to an external provider — regardless of whether you stay on Heroku.

3. Your enterprise contract renewal conversation gets weird
If you’re on Heroku Enterprise and your renewal date comes up, you’ll be talking to a Salesforce team that isn’t actively selling this product. That conversation will clarify your timeline faster than any announcement.

4. A security incident that doesn’t get patched
In sustaining engineering mode, security patches are prioritized. But a disclosed vulnerability that sits unpatched for 30+ days is a clear signal of resource constraints.

5. A key developer at your company starts asking hard questions
Sometimes the trigger event is internal: a new DevOps hire, a security audit, a compliance review. The moment someone with fresh eyes looks at your Heroku dependency and says “we should plan an exit,” you have organizational alignment to act. Don’t waste it.

The Migration Landscape in 2026

The good news: there are more credible Heroku alternatives in 2026 than at any point in the past.

The challenging news: most of them are self-serve platforms, not managed services.

Railway, Render, Fly.io, and DigitalOcean App Platform are all viable options for teams with DevOps capability — developers who are comfortable managing their own infrastructure configuration, who can respond to their own incidents, and who can execute their own migrations.

For teams that chose Heroku specifically to avoid that work, these alternatives aren’t really alternatives. They’re different platforms that still require you to hire or develop ops capability.

If your team is small, doesn’t have a dedicated DevOps engineer, and wants to maintain the “I push code, the infrastructure handles itself” experience — you need a managed hosting provider, not another PaaS.

What a Managed Migration Looks Like

At vmfarms, we’ve been helping teams migrate off Heroku to fully managed Docker Swarm infrastructure. Here’s what the process actually looks like:

Week 1: Assessment
We review your Heroku stack — dynos, add-ons, database size, traffic patterns, any unusual dependencies. We give you a migration timeline and cost estimate.

Week 2–3: Staging migration
We deploy your app on vmfarms infrastructure in a staging environment. We validate that everything works: database connections, add-on equivalents, environment variables, build process.

Week 3–4: Database migration
This is the part everyone else glosses over. We use logical replication to keep your Heroku Postgres in continuous sync with your new managed Postgres database. When you’re ready to cut over, the databases are already in sync. The cutover window is minutes, not hours.

Cutover day
We coordinate the DNS cutover at a time you choose. We monitor both environments until you’re confident the new one is stable.

2 weeks post-launch: Hypercare
We watch your stack extra closely for the first two weeks post-migration, resolve anything that surfaces, and make sure your team is comfortable with the new environment.

Should You Migrate Now?

Here’s a framework:

Migrate in the next 90 days if:

• You’re on Heroku Enterprise and your renewal is coming up
• You have compliance or data residency requirements (PIPEDA, Quebec Law 25, healthcare)
• A key add-on you depend on is showing signs of reduced maintenance
• You’re planning significant new development and don’t want to build on a frozen platform

Migrate in the next 6–12 months if:

• You’re on standard plans, app is stable, no immediate trigger events
• Your team needs time to evaluate alternatives properly
• You want to do this as a planned project rather than a rushed migration

It’s okay to wait and watch if:

• You’re on a small, low-stakes app with minimal infrastructure dependencies
• You have the internal capability to do an emergency migration if needed
• Your team has other critical priorities right now

Whatever your timeline, the time to evaluate alternatives is now — not when you’re under pressure to move immediately.

The Bottom Line

Heroku entering sustaining engineering mode is a signal, not a siren. There’s no fire today.

But the teams that plan their migration now, while there’s no urgency, will have a dramatically better experience than the teams that wait for an incident to force their hand.