Migrer Heroku Postgres sans fenêtre de maintenance

Chaque autre partie d’une migration Heroku est mécanique : les config vars se copient-collent, le Procfile se lit de la même façon, les buildpacks construisent l’application sans changement. La base de données est la seule partie qui inquiète vraiment, parce que c’est la seule où « ça n’a pas marché » veut dire des données perdues, pas juste un redéploiement.

C’est plus ennuyeux que ça en a l’air. Voici exactement ce qui se passe.

Ce que l’importateur fait vraiment

Applications → Import lit un compte Heroku depuis un jeton API et affiche un plan par application avant que quoi que ce soit ne s’exécute — ce qui suit, ce qu’il faudra ajouter soi-même. Pour Heroku spécifiquement : les config vars, la formation complète (types de processus et leur nombre), et les add-ons Postgres, Redis, MySQL et Memcached suivent tous, avec les domaines personnalisés.

La seule chose que l’API de Heroku ne peut vraiment pas transmettre, c’est l’URL Git elle-même — Heroku n’expose pas votre dépôt, donc c’est le seul champ que vous fournissez vous-même pendant l’import.

Comment les données se déplacent vraiment

La base de données est copiée en diffusant un dump directement depuis le DATABASE_URL de Heroku vers la nouvelle base Postgres gérée sur Railyard — pas un pg_dump manuel vers un ordinateur portable puis une restauration, un flux direct entre les deux. Ça compte parce que ça veut dire qu’il n’y a pas de fichier de plusieurs heures qui traîne sur un disque comme seule copie des données de production en cours de migration.

La séquence qui évite vraiment l’indisponibilité :

1. Lancez l’import. La nouvelle application existe, configurée, avec sa propre base fraîche déjà en train de recevoir le flux depuis l’ancienne.
2. Gardez l’application Heroku en marche tout ce temps. Rien dans l’import ne l’arrête.
3. Une fois que le nouveau DATABASE_URL répond correctement et que vous l’avez vérifié contre l’ancien, basculez le DNS.
4. Suspendez les dynos Heroku seulement à ce moment-là — après le basculement, pas avant.

Il n’y a pas de fenêtre de maintenance à planifier parce qu’il n’y a aucun moment où ni l’une ni l’autre base ne sert le trafic. L’ancienne continue de répondre jusqu’à ce que la nouvelle soit prouvée, et le basculement lui-même est un changement de DNS, pas un événement d’indisponibilité.

Ce qui demande encore une intervention humaine

Les secrets stockés comme config vars Heroku suivent avec tout le reste — mais si votre application tire des identifiants de quelque part que l’API de Heroku n’expose pas (une valeur injectée par un buildpack, quelque chose défini en dehors des config vars), c’est à vous de vérifier. Et si la base de données a des extensions au-delà du Postgres standard — pgvector, PostGIS — confirmez que la cible les supporte avant de basculer, pas après.

Pour le chemin le plus rapide, la sortie de heroku config -s se colle directement dans Variables → Bulk import si vous faites une partie de ceci à la main plutôt que via l’importateur.

Correspondance complète pour chaque plateforme source : Importer depuis Heroku, Render, Fly ou Railway et le guide complet sur Migrer depuis Heroku.