Comment migrer de Heroku vers une plateforme PaaS multicloud en 2026

Le 6 février 2026, Salesforce a annoncé que Heroku passait en mode « ingénierie de maintenance ». Plus de nouvelles fonctionnalités ni de nouveaux contrats Enterprise pour les nouveaux clients. Les clients existants ne sont pas concernés pour l’instant : les tarifs, la facturation et le service au quotidien continuent comme avant. Pour les équipes qui l’utilisent encore, ça soulève une question pratique : qu’est-ce que ça implique de quitter Heroku ? Cet article t’explique tout ça, concrètement.

Que signifie « maintenance technique » ?

Voici ce qui a changé :

• Plus aucun développement de nouvelles fonctionnalités à l’avenir. La feuille de route est défensive : uniquement des correctifs de sécurité, des corrections de stabilité et la maintenance de l’infrastructure.
• Plus de nouveaux contrats « Enterprise » pour les nouveaux clients. Les clients « Enterprise » existants peuvent toujours renouveler leur contrat.
• Pour les clients existants payant par carte bancaire, rien ne change au niveau des tarifs, de la facturation ou du service.
• Heroku n’a pas annoncé de date de fermeture, et aucun des articles consacrés à cette annonce ne laisse entendre qu’une fermeture soit imminente.

Concrètement, ça veut dire qu’une plateforme dans ce mode n’investira plus dans de nouvelles certifications de conformité, la prise en charge de nouveaux langages d’exécution ou de nouvelles capacités d’infrastructure. Pour une équipe qui planifie à plus d’un ou deux ans, ça vaut le coup d’en tenir compte dans ses choix d’infrastructure, même s’il n’y a pas d’urgence immédiate à migrer.

Pourquoi migrer vers une plateforme PaaS multicloud ?

La plupart des guides de migration depuis Heroku orientent vers Railway, Render ou Fly.io. Ces trois plateformes sont de bonne qualité et ont toutes un point commun avec Heroku : chacune fonctionne sur sa propre infrastructure unique. Passer de Heroku à l’une d’entre elles résout le risque spécifique à Heroku (une plateforme qui a cessé d’évoluer), mais pas le risque sous-jacent, qui est de dépendre d’un seul fournisseur pour que ton application puisse fonctionner.

Une PaaS multicloud change la donne. Upsun Cloud, par exemple, déploie la même configuration d’application sur AWS, Azure, Google Cloud, IBM Cloud ou OVHcloud. Heroku, en revanche, a toujours fonctionné uniquement sur un ensemble limité de régions AWS, ce qui constitue en soi l’une des contraintes que les équipes cherchent à éviter en migrant. Passer à une plateforme capable de fonctionner chez plusieurs fournisseurs signifie que la prochaine migration, si jamais elle s’avère nécessaire, consistera simplement à redéployer la même configuration chez un autre fournisseur, et non à réécrire entièrement l’application.

La migration vers Upsun Cloud

La bonne nouvelle : les concepts fondamentaux de Heroku s’adaptent assez directement à Upsun Cloud. Le modèle Procfile, en particulier, se transpose sans problème. Ça vaut le coup de le préciser clairement, car on confond souvent « migration » et « réécriture » : transposer la définition de ton application dans le fichier de configuration déclaratif d’Upsun Cloud, ce n’est pas la même chose que de réécrire sa logique. Le code de l’application lui-même ne change généralement pas ; ce qui change, c’est la façon dont son exécution, ses services et ses connexions sont décrits.

• Les types de processus du Procfile (web, worker, release) correspondent aux définitions d’application et de service dans le fichier .upsun/config.yaml d’Upsun Cloud. Un type de processus « web » devient le service web de l’application ; un « worker » devient un service de tâche en arrière-plan défini de la même manière.
• Les dynos correspondent aux conteneurs qu’Upsun Cloud provisionne selon ta configuration. Alors que les dynos Heroku sont facturés selon des niveaux fixes (Eco, Basic, Standard, Performance), la tarification basée sur le provisionnement d’Upsun Cloud te permet de préciser exactement la quantité de CPU et de RAM dont un service a besoin, au lieu de passer au niveau supérieur pour une simple augmentation des ressources.
• Les modules complémentaires deviennent pour la plupart des fonctionnalités intégrées à la plateforme, plutôt qu’un marché de services distincts. Le stockage persistant, les tâches cron, la protection DDoS et les sauvegardes sont généralement intégrés à la plateforme elle-même, sans nécessiter de module complémentaire séparé ni de ligne de facturation distincte. Les modules complémentaires tiers qui se connectent via une clé API (outils de surveillance, services de messagerie) continuent généralement de fonctionner après la migration grâce au transfert des variables d’environnement pertinentes, mais cela doit être vérifié module par module, et ne doit pas être considéré comme une règle générale.
• Les variables de configuration sont directement transférées en tant que variables d'environnement dans Upsun Cloud.
• Heroku Postgres est migré vers le service PostgreSQL géré d’Upsun Cloud via le processus standard pg_dump/pg_restore. C’est généralement l’étape la plus risquée de toute la migration, et elle nécessite plus d’attention et de temps de test que la conversion de la configuration.
• Les Review Apps correspondent aux environnements de test, même si le fonctionnement diffère considérablement : les Review Apps de Heroku nécessitent une configuration manuelle pour charger les données dans chacune d’elles, tandis qu’Upsun Cloud clone automatiquement la base de données, les fichiers et les services par branche, octet par octet.
• La bascule DNS est la dernière étape une fois que l’environnement Upsun Cloud a été validé par rapport aux modèles de trafic de production.

Ce qui change sur Upsun Cloud

Quelques points méritent d’être soulignés comme de véritables changements de comportement :

• Le stockage persistant. Les dynos de Heroku ne disposent pas de stockage persistant propre ; tout ce qui doit survivre à un redémarrage doit être hébergé dans un service externe comme S3. Upsun Cloud fournit un stockage persistant en natif, ce qui élimine cette infrastructure supplémentaire à mettre en place et à maintenir.
• Cycle des dynos. Heroku redémarre les dynos au moins toutes les 24 heures, ce qui efface l’état en mémoire et peut interrompre les connexions de longue durée. Upsun Cloud ne redémarre les conteneurs qu’au moment du déploiement, et non selon un calendrier fixe, ce qui élimine une catégorie de problèmes intermittents pour lesquels les équipes doivent aujourd’hui trouver des solutions de contournement.
• Délais d’attente des requêtes. Heroku impose un délai de réponse de 30 secondes non configurable. Upsun Cloud n’impose pas cette limite, ce qui est important pour tout ce qui concerne le téléchargement de fichiers volumineux ou les requêtes de longue durée ; ça vaut le coup de vérifier le comportement réel de ton application avant de migrer.

Risques courants liés à la migration

• La migration des données est l’étape la plus risquée, pas la conversion de la configuration. Teste le processus de sauvegarde/restauration Postgres sur une copie des données de production bien avant la bascule effective, pas pendant celle-ci.
• Vérifie le tout sur un clone avant de toucher à l’environnement de production. Plutôt que de tester une migration dans un environnement de préproduction qui ne fait qu’approcher l’environnement de production, tester la configuration migrée sur un clone complet des données et des services de production dans une branche de la plateforme cloud d’Upsun permet de détecter des problèmes que la conversion de configuration seule ne ferait pas ressortir.
• Les extensions tierces nécessitent une vérification au cas par cas. Les extensions qui se connectent via des clés API et des variables d'environnement continuent généralement de fonctionner une fois ces variables transférées, mais « généralement » ne veut pas dire « toujours », et chacune mérite une vérification explicite.
• Ne tout migrer d’un seul coup. Commencer par déplacer une seule application non critique, se familiariser avec le processus de déploiement d’Upsun Cloud, puis seulement ensuite migrer les systèmes de production permet de limiter l’impact de toute mauvaise surprise.

Foire aux questions (FAQ)

Est-ce que quitter Heroku implique de réécrire mon application ?
Pas en général. La logique de l’application reste généralement la même ; ce qui change, c’est la façon dont son exécution, ses services et ses connexions sont décrits, en passant du modèle Heroku au fichier de configuration déclaratif d’Upsun Cloud. Le mappage Procfile-service, en particulier, se traduit directement sans nécessiter de réécriture.

Mon Procfile Heroku correspond-il directement à la configuration d’Upsun ?
Le concept, oui. Les types de processus (web, worker, release) se traduisent par des définitions de services dans le fichier .upsun/config.yaml d’Upsun Cloud, même si la syntaxe exacte diffère et doit être réécrite, pas simplement copiée.

Qu’advient-il de mes données Postgres Heroku ?
Elles sont migrées via un dump et une restauration standard de la base de données vers le service PostgreSQL géré par Upsun Cloud. C’est l’étape qui risque le plus de nécessiter du temps de test supplémentaire, car elle implique le transfert de données de production réelles, et pas seulement de la configuration.

Dois-je tout migrer d’un seul coup ?
Non, et ce n’est généralement pas conseillé. Commencer par migrer une petite application non critique permet à l’équipe de valider le processus de déploiement de Upsun Cloud avant de transférer le trafic de production.

Pourquoi migrer vers une plateforme PaaS multicloud plutôt que vers une autre alternative monocloud comme Railway ou Render ?
Migrer vers une autre plateforme monocloud résout le problème spécifique lié au fait que Heroku n’évolue plus, mais ça ne résout pas le risque sous-jacent de dépendre d’un seul fournisseur pour l’exécution d’une application. Upsun Cloud, qui déploie la même configuration sur AWS, Azure, Google Cloud, IBM Cloud ou OVHcloud, permet d’éviter une nouvelle migration complète en cas de changement de fournisseur.

Est-ce que mes extensions tierces fonctionneront toujours après la migration ? La
plupart des extensions qui se connectent via une clé API et des variables d’environnement continuent de fonctionner sur Upsun Cloud une fois ces variables transférées. Il vaut mieux vérifier cela extension par extension plutôt que de partir du principe que c’est le cas pour toute la stack.