Salesforce recently announced that it’s ending sales of new Heroku Enterprise contracts and shifting the service into more of a sustaining, maintenance‑focused posture. While it’s not an immediate wind‑down, it’s a clear signal that Heroku’s long‑term roadmap is narrowing for many enterprise customers. For teams still relying on Heroku for business‑critical workloads, that shift raises questions about how long it remains the right home for new applications. The good news is leaving Heroku doesn’t have to mean sacrificing developer experience. Done well, a migration to Kubernetes can feel like upgrading your platform, not going back to bare metal.
For more than a decade, Heroku has been a solid solution for startups and even enterprise teams that wanted to move fast without getting bogged down in infrastructure. It offered a clean abstraction: push code, scale dynos, wire up add‑ons, and let Heroku handle the messy parts of operating production systems. Over the last several years, Heroku has been less central to many modern cloud native architectures, but now Salesforce made the shift explicit.
Many teams have already decided to leave Heroku as their needs have changed, and the 2026 shift to sustaining engineering is pushing more to revisit that decision.
A few common patterns spurring migration include:
I like to think of Heroku as a very nice, very well‑run neighborhood with a strict Homeowner’s Association (HOA). At first, having that structure is helpful. Over time, though, the rules start to frustrate you because they get in the way of what you actually need to build.
In contrast, Kubernetes is the infrastructure you move to when you want to own the land. It is not a platform in the same sense as Heroku; it’s the toolkit for building your own platform. With Kubernetes, you can recreate the parts of Heroku that you love, such as simple deployment workflows, sensible defaults, and clear guardrails, while dropping the constraints that no longer fit your business.
In the process, you gain:
The tradeoff is that Kubernetes doesn’t come pre-configured with guardrails built in. It’s a complex and very customizable system, which means you can build it to meet your organization’s unique needs. That’s why you need to think of Kubernetes not just as infrastructure, but as the foundation of a platform you design. That’s where many migrations either succeed or stumble.
Treating the migration as a structured platform program, not a one‑off project, is the difference between a brittle lift and shift and a move that actually reduces risk and operational toil. Here’s how I recommend approaching it today.
Before you touch Kubernetes, you need a clear picture of what Heroku is actually doing for you.
Do a structured inventory:
For each of these, decide whether it needs to be replicated, redesigned, or retired. This is also the time to stop increasing your Heroku lock in. Avoid adding new critical services, data stores, or workflows that will be hard to unwind later.
If your developers are used to git push heroku main, dropping them straight onto raw Kubernetes objects is a guaranteed path to frustration. The goal isn’t to replace Heroku with YAML, but with a platform that feels just as streamlined while giving your organization more control.
In practice, that means:
This is where platform engineering designs the ideal platform for your organization. Kubernetes is the engine. Your platform is the car your developers actually drive.
On Heroku, a lot of operational work happens automatically. On Kubernetes, you own those capabilities and have to decide how to implement them. Before you move traffic to Kubernetes, make sure you have answers for how you’ll implement:
This is also where prior experience pays off, whether it’s from your internal platform team or an external partner.
When it comes time to move applications, think in terms of thin slices, not a single cutover weekend.
A typical pattern looks like this:
In previous migrations, we’ve seen downtime for an individual service reduced to very short windows, sometimes under a minute, when teams rehearse the cutover and build automation around it. The key is preparation; migrations are risky when you’re improvising.
Kubernetes isn’t a one‑time destination; it can become a platform that will keep evolving alongside your applications and teams.
Once you are off Heroku, the work shifts to:
The important part is that you now decide how to balance reliability, cost, and developer experience, instead of waiting on a vendor roadmap
One example involves a team that started on Heroku but ended up building a shadow stack on Amazon Web Services (AWS). They needed isolated environments for sensitive workloads, more advanced networking, and a microservices architecture that Heroku was no longer serving well. Now they were running two platforms: Heroku for some applications and AWS for others, with disconnected logging, monitoring, and deployment pipelines.
Moving their infrastructure to Kubernetes on AWS allowed them to unify that sprawl into a single, modern architecture. They rebuilt their workflows around containerized microservices, standardized deployments, and a shared observability stack. The payoff wasn’t just cost; it was speed and predictability. Deployments that previously took hours or required manual coordination dropped to minutes because the platform was built for repeatability.
That story isn’t unique. In the past, Heroku was a fantastic starting point, but now that Salesforce has effectively moved the once-prominent PaaS to maintenance-mode, planning a move to Kubernetes on a major cloud provider is a reliable way to protect your long‑term roadmap.
If Heroku is currently a core part of your platform strategy, you don’t need to panic, but you do need to plan.
Start by:
From there, you can build a phased migration plan that fits your risk tolerance and your business calendar.
If you want help thinking through that plan, the team at Fairwinds spends our days helping organizations move from platforms like Heroku to Kubernetes with guardrails, best practices, and as little drama as possible. Reach out to learn more.
