Migrer vers Pierrr

Ce que fait la migration

L'assistant de migration reprend une application qui tourne déjà chez un autre hébergeur et la recrée sur Pierrr : un projet, un conteneur construit depuis le même dépôt Git, les mêmes réglages de build et les mêmes variables de production. Il lance ensuite le premier déploiement.

L'assistant n'arrête jamais l'application d'origine. Tant que vous ne changez pas le DNS de vos domaines, votre hébergeur actuel continue de servir le site : vous vérifiez la version Pierrr sur son adresse Pierrr, puis vous basculez quand vous êtes prêt.

Une fonctionnalité en bêta

L'assistant de migration est en bêta : il est ouvert à toutes les organisations, et nous l'affinons au fil de vos retours.

La migration se lance depuis la page Projets : cliquez sur Créer un projet, puis choisissez Migrer depuis un autre hébergeur. L'option est ouverte aux membres qui peuvent créer des projets, tant que le quota de projets de votre plan n'est pas atteint : une migration crée un nouveau projet.

Hébergeurs pris en charge

Chaque hébergeur a son propre connecteur, et ils arrivent l'un après l'autre :

• Disponible : Vercel. Le guide pas à pas est sur la page Migrer depuis Vercel.
• Pour une application hébergée sur votre propre serveur, suivez la checklist de migration d'une application existante.
• Annoncés : Netlify, Render, Railway, Heroku, Coolify, OVHcloud et IONOS. Ils figurent avec la mention Bientôt dans la liste des hébergeurs, sans date pour l'instant.

Les étapes en bref

Une migration suit toujours le même chemin, dans un assistant dont la barre de progression compte cinq étapes :

1. Connexion : vous donnez à Pierrr un accès en lecture à votre compte chez l'hébergeur, avec un jeton que vous créez vous-même.
2. Projet : vous choisissez le compte ou l'équipe, puis le projet à migrer.
3. Analyse : Pierrr lit le projet et vous montre ce qui sera importé, comment l'application sera construite et ce qui demande votre attention.
4. Import : Pierrr crée le projet, importe les variables et démarre le premier déploiement.
5. Terminé : l'application est importée et l'étape est cochée. Il reste, depuis l'écran de résultat, à copier les données et à basculer les domaines, puis à terminer la migration, ce qui efface l'accès donné à Pierrr.

La page de l'assistant, Migrer depuis un autre hébergeur, porte un badge Bêta et liste vos migrations récentes avec leur statut (Connectée, Analysée, Import en cours, Importée, Terminée, Échouée, Annulée). Le bouton Ouvrir en rouvre une.

Après l'import

L'écran Application importée résume ce qui vient d'être créé :

• Le premier déploiement : son statut (un point animé tant qu'il tourne), sa durée, sa source (branche et commit) et son heure de démarrage. Il se met à jour tout seul jusqu'à la fin ; Suivre le déploiement ouvre son détail et Ouvrir le projet ouvre le projet.
• Les variables, dans un tableau à deux colonnes, Variable et Statut : Importée, Fournie par la base Pierrr, ou Non importée quand la valeur est absente.
• Un rappel Et ensuite : vérifiez l'application sur son adresse Pierrr avant de basculer vos domaines. Avant l'import, Annuler la migration reste disponible.

1. Import (suite) : si l'application utilise une base de données, Pierrr peut en copier le contenu dans la base du projet, depuis l'écran de résultat.
2. Import (suite) : depuis le même écran, Pierrr prépare vos adresses et vous indique les enregistrements DNS à poser, ou les pose pour vous quand l'hébergeur gère votre DNS.

Si quelque chose se passe mal

Trois situations ont leur propre écran :

• L'import a échoué : l'erreur est affichée, démarrez une nouvelle migration.
• Migration annulée : le jeton est effacé et rien n'a été créé.
• Token expiré : au bout de 24 heures, le jeton est effacé ; démarrez une nouvelle migration. Un import qui ne progresse plus depuis plus de dix minutes est signalé, avec le conseil d'annuler et de recommencer.

Ce qui est repris

L'analyse retrouve et importe :

• Le dépôt Git de l'application et son dossier racine dans le dépôt.
• La façon de la construire : un modèle Pierrr adapté à son framework, ou le Dockerfile du dépôt.
• Les variables de production, importées et rattachées à l'application.
• La base de données détectée, dont vous pouvez copier les données dans la base Pierrr du projet, ou que vous pouvez garder sur un plan payant.
• Les domaines, repris après l'import, une fois l'application en ligne sur Pierrr.

Ce qui n'est pas repris

Certaines fonctions propres à l'hébergeur d'origine n'ont pas d'équivalent direct. L'analyse les signale avant l'import :

• Les tâches planifiées.
• Pour un site construit en fichiers statiques, les fonctions serverless et le rendu côté serveur : seul le site construit est servi.
• Les déploiements de prévisualisation.
• Les variables que l'hébergeur fournit lui-même, qui n'existent pas sur Pierrr.

Sécurité et confidentialité

La migration est conçue pour ne rien laisser traîner derrière elle :

• Pierrr lit votre projet chez l'hébergeur et n'y écrit rien. Seule exception : la bascule automatique du DNS, que vous déclenchez vous-même et confirmez en tapant le nom du projet.
• Le jeton d'accès est conservé chiffré 24 heures au plus. Il est effacé à la fin de la migration, en cas d'échec, si vous annulez, ou au bout de 24 heures, et il n'est jamais affiché de nouveau.
• Nous recommandons un jeton limité à l'équipe du projet et qui expire au bout d'un jour : même oublié, il ne sert plus le lendemain.
• Une chaîne de connexion que vous collez pour copier votre base sert à cette copie seulement : elle n'est jamais enregistrée, et la copie exige une connexion chiffrée.
• Lors d'une bascule automatique du DNS, seuls les enregistrements d'adresse des noms migrés changent. Vos e-mails et vos autres enregistrements ne bougent pas, et les anciens sont gardés pour revenir en arrière.

Migrer sans coupure

L'ordre recommandé garde votre site en ligne du début à la fin :

1. Importez l'application.
2. Vérifiez-la sur son adresse Pierrr, une fois son premier déploiement réussi.
3. Copiez les données de la base, si l'application en utilise une.
4. Basculez les domaines.
5. Terminez la migration.

Jusqu'au changement de DNS, c'est votre hébergeur actuel qui sert le site : vos visiteurs ne voient rien des étapes précédentes.