Last updated: March 2026

On February 6, 2026, Heroku announced a transition to sustaining engineering. No new feature development. No new enterprise contracts for new customers. Maintenance mode.

The reaction in developer communities was swift and predictable: "Should we migrate?" Most teams don't have a clean answer because they've never formalized the question.

This chapter gives you the framework to answer it.

TL;DR

• Heroku is not shutting down. The platform runs, existing contracts are honored, and credit card customers are unaffected in the near term.

• Most teams can stay on Heroku without any immediate operational risk.

• The February 2026 announcement changed long-term planning assumptions, not near-term urgency.

• Whether to migrate depends on your cost trajectory, compliance pressure, growth stage, and how much your team is compensating for platform limitations.

• Staying by choice is very different from staying by default. The difference is a plan.

Why teams start looking at alternatives

Most teams don't evaluate alternatives because they decided to. They start looking because something went wrong, or because something got expensive, or because someone at a board meeting asked a question that didn't have a good answer.

The four triggers: cost, reliability, stagnation, compliance

Cost. Heroku pricing is easy to understand but compounds in ways that surprise teams at scale. Horizontal scaling multiplies dyno cost linearly. Background worker processes double compute spend. Database tiers jump in large increments as data grows. Add-ons that each seem minor produce a monthly bill that doesn't match the infrastructure value received. When finance starts asking questions and you can't confidently project next quarter's spend, the platform becomes harder to defend. For a detailed breakdown, see Heroku Pricing.

Reliability. The June 2025 outages affected a wide range of Heroku deployments and weren't resolved quickly. Apps went down. Deploys stalled. Status updates were slow. Escalation paths were unclear. For affected teams, the experience was costly in hours and in confidence. That kind of incident doesn't just create frustration. It surfaces the question that inertia had been suppressing: how long do we stay?

Platform stagnation. Long-standing feature requests remain unresolved. Workarounds that were supposed to be temporary have become permanent parts of the deploy workflow. CI/CD pipelines have been rebuilt around Heroku's constraints rather than improved by the platform. The February 2026 announcement formalized what many teams had already concluded: active feature development has ended. For teams that had been waiting on roadmap items, that confirmation matters. See What's Happening at Heroku.

Compliance and enterprise pressure. Security questionnaires get longer. Enterprise customers want evidence that didn't used to be required. Audit scope expands. For teams on Heroku Shield, the question is no longer "can we support HIPAA?" Shield provides infrastructure support for HIPAA workloads. The harder question is whether that compliance model holds up for the next two to three years as auditor expectations and enterprise procurement requirements evolve. See Heroku and HIPAA.

The inertia problem

Here's what actually happens in most cases: teams know they should evaluate alternatives. They've known for a while. The reasons to migrate have been accumulating quietly. But migration has real costs, the platform still mostly works, and there's always a higher priority this sprint.

Inertia is powerful. Most teams aren't staying on Heroku because they've made a considered decision to stay. They're staying because they haven't made any decision at all.

That's the gap this chapter is designed to close.

Three migration profiles

Not every team considering a Heroku migration is in the same position. The decision looks different depending on where you are.

Small team optimizing for cost and simplicity

One to three engineers. A CRUD app or a handful of services. No compliance pressure, no enterprise sales cycle, no platform engineer on staff. The platform mostly works, but the bill is growing and the developer experience feels dated relative to what's now available elsewhere.

For this team, the migration calculus is simple. Modern Heroku alternatives like Render and Railway offer a comparable developer experience at meaningfully lower cost. The migration surface area is small. The work is typically measured in days, not sprints. The honest answer for most teams in this profile: Render solves everything and the migration is worth scheduling for the next slow quarter. The sustaining engineering announcement hasn't changed the urgency, but it has eliminated the reason to wait.

Scaling team that tried DIY cloud and regretted it

They migrated to AWS two years ago. The initial pitch was cost savings and control. The reality was IAM policies, Terraform sprawl, a six-month Kubernetes detour that nobody wanted to explain to new hires, and an on-call rotation that now includes infrastructure failures that wouldn't have been possible on Heroku. They're looking for something between Heroku's simplicity and AWS's raw capability.

This team isn't looking for another Heroku. They want a platform that handles undifferentiated infrastructure without requiring them to hire a dedicated platform engineer to maintain it. Modern PaaS platforms and managed container platforms are the right answer here. The migration from AWS back to a managed platform is often simpler than expected because this team has already been through one migration cycle and understands what they're mapping.

Security-focused organization with growing compliance requirements

They're on Heroku Shield. PHI is in scope. The first enterprise deal is coming, or already closed, and the security review was painful. Auditors asked questions about isolation that Shield technically answers but doesn't answer cleanly. Generating deployment audit history required manual work. The compliance story is defensible but effortful, and everyone knows it gets harder as the company scales.

For this team, the question isn't "Heroku versus Render." Render and Railway don't solve their problem. The question is whether to invest in building compliance infrastructure on top of AWS, or to move to a platform where compliance is the design assumption rather than an add-on tier. For a detailed comparison, see Heroku vs. Aptible. For the specific technical considerations of migrating regulated workloads off Shield, see Migrating from Heroku Shield.

What changed in February 2026

On February 6, 2026, Heroku's SVP and General Manager published "An Update on Heroku" announcing the transition to a sustaining engineering model. The announcement used careful corporate language. The practical translation: Heroku will maintain the platform but won't build new features. No new enterprise contracts for new customers. No net-new product development.

This doesn't change today's operational picture for most teams. The platform runs. Credit card customers continue without interruption. Existing enterprise contracts renew.

What it changes is long-term planning confidence. Teams that were waiting for roadmap items won't see them. Compliance gaps that exist today are unlikely to close. Enterprise contract paths for new customers are off the table. The innovation gap between Heroku and its actively developing alternatives will only widen.

One clarification that came up repeatedly in community discussions: EOS (end of sale) is not EOL (end of life). Heroku is not shutting down. But the trajectory has changed in a way that matters for teams making 12 to 36 month infrastructure decisions. That shift shouldn't be translated into manufactured urgency. Heroku is not closing next month. A rushed migration carries its own costs and risks. The February announcement does change the inputs to a deliberate planning process.

When staying is rational

Being honest about this matters. Staying on Heroku is a valid choice for a lot of teams, and any analysis that pretends otherwise isn't worth trusting.

If your workload is stable and not growing fast, the operational disruption of a migration may not be worth the benefit. If your team is small and has limited engineering bandwidth, a migration is an expensive distraction. If you have no compliance pressure and no enterprise deals in the pipeline, the sustaining engineering announcement changes very little about your immediate situation. If your costs are predictable and within budget, the financial case for migrating isn't compelling.

The teams where staying is rational:

• Small teams (one to five engineers) with stable, low-complexity workloads

• Early-stage products where developer velocity matters more than infrastructure optimization

• Teams with low or no compliance burden

• Organizations where existing Heroku costs are predictable and within budget

• Situations where no major architecture shifts are planned in the next 12 months

• Companies with no enterprise sales cycle that would trigger security reviews

If you stay, do this

Staying intentionally requires an actual decision. That decision should be documented and revisited.

Write a one-page internal memo: what you're running on Heroku, what you're paying, what your compliance exposure is, and what would trigger a migration evaluation. Inventory your add-ons and databases. Define a 12 to 24 month roadmap assumption for the platform. Identify the specific conditions that would cause you to revisit that assumption. Schedule a quarterly review.

This takes a few hours. The output is a platform decision instead of a deferred one. That distinction becomes important when a forcing event happens and you need to move faster than you'd like.

When to plan but not rush

Some teams are in the gray zone. The situation isn't urgent, but the trajectory is clear enough that planning now is smarter than planning later.

Cost is trending upward but hasn't become a crisis. Platform stagnation is creating friction but not blocking anything critical. Enterprise deals are expanding and security reviews are getting more detailed. Compliance requirements are rising but haven't hit a hard deadline. The sustaining engineering announcement has added weight to questions that were already being asked.

For these teams, the right move is to start shortlisting alternatives and modeling migration cost over a six to eighteen month horizon. That's not a migration commitment. It's getting the information needed to make a deliberate decision before you're forced into a reactive one.

Planning looks like this in practice: identify two to three realistic alternatives. Define the target architecture at a high level. Model migration cost including engineering time, database migration complexity, and rollback risk. Identify the database migration path specifically, because that's typically the hardest part. Set a planning horizon and revisit it when any of the trigger conditions below appear.

This is the right moment to read Migration Guide and Overview to understand what a migration actually involves before you're under pressure to execute one.

When delaying increases risk

There are situations where staying in "we'll plan to plan eventually" mode is genuinely risky.

A compliance trigger is the most common forcing event. If an enterprise customer requires a security review and your Heroku Shield compliance posture can't cleanly answer the questions being asked, you're now running an emergency migration instead of a planned one. That is a materially worse position.

A major contract renewal creates leverage questions. If you're approaching renewal on Heroku's enterprise tier, that's the moment to have already evaluated alternatives. Leverage requires runway. Starting the evaluation at the renewal conversation means starting with none.

A major architecture refactor underway is a natural migration window. If you're already redesigning the system, the marginal cost of changing the platform decreases. Platforms get stickier as the architecture becomes more complex, not less.

An organizational trigger, like a new CTO mandate, a hiring plan that includes platform engineers, or board-level scrutiny on infrastructure strategy, can compress the decision timeline in ways that aren't predictable.

Even when migration is clearly the right call, it should still mean a controlled, phased migration. A rushed migration introduces exactly the kind of risk that makes staying feel safe in the first place.

Migration trigger self-assessment checklist

Cost triggers

• Monthly infrastructure spend is growing faster than revenue

• Database costs have doubled year over year

• Add-on sprawl has made spend difficult to forecast

• Finance is actively scrutinizing the infrastructure budget

Reliability and support triggers

• Multiple incidents in the past 12 months

• Slow or unclear escalation paths during outages

• On-call stress is tied to platform-level failures, not application-level ones

• Downtime that couldn't be explained to customers

Compliance triggers

• First enterprise deal requiring a formal security review

• SOC 2 certification in progress

• HIPAA scope is expanding

• Customer security questionnaires are getting longer and harder to answer

• Generating audit evidence for deployments or access controls requires manual work

Organizational triggers

• New CTO or infrastructure leadership with different platform assumptions

• Hiring plan includes platform engineers

• Board-level questions about infrastructure strategy

• Infrastructure consolidation as part of a broader company roadmap

If you're checking boxes in multiple categories, you're in the "plan but don't rush" zone at minimum. Compliance and organizational triggers alongside cost mean you're likely in the "delaying increases risk" zone.

What migration actually requires (high level)

Most migrations are not rewrites. They're platform abstraction replacements. Application code doesn't change. Database schemas don't change. What changes is the build system, the deployment workflow, how secrets are managed, how add-ons map to equivalent managed services, and how networking is configured.

The high-level phases: Dockerfile (if your target platform requires one, and most do), database migration, environment variable and secrets configuration, CI/CD changes, cutover planning, and rollback design.

The most important tactical point: separate migration from modernization. These are two different projects. You can migrate to a new platform while keeping your existing CI/CD workflow intact and modernize it afterward. Trying to simultaneously move platforms and redesign your deployment pipeline is the most common way to turn a week into a month.

For the full technical breakdown: Migration Guide.

Choosing your path

Once you've decided to migrate, the decision forks into three directions.

Heroku-like PaaS. Render, Railway, Fly.io. Similar developer experience to Heroku with lower cost and actively evolving platforms. The right choice for teams that want to preserve the Heroku mental model without Heroku's cost trajectory and frozen roadmap. See PaaS Alternatives.

DIY cloud. AWS, GCP, Azure. Maximum control, maximum operational responsibility. The right choice for teams with platform engineering capacity that need deep infrastructure control or specific networking requirements. See DIY Cloud.

Compliance-first platform. Built for regulated production workloads with compliance enforced at the platform level. The right choice for teams where HIPAA, SOC 2, or enterprise procurement requirements are first-class constraints rather than afterthoughts. See Heroku vs. Aptible.

The decision factors are operational maturity, risk tolerance, compliance pressure, and how much confidence you need in the platform's long-term roadmap.

The safest strategy

Staying on Heroku is not inherently risky. Staying on Heroku without a plan is.

The difference between the two teams is not infrastructure. It's documentation. One team has a written assessment of what they're running, what they're paying, what their compliance exposure is, and what conditions would trigger a migration evaluation. The other team has inertia and the assumption that they'll figure it out when they need to.

The teams that get into trouble are the ones who let a forcing event, an outage, an audit, an enterprise deal, an unexpected invoice, make the decision for them. Those migrations happen under pressure. They involve shortcuts. They take longer than planned and cost more than expected.

A controlled migration is cheaper than an emergency one. The planning investment is small. The option value is high.

Next steps

If you're staying for now: Write the one-page risk memo described above. Inventory your add-ons, databases, and current spend. Define the conditions that would trigger a re-evaluation and put a quarterly review on the calendar. That's it. You've turned inertia into a decision.

If you're planning but not rushing: Shortlist two to three platforms that fit your team profile. Start with PaaS Alternatives if you want to stay in the managed lane, DIY Cloud if you're considering AWS, or Heroku vs. Aptible if compliance is the primary driver. Run a small proof of concept on your top candidate before the timeline becomes urgent. Read Heroku Pricing to audit whether your current spend is defensible.

If you're ready to migrate: Start with the Migration Guide for a full inventory and phased approach. If you're on Heroku Shield, the planning requirements are different: see Migrating from Heroku Shield. Use Compare Platforms to narrow your shortlist before committing to a proof of concept.