Leave the PaaS. Keep the workflow.
Move off Heroku onto infrastructure you own, without the year-long project. One command from your repository, and the agent does the rest.
Heroku to the cloud you already own.
Heroku to AWS
One command. An agent reads your repository and deploys it into the AWS account you already own - after you approve the plan.
Heroku to Google Cloud
One command. An agent reads your repository and deploys it into the Google Cloud project you already own - after you approve the plan.
Heroku to Azure
One command. An agent reads your repository and deploys it into the Azure subscription you already own - after you approve the plan.
Heroku to Scaleway
One command. An agent reads your repository and deploys it into the Scaleway project you already own - in EU data centres, outside US CLOUD Act reach.
One question decides this: whose account does it run in?
Heroku moved you off your own infrastructure. Most of the alternatives move you onto somebody else’s. Only one of these three answers changes who owns the account.
Salesforce's infrastructure. You get a URL, they get the account. No VPC, no cluster, no cloud bill of your own.
Still their infrastructure. You changed vendor, not the model. Your data lives in someone else’s account and the exit is another migration.
Installs into the AWS, Google Cloud, Azure or Scaleway account you already own. You hold the cloud bill, the VPC, the cluster and the audit trail.
Qovery generates standard qovery/qovery Terraform and native Kubernetes manifests in your account. Stop paying Qovery and everything keeps running.
Nothing about this is destructive.
The new environment runs alongside Heroku for as long as you want. You move the domain when you are confident, and you can move it back.