What Does “Sustaining Engineering” Actually Mean?

In software organizations, sustaining engineering has a very specific meaning. A product enters a maintenance-focused phase. Engineering efforts concentrate on:

• operational stability

• security patches

• infrastructure reliability

• minimal improvements required to keep the system running

It does not mean immediate shutdown. It does mean the product is no longer evolving in a forward-looking way. The roadmap becomes defensive rather than innovative.

In the context of Heroku, this suggests we should not expect major new features, significant improvements in developer experience, or deeper infrastructure investments. The platform will continue to function, and likely remain stable, but it is no longer positioned as a growth engine.

For technical teams, this distinction matters. A Platform-as-a-Service offering thrives not only on stability, but on evolution. If we rely on it as the foundation of our product, we need clarity about whether that foundation will grow or simply be maintained.

Why This Matters from a Technical Perspective

Heroku played a major role in shaping modern PaaS. For many teams, especially Ruby on Rails teams, it became the default production environment.

No server management, automatic scaling, plug-and-play add-ons, Heroku Postgres with automated backups, all of this dramatically reduced operational complexity and accelerated product development.

However, the ecosystem has evolved. Today, AWS, GCP, and Azure offer mature managed services. Docker and Kubernetes have become standard. CI/CD tooling, observability stacks, and Infrastructure as Code are widely adopted and production-ready.

Heroku is no longer the only way to simplify deployment. And if it is no longer actively developed, it is natural to question its long-term trajectory.

Heroku Future – Stability or Gradual Sunset?

A common question in technical discussions is whether Heroku will eventually be shut down.

There is no definitive answer. Products in sustaining engineering mode can operate for years. However, history shows a pattern: as fewer new customers adopt the platform and innovation slows, long-term strategic alignment weakens.

Eventually, decisions become more business-driven than technical.

From a CTO’s perspective, the core issue is not whether Heroku will shut down next year or in five years. The issue is predictability. When a platform stops being a strategic investment area, long-term certainty decreases.

If we are building a SaaS product designed to scale, we must consider not just current operational stability, but also the platform’s long-term trajectory.

When Does a Heroku Migration Make Sense?

Not every company should migrate from Heroku today. In many cases, staying may be a rational decision. The key is understanding the technical context.

A Heroku migration becomes worth considering when:

1. Significant Scaling Is Planned

If rapid traffic growth, geographic expansion, microservices architecture, or complex asynchronous processing is on the roadmap, infrastructure control becomes increasingly important.

Heroku abstracts many layers. That abstraction is a strength early on, but can become limiting as complexity grows.

2. Advanced Networking and Security Control Is Required

Custom VPC configurations, private networking, granular IAM policies, advanced load balancing, or deep integrations with internal systems often require capabilities more naturally supported by AWS ECS, EKS, or GKE.

3. Compliance Requirements Are Increasing

While Heroku has offered enterprise solutions, the decision to stop selling new Heroku enterprise contracts signals a shift in focus. For companies requiring strict compliance, auditability, and infrastructure transparency, migrating from Heroku to a public cloud provider may simplify long-term governance.

4. Costs Become Disproportionate

Many teams explore a Heroku to AWS migration primarily for cost optimization. Heroku’s pricing model is convenient and predictable, but at scale, it can become more expensive compared to directly leveraging hyperscaler services.

When Staying on Heroku Is Reasonable

There are also valid scenarios where migration would be unnecessary.

If the application is stable, growth expectations are moderate, costs are acceptable, and no advanced infrastructure control is required, remaining on Heroku may be entirely pragmatic.

Migration is not free. It introduces technical risk and consumes engineering capacity. Reacting purely to headlines without a clear technical rationale is rarely a good decision.

What a Heroku Migration Actually Involves

One common misconception is that migrating from Heroku is simply a matter of redeploying code elsewhere. In practice, it affects multiple system layers.

The first step is evaluating add-ons. Heroku relies heavily on its ecosystem: databases, caching services, message queues, monitoring tools, and email delivery services. Each of these must be mapped to an equivalent managed service in AWS, GCP, or Azure.

The second layer is deployment architecture. Heroku uses buildpacks and dynos. Migrating to AWS ECS or Kubernetes requires containerization, CI/CD pipeline adjustments, and a rollout strategy such as blue/green or rolling deployments.

Observability is another major shift. Heroku centralizes logging and simplifies log access. In a Kubernetes-based environment, teams must design and maintain their own monitoring and logging stack, typically involving Prometheus, Grafana, ELK, or OpenTelemetry.

In other words, migrating from Heroku often means moving from a highly abstracted environment to one that offers more control and more operational responsibility.

Heroku Alternatives – Realistic Options

When evaluating Heroku alternatives, options generally fall into two categories.

The first category includes alternative PaaS providers such as Render or Fly.io. These platforms offer a similar developer experience and simplified deployment model. Migration may be faster, but vendor lock-in risk remains.

The second category is direct use of public cloud infrastructure, AWS, GCP, or Azure, combined with containers and orchestration. This approach requires deeper DevOps expertise but provides long-term flexibility, scalability, and cost control.

The right choice depends on team maturity and product vision. Teams with established DevOps capabilities often choose Kubernetes or ECS. Smaller teams prioritizing simplicity may prefer a managed PaaS alternative.

Ruby on Rails After Heroku

It is difficult to discuss Heroku without mentioning Ruby on Rails. For many Rails applications, Heroku was the default production home.

Today, Rails integrates seamlessly with Docker and cloud-native environments. A modern stack built on containers, Application Load Balancers, managed databases (such as RDS), and Redis is stable and widely adopted.

A Heroku migration does not require abandoning Rails or rewriting the application. In many cases, it is primarily an infrastructure shift rather than a fundamental application redesign.

Common Mistakes in Heroku Migration Projects

From experience, several mistakes frequently occur.

The first is underestimating the scope. Migration is often perceived as a purely infrastructure task, but it impacts CI/CD processes, staging environments, monitoring, and sometimes application configuration.

The second is insufficient long-term cost modeling. Comparing monthly bills is not enough. Teams must account for DevOps effort, cluster maintenance, upgrades, and ongoing operational overhead.

The third is lacking a rollback strategy. Every migration should include a clear fallback plan to minimize business risk.

A Technical Approach to Decision-Making

Instead of asking “Should we migrate from Heroku?”, I recommend asking:

What is our exposure to platform risk?

Practically, this means:

• reviewing the current architecture

• assessing dependency on the Heroku ecosystem

• modeling costs over a 24–36 month horizon

• evaluating internal DevOps capabilities

In many cases, this structured assessment clarifies the path forward. Some teams will conclude that staying on Heroku is acceptable. Others will initiate a phased Heroku migration plan over the next 6–12 months.

Final Thoughts

Salesforce’s decision to move Heroku into sustaining engineering mode does not mean immediate disruption. The platform remains operational and supported.

However, it does signal that Heroku is no longer a primary growth focus.

For technical teams, this is a prompt to think long-term. A Heroku migration is not mandatory. But lacking an alternative plan may become costly in the future.

The decision should be based on architecture, scalability, cost structure, compliance requirements, and internal expertise, not emotion.

Heroku played an important role in modern cloud development. The relevant question today is not “Will Heroku disappear?” but rather:

Is our architecture resilient enough if we ever need to move?