How to migrate from Heroku to a multicloud PaaS in 2026

On February 6, 2026, Salesforce announced that Heroku is moving into "sustaining engineering" mode. No new features or new Enterprise contracts for new customers. Existing customers are unaffected for now: pricing, billing, and day-to-day service continue as before. For teams still running on it, that raises a practical question: what does moving off Heroku involve? This piece walks through that, concretely.

What "sustaining engineering" means

Here's what changed:

• No new feature development going forward. The roadmap is defensive: security patches, stability fixes, and infrastructure maintenance only.
• No new Enterprise contracts for new customers. Existing Enterprise customers can still renew.
• Existing customers on credit card billing see no change to pricing, billing, or service.
• Heroku has not announced a shutdown date, and none of the coverage of the announcement suggests one is imminent.

What this means in practice is that a platform in this mode won't invest in new compliance certifications, new language runtime support, or new infrastructure capabilities going forward. For a team planning more than a year or two out, that's worth factoring into an infrastructure decision, even without any immediate urgency to migrate.

Why migrate to a multicloud PaaS

Most Heroku migration guides point toward Railway, Render, or Fly.io. All three are good platforms, and all three share one thing in common with Heroku: each runs on its own single infrastructure. Moving from Heroku to any one of them solves the Heroku-specific risk (a platform that's stopped evolving) but not the underlying one, which is depending on a single vendor for where your application can run at all.

A multicloud PaaS changes that calculus. Upsun Cloud, for example, deploys the same application configuration to AWS, Azure, Google Cloud, IBM Cloud, or OVHcloud. Heroku, by contrast, has always run solely on a limited set of AWS regions, which is itself one of the constraints teams are migrating away from. Moving to a platform that can run on more than one provider means the next migration, if one is ever needed, is a matter of re-provisioning the same configuration on a different provider, not another full rewrite.

The migration mapping to Upsun Cloud

The good news: Heroku's core concepts map fairly directly onto Upsun Cloud. The Procfile pattern, in particular, translates cleanly. This is worth stating plainly, since "migration" often gets treated as a synonym for "rewrite": moving your application's definition into Upsun Cloud's declarative configuration file is not the same as rewriting its logic. The application code itself typically doesn't change; what changes is how its runtime, services, and connections are described.

• Procfile process types (web, worker, release) map to application and service definitions in Upsun Cloud's .upsun/config.yaml file. A web process type becomes the application's web service; a worker becomes a background worker service defined in the same way.
• Dynos map to containers that Upsun Cloud provisions per your configuration. Where Heroku dynos are billed by a fixed tier (Eco, Basic, Standard, Performance), Upsun Cloud's provision-based pricing lets you specify the exact CPU and RAM a service needs instead of jumping to the next tier for a single resource increase.
• Add-ons largely become built-in platform capabilities rather than a marketplace of separate services. Persistent storage, cron jobs, DDoS protection, and backups are commonly bundled into the platform itself rather than requiring a separate add-on and its own line item. Third-party add-ons that connect via an API key (monitoring tools, email services) typically continue working after migration by carrying over the relevant environment variables, but this should be verified add-on by add-on, not assumed universally.
• Config vars carry over directly as environment variables in Upsun Cloud.
• Heroku Postgres migrates to Upsun Cloud's managed PostgreSQL service via the standard pg_dump/pg_restore process. This is typically the highest-risk step in the entire migration, and it warrants more care and testing time than the configuration translation.
• Review Apps map to preview environments, though the mechanics differ meaningfully: Heroku's Review Apps require manual setup to load data into each one, while Upsun Cloud clones the database, files, and services automatically per branch, byte for byte.
• DNS cutover is the final step once the Upsun Cloud environment has been validated against production traffic patterns.

What changes on Upsun Cloud

A few things worth calling out as real changes in behavior:

• Persistent storage. Heroku's dynos have no persistent storage of their own; anything that needs to survive a restart has to live in an external service like S3. Upsun Cloud provides persistent storage natively, removing that extra piece of infrastructure to wire up and maintain.
• Dyno cycling. Heroku restarts dynos at least every 24 hours, which drops in-memory state and can interrupt long-lived connections. Upsun Cloud only restarts containers on deploy, not on a fixed schedule, removing a class of intermittent issues teams build workarounds around today.
• Request timeouts. Heroku enforces a non-configurable 30-second response timeout. Upsun Cloud does not impose this limit, which matters for anything handling large file uploads or long-running requests, and is worth checking against your application's actual behavior before migrating.

Common migration risks

• Data migration is the highest-risk step, not the configuration translation. Test the Postgres dump/restore process against a copy of production data well before the actual cutover, not during it.
• Validate on a clone before touching production. Rather than testing a migration in a staging environment that only approximates production, testing the migrated configuration against a full clone of production data and services on an Upsun Cloud branch catches problems that the configuration translation alone won't surface.
• Third-party add-ons need individual verification. Add-ons that connect via API keys and environment variables generally continue working once those variables are carried over, but "generally" isn't "always," and each one is worth an explicit check.
• Don't migrate everything at once. Moving a single non-critical application first, learning Upsun Cloud's deployment workflow, and only then migrating production systems reduces the blast radius of any surprise.

Frequently asked questions (FAQs)

Does migrating off Heroku mean rewriting my application? 
Not usually. The application's logic typically stays the same; what changes is how its runtime, services, and connections are described, moving from Heroku's model to Upsun Cloud's declarative configuration file. The Procfile-to-service mapping, in particular, translates directly rather than requiring a rewrite.

Does my Heroku Procfile map directly to Upsun's configuration? 
The concept does. Process types (web, worker, release) translate into service definitions in Upsun Cloud's .upsun/config.yaml, though the exact syntax differs and needs to be rewritten, not just copied.

What happens to my Heroku Postgres data? 
It migrates via a standard database dump and restore into Upsun Cloud's managed PostgreSQL service. This is the step most likely to need extra testing time, since it involves moving actual production data, not just configuration.

Do I need to migrate everything at once? 
No, and it's generally not advisable to. Migrating a smaller, non-critical application first lets a team validate Upsun Cloud's deployment workflow before moving production traffic.

Why migrate to a multicloud PaaS instead of another single-cloud alternative like Railway or Render? 
Migrating to another single-cloud platform solves the specific problem of Heroku no longer evolving, but it doesn't address the underlying risk of depending on one vendor for where an application can run. Upsun Cloud, which deploys the same configuration to AWS, Azure, Google Cloud, IBM Cloud, or OVHcloud, means a future provider change doesn't require another full migration.

Will my third-party add-ons still work after migrating? 
Most add-ons that connect via an API key and environment variables continue working on Upsun Cloud once those variables are carried over. This should be checked add-on by add-on rather than assumed for the whole stack.