Quand faut-il migrer une application créée par vibe coding ?

Déplacer une application générée avant son lancement coûte moins cher et laisse moins de traces. La déplacer après qu'elle a trouvé son public s'appuie sur davantage d'informations, mais pardonne beaucoup moins les erreurs. Le bon moment dépend moins du fait que le projet a commencé dans Lovable, Bolt, v0 ou Replit que de votre capacité à nommer et à répéter chaque frontière avec état contrôlée par la plateforme actuelle.

Je considère le lancement comme le moment où l'identité, les données et un domaine public deviennent des promesses faites aux utilisateurs. Avant ce moment, une migration ratée coûte du temps de développement. Après, la même erreur peut empêcher des clients d'accéder au service, perdre des écritures, invalider des sessions ou diriger le trafic vers deux versions différentes du produit. Les premiers usages vous montrent ce qui mérite d'être conservé, mais ils transforment aussi un simple déplacement de code en changement opérationnel.

Ne décidez pas en fonction de la taille de l'arborescence du code source. Une petite application avec une authentification gérée et une base de données active peut être plus difficile à déplacer qu'un grand site statique. Décidez en fonction de la propriété : qui contrôle le dépôt, les identités utilisateur, la base de données, les secrets, les fichiers, les tâches planifiées, le domaine, le déploiement et le chemin de retour arrière ?

Avant le lancement, migrer apporte de la liberté

Migrer avant le lancement est généralement préférable lorsque la plateforme actuelle ne peut pas satisfaire une exigence connue de propriété, de déploiement, de localisation des données ou de maintenabilité. Vous pouvez encore modifier les schémas, remplacer l'authentification, renommer les variables d'environnement et réinitialiser les données de test sans devoir négocier avec les utilisateurs.

Cette étape est particulièrement intéressante lorsque l'application ne compte que des comptes créés pour les tests et des données jetables. Vous pouvez exporter le code, le compiler dans un environnement propre, recréer la base de données à partir des migrations et découvrir quels éléments étaient implicites dans l'espace de travail d'origine. Chaque échec est utile, car il révèle une dépendance avant qu'elle ne transporte les données de clients.

Ce bon timing ne rend pas le travail facultatif. Les projets générés fonctionnent souvent parce que leur plateforme d'origine injecte une configuration, fournit une URL de base de données, héberge des fonctions ou connaît une convention de compilation. Un export du code source prouve que vous possédez des fichiers. Il ne prouve pas qu'un autre hébergeur peut compiler et exécuter le même système.

Avant le lancement, j'exige un test en environnement vierge. Un collègue qui n'a pas créé le projet ne reçoit que le dépôt, une liste écrite des secrets avec des valeurs de développement sûres et les instructions d'installation. Si cette personne ne peut pas accéder à une connexion fonctionnelle, créer un enregistrement et parcourir le principal chemin utilisateur, le projet n'est pas encore portable.

Il existe aussi de bonnes raisons d'attendre. Un prototype précoce peut modifier son modèle de données chaque jour, et le travail de migration peut être annulé par la prochaine décision produit. Si la plateforme actuelle prend en charge le lancement prévu, l'export du code source, le déploiement, les domaines personnalisés et un chemin de retour arrière crédible, apprendre d'une petite mise en production peut valoir davantage que de perfectionner l'infrastructure d'un produit dont personne ne veut.

La décision avant le lancement n'est donc pas « Pouvons-nous migrer ? » Elle est « La migration élimine-t-elle un risque connu pour le lancement, ou payons-nous pour préserver des suppositions ? » Migrez face à une contrainte concrète. Ne migrez pas seulement parce qu'une infrastructure conventionnelle semble plus respectable.

Après les premiers succès, les informations apportent des obligations

Migrer après les premiers succès a du sens lorsque l'usage réel révèle des besoins que la configuration d'origine ne peut pas satisfaire, mais le plan doit préserver chaque promesse publique déjà utilisée. Vous connaissez désormais les parcours les plus sollicités, le volume réel de données, les tâches d'arrière-plan déclenchées par les utilisateurs et les intégrations qui comptent. Ces informations peuvent éviter une coûteuse migration vers une architecture imaginaire.

Les obligations sont tout aussi concrètes. Les mots de passe existants doivent continuer à fonctionner, ou les utilisateurs doivent disposer d'un chemin de réinitialisation maîtrisé. Les identifiants de base de données doivent rester stables si des URL, factures, webhooks ou clés étrangères les exposent. Les fichiers envoyés ont besoin d'un plan de transfert. Les liens d'e-mail et les rappels OAuth doivent viser le bon domaine. Les écritures effectuées pendant la copie doivent atteindre la nouvelle base de données ou être volontairement interrompues.

Les premiers succès ne correspondent pas à un seuil unique. Dix clients actifs qui utilisent l'application pour la paie créent plus de risque de migration que dix mille lecteurs d'un catalogue statique. Comptez les états et les conséquences, pas les comptes. Demandez-vous combien de données changent par minute, quel est le coût d'une action en double, à quelle vitesse le support peut joindre chaque utilisateur touché et si l'activité peut tolérer une fenêtre de maintenance.

C'est aussi l'étape où les équipes confondent demande observée et permission architecturale. Davantage d'utilisateurs ne justifient pas automatiquement une réécriture. Si l'application exportée reste compréhensible et que les services actuels peuvent être séparés une frontière après l'autre, une migration progressive est plus sûre que le remplacement de toute la pile.

Je souhaite une carte écrite des responsabilités avant d'approuver une migration après les premiers succès :

• Dépôt source et processus de compilation
• Répertoire des utilisateurs et sessions actives
• Base de données principale, fichiers et sauvegardes
• Secrets, tâches planifiées et webhooks sortants
• Domaine, enregistrements d'expéditeur d'e-mails, surveillance et autorité de retour arrière

Toute ligne vide bloque la migration, ce n'est pas un détail à régler le soir de la bascule. Le nom de la plateforme ne compte que s'il change la manière d'exporter ou de reconfigurer l'une de ces ressources.

L'authentification est une migration d'identités

L'authentification doit être traitée comme un transfert d'identités et de règles de confiance, pas comme un écran de connexion qu'on peut reconstruire plus tard. Le formulaire visible est la partie facile. Les hachages de mots de passe, les identifiants de sujet des fournisseurs, l'état des e-mails vérifiés, l'inscription à l'authentification multifacteur, les méthodes de récupération, les sessions et les rôles d'autorisation assurent la véritable continuité.

Commencez par déterminer si l'application possède une table d'utilisateurs ou délègue l'identité à un service géré. Si vous pouvez exporter les utilisateurs, examinez les champs disponibles et vérifiez si les hachages de mots de passe peuvent être importés dans la destination. Les hachages ne sont pas interchangeables simplement parce que les deux systèmes les appellent ainsi. La destination doit prendre en charge l'algorithme et les paramètres exacts, sinon chaque mot de passe devra être réinitialisé.

La connexion sociale crée une autre rupture d'identité. Les fournisseurs OAuth renvoient généralement un identifiant de sujet stable propre au fournisseur. Si la nouvelle implémentation associe les comptes uniquement par e-mail, elle peut fusionner des personnes à tort lorsque les adresses changent ou que les fournisseurs renvoient des alias différents. Conservez le triplet émetteur, sujet du fournisseur et identifiant local de l'utilisateur. Enregistrez de nouveau les URL de rappel avant la bascule, puis testez à la fois une nouvelle connexion et un compte existant.

La fiche pratique de gestion des sessions d'OWASP recommande de renouveler l'identifiant de session après un changement de privilège. Une migration n'est pas en soi un changement de privilège, mais ce conseil révèle une frontière importante : l'état de session est un état de sécurité. Essayer de sérialiser des cookies opaques d'une pile d'authentification vers une autre est généralement un mauvais calcul. Conservez temporairement l'ancien vérificateur si vous le comprenez entièrement, ou expirez les sessions et indiquez aux utilisateurs qu'ils doivent se reconnecter. N'acceptez jamais silencieusement un cookie que le nouveau service ne peut pas valider.

La portée des cookies peut faire échouer une migration pourtant correcte. Vérifiez le nom, le domaine, le chemin et les attributs Secure, HttpOnly et SameSite produits par le nouvel hébergeur. La référence Set-Cookie de MDN explique qu'un cookie avec un attribut Domain est accessible sur ce domaine et ses sous-domaines, tandis que l'absence de domaine le limite à l'hôte qui l'a créé. Cette distinction compte lorsque l'ancienne application utilisait un hôte pour l'interface web et un autre pour son API. Testez dans un nouveau profil de navigateur afin qu'un ancien cookie ne fasse pas paraître sain le nouveau parcours.

L'autorisation mérite une comparaison distincte. Un utilisateur peut s'authentifier avec succès tout en perdant une appartenance à une organisation, un rôle d'administrateur, un droit d'abonnement ou une règle au niveau des lignes. Exportez un échantillon de comptes avec des rôles différents et écrivez des tests d'accès attendu avant de déplacer les données. Une page confirmant la connexion ne prouve presque rien.

Pour une migration avant le lancement, je préfère remplacer maintenant le système d'identité et supprimer les utilisateurs de test. Pour une migration après les premiers succès, choisissez une stratégie de continuité explicite :

• Importer des hachages de mots de passe compatibles et préserver les identifiants des fournisseurs.
• Conserver l'ancien service d'identité pendant le déplacement de l'application.
• Exiger une réinitialisation avec des jetons à usage unique qui expirent.
• Mettre en place un court pont de double lecture avec une seule autorité pour les écritures.

N'exécutez pas deux répertoires d'utilisateurs accessibles en écriture. Les changements d'e-mail contradictoires et les demandes de suppression de comptes transformeront cette commodité en incident.

Le transfert de la base de données doit préserver le sens

Une migration de base de données réussit seulement si la destination préserve les contraintes, les identifiants, les horodatages, les relations et chaque écriture acceptée pendant le déplacement. Le nombre de lignes est une vérification faible. Deux bases peuvent contenir le même nombre de lignes tout en différant sur la précision monétaire, les fuseaux horaires, l'unicité, le traitement des valeurs nulles ou les clés étrangères.

Avant le lancement, reconstruisez la base de données à partir de migrations versionnées au lieu de copier une base de développement. N'ajoutez en données initiales que les enregistrements dont l'application a besoin. Ce test prouve que l'historique du schéma est complet et que l'application ne dépend pas de tables créées manuellement dans une console hébergée.

Après les premiers succès, séparez le déplacement du schéma de celui des données actives. Notez le moteur source et sa version, les extensions, les règles de tri, les colonnes générées, les déclencheurs, les règles au niveau des lignes, les séquences et les objets volumineux. Si la destination utilise un autre moteur de base de données, traitez aussi cela comme une migration de l'application. La syntaxe SQL est la plus petite partie de ce changement : le comportement des transactions et la sémantique des types provoquent les mauvaises surprises.

La documentation PostgreSQL décrit pg_dump comme un export cohérent qui ne bloque ni les lecteurs ni les écrivains. C'est utile, mais les équipes interprètent souvent cette promesse trop largement. Un instantané cohérent n'inclut pas les écritures validées après son début. Il faut toujours une méthode de capture des changements, une pause finale des écritures ou une fenêtre de maintenance pour combler cet écart.

Utilisez une requête de réconciliation dont vous pouvez enregistrer le résultat avec le dossier de bascule. Ce fragment vérifie les nombres, les bornes d'identifiants et les fenêtres de mise à jour de trois tables importantes :

SELECT 'users' AS table_name, count(*) AS rows,
       min(id)::text AS min_id, max(id)::text AS max_id,
       max(updated_at) AS newest_update
FROM users
UNION ALL
SELECT 'projects', count(*), min(id)::text, max(id)::text, max(updated_at)
FROM projects
UNION ALL
SELECT 'orders', count(*), min(id)::text, max(id)::text, max(updated_at)
FROM orders;

Exécutez-la des deux côtés et examinez chaque différence. Testez ensuite les invariants métier que les nombres ne révèlent pas : aucune commande ne pointe vers un utilisateur absent, les soldes correspondent à leur grand livre, chaque enregistrement de fichier possède un objet et les règles d'unicité refusent les mêmes doublons.

Les sauvegardes nécessitent un test de restauration. Un fichier d'export réussi prouve seulement qu'une commande s'est terminée. Restaurez-le dans une destination vide, exécutez l'application dessus et chronométrez le processus. Ce temps de restauration mesuré vous indique si un retour arrière par restauration est réaliste ou simplement rassurant.

Le stockage de fichiers se cache souvent derrière des lignes de base de données. Une table uploads exportée peut préserver les noms d'objets alors que les objets eux-mêmes restent dans un compartiment géré par la plateforme. Copiez les octets, les sommes de contrôle, les types de contenu, les règles d'accès et les métadonnées de propriété, puis échantillonnez les téléchargements via l'application plutôt que dans la console de stockage. Si les URL contiennent des jetons signés ou le nom de l'ancien hôte, régénérez-les au lieu de copier des URL obsolètes. Traitez les fichiers envoyés par les utilisateurs comme un état inclus dans la même fenêtre de bascule, surtout s'ils peuvent remplacer un fichier pendant la copie de la base.

Les variables d'environnement révèlent l'architecture cachée

Les variables d'environnement doivent passer d'un ensemble hérité de chaînes de caractères à un contrat nommé pour chaque environnement. Les variables manquantes provoquent des échecs évidents. Les plus dangereuses contiennent des valeurs de production plausibles mais erronées, comme une clé de paiement de test, un ancien secret de webhook ou une origine de rappel qui renvoie les utilisateurs vers l'ancien hébergeur.

Recensez les variables dans le code, les paramètres de la plateforme, la configuration de compilation, les fonctions serverless, les tâches planifiées et le système de déploiement. Ne copiez pas tout l'ancien environnement vers le nouvel hébergeur. Classez chaque valeur selon son responsable, sa sensibilité, son périmètre, sa méthode de rotation et selon qu'elle est lue à la compilation ou à l'exécution.

Un manifeste compact rend cette frontière vérifiable :

DATABASE_URL          runtime   secret   owner=backend   rotate=yes
PUBLIC_APP_ORIGIN     build     public   owner=web       rotate=no
SESSION_SIGNING_KEY   runtime   secret   owner=security  rotate=yes
MAIL_SENDER           runtime   public   owner=ops       rotate=no
WEBHOOK_SECRET        runtime   secret   owner=backend   rotate=yes

La distinction entre compilation et exécution compte dans les interfaces React. Une valeur intégrée lors de la compilation ne changera pas lorsqu'une personne modifie un paramètre d'exécution. Recompilez le client et examinez le bundle livré pour y trouver la configuration publique. Ne mettez jamais un secret dans une variable simplement parce que son nom commence par le préfixe public d'un framework.

Faites tourner les secrets pendant une migration après les premiers succès lorsque la destination permet une période de chevauchement. Pour la vérification des webhooks ou la signature des sessions, acceptez brièvement l'ancien et le nouveau secret tout en n'émettant que le nouveau. Retirez l'ancienne valeur après la durée maximale de livraison ou de session. Si un fournisseur ne prend en charge qu'un seul secret, coordonnez le changement avec la bascule finale et rendez cette dépendance explicite dans le guide opératoire.

Avant le lancement, supprimez les variables inutilisées et faites échouer le démarrage en l'absence de valeurs requises. Après les premiers succès, ajoutez de l'observabilité avant le nettoyage afin de voir si une intégration apparemment obsolète reçoit encore des appels. Deviner à partir des noms de variables conduit les équipes à désactiver la tâche mensuelle discrète dont la comptabilité a réellement besoin.

Comparez les valeurs selon l'environnement, mais ne collez jamais de secrets dans le document de migration. Notez les noms des secrets et leurs étiquettes de version, puis conservez les valeurs dans le magasin de secrets de la destination. Donnez à l'identité de l'application le droit de lire uniquement ce dont ce déploiement a besoin. Lorsqu'une variable change, notez qui l'a modifiée et quelle version l'a consommée. Cette petite discipline répond à la question familière du soir de la bascule : « Quelle URL de base de données avons-nous réellement déployée ? »

La bascule du domaine est un changement de contrôle du trafic

Une bascule de domaine doit être conçue pour que les anciens et nouveaux déploiements puissent recevoir le trafic sans risque pendant la propagation DNS. Le DNS ne bascule pas partout en même temps, et réduire le TTL peu avant le changement n'affecte pas les résolveurs qui ont déjà mis l'ancienne valeur en cache.

Plusieurs jours avant une migration planifiée, réduisez le TTL de l'enregistrement concerné et confirmez la réponse faisant autorité. Gardez l'ancien déploiement sain au moins pendant l'ancien TTL, plus une marge prudente pour les résolveurs. Provisionnez le certificat sur le nouvel hébergeur avant d'y diriger le trafic, puis vérifiez séparément le domaine racine, l'hôte www, le sous-domaine API, les redirections et les enregistrements IPv6.

Le domaine n'est que la porte d'entrée. Mettez à jour les rappels d'authentification, les origines autorisées, les domaines de cookies, les URL canoniques, les points de terminaison de webhooks, les liens d'e-mail et toute configuration de liens profonds mobiles. Recherchez l'ancien nom d'hôte dans le dépôt et les paramètres de la plateforme. Une redirection aide les navigateurs, mais elle ne corrige ni une incompatibilité stricte d'URL de rappel OAuth ni un webhook signé pour le mauvais point de terminaison.

L'absence d'interruption n'est possible que si les deux versions fonctionnent avec un état compatible. Si la nouvelle version modifie la base de données d'une manière que l'ancien code ne peut pas lire, le chevauchement DNS crée des échecs. Utilisez des changements de schéma par extension puis retrait : ajoutez d'abord la nouvelle colonne ou table, déployez du code qui comprend les deux formes, déplacez les données, puis retirez l'ancienne forme lorsque tout le trafic a quitté l'ancienne version.

Pour les produits à faible volume, une courte fenêtre de maintenance peut être plus sûre qu'une configuration compliquée de réplication en direct. Indiquez quand les écritures seront suspendues, renvoyez une vraie réponse de maintenance, terminez le travail d'arrière-plan, effectuez la copie finale, réconciliez, basculez le trafic puis rouvrez les écritures. L'accès en lecture seule peut rester disponible s'il ne peut pas mettre en file un travail caché.

Le retour arrière doit suivre une règle sur les données. Rediriger le DNS est simple tant qu'aucune écriture n'a atteint la destination. Dès que les utilisateurs ont écrit des données des deux côtés, un retour DNS peut perdre ou diviser les données. Définissez le dernier moment sûr pour revenir en arrière. Après ce moment, avancez ou réconciliez les changements au lieu de prétendre qu'une inversion du trafic restaure la cohérence.

Surveillez l'application depuis l'extérieur du compte du nouvel hébergeur. Résolvez le domaine via plusieurs résolveurs publics, demandez la chaîne de certificats, chargez une page sans cache chaud, soumettez une transaction réversible et confirmez que le travail d'arrière-plan obtenu se termine. Les tableaux de bord de l'hébergeur peuvent indiquer un déploiement sain alors que les utilisateurs reçoivent une ancienne réponse DNS ou qu'une périphérie régionale sert une version plus ancienne. Gardez une vérification synthétique active sur le domaine public et sur un hôte de test propre à la destination jusqu'à la fin du chevauchement.

Le nettoyage du code source détermine si la migration dure

Le nettoyage du code source doit supprimer le couplage à la plateforme sans effacer une structure générée utile ni déclencher une réécriture sans rapport. Le code généré peut être répétitif ou maladroit, mais un désaccord esthétique n'est pas une exigence de migration. Modifiez ce qui empêche des compilations indépendantes, les tests, la revue de sécurité ou la maintenance future.

Commencez par la provenance. Exportez le dépôt complet et conservez les fichiers de licence, les attributions des ressources, les migrations générées, les fichiers de verrouillage et la configuration. Vérifiez si des secrets ou jetons de plateforme sont entrés dans l'historique Git. Les retirer du dernier fichier ne les révoque pas, faites donc tourner les identifiants exposés et décidez si une réécriture de l'historique est justifiée.

Cherchez ensuite les imports propres à la plateforme, les chemins de proxy, les clients de base de données, les assistants d'authentification, les adaptateurs de stockage, les fichiers de déploiement et les points de terminaison d'API générés. Remplacez-les derrière des interfaces d'application étroites lorsque c'est pratique. Une recherche dans tout le dépôt est utile, mais l'exécution des parcours utilisateur vous montre quelles références comptent encore.

Le nettoyage des dépendances vient après le bon fonctionnement de la compilation indépendante. Retirez les paquets un par un, régénérez le fichier de verrouillage avec le gestionnaire de paquets existant et lancez les tests après chaque groupe. Ne mettez pas à niveau le framework, ne remplacez pas la gestion de l'état, ne renommez pas chaque composant et ne migrez pas l'hébergement dans le même changement. Cela crée trop d'explications possibles pour une seule défaillance.

Le code serveur généré mérite un examen attentif aux frontières de confiance. Suivez chaque requête de la route au contrôle d'autorisation puis à la requête de base de données, et vérifiez que le serveur ne repose pas sur une règle de visibilité côté client. Examinez les limites d'envoi de fichiers, les cibles des requêtes sortantes, les messages d'erreur et les routes administratives. Il ne s'agit pas d'appeler à réécrire chaque gestionnaire généré. C'est une vérification ciblée que le code applique toujours les règles d'accès après la disparition du middleware de la plateforme et des proxys gérés.

Le projet généré a également besoin de fichiers opérationnels ordinaires : un manifeste d'environnement d'exemple avec des valeurs fictives, des commandes de migration de base de données, des instructions de compilation et de démarrage, des vérifications d'état et une description des workers d'arrière-plan. Gardez ces instructions exécutables. Un README qui dit « configurez la base de données » note seulement qu'une base de données existe.

Avant le lancement, le nettoyage peut inclure des réinitialisations de schéma et de grands remaniements, car aucune promesse de compatibilité n'existe. Après les premiers succès, préservez les formes d'API publiques, les identifiants et le comportement visible par les utilisateurs jusqu'à ce que le déplacement de l'infrastructure se stabilise. Laissez au nouveau déploiement une période calme avant de modifier le comportement du produit. Lorsque migration et refonte arrivent ensemble, le support ne peut pas savoir si une réclamation vient du déplacement ou de la nouvelle fonctionnalité.

La répétition transforme l'interruption en décision

Une répétition de migration doit reproduire la séquence de production avec une copie récente de données anonymisées et produire des durées mesurées, des résultats de réconciliation et un point d'abandon testé. Une liste de contrôle copiée depuis un autre projet ne peut pas vous dire combien de temps votre base de données met à se restaurer ni quelle tâche continue d'écrire après le début du mode maintenance.

Utilisez une personne pour exécuter et une autre pour observer, noter les heures et contester les vérifications sautées. Dans une petite équipe, la seconde personne peut être le fondateur, mais elle a besoin d'assez de contexte pour reconnaître un résultat modifié. La personne qui tape les commandes ne doit pas être la seule à décider si ces commandes ont fonctionné.

Un guide opératoire pratique suit un ordre strict :

1. Gelez les déploiements sans rapport et notez les versions actuelles, les valeurs DNS et les versions des secrets.
2. Placez les écritures en mode maintenance, videz les files, arrêtez les tâches planifiées et notez le dernier repère de la source.
3. Copiez les données restantes, réconciliez les tables et les invariants métier, puis lancez les tests d'authentification et des parcours essentiels.
4. Basculez le trafic, vérifiez les certificats et les rappels, surveillez les erreurs et la profondeur des files, puis rouvrez les écritures.
5. Au point de contrôle annoncé, continuez sur le nouveau système ou appliquez la règle de retour arrière documentée pour les données.

Avant le lancement, répétez en détruisant la destination et en la reconstruisant depuis le dépôt. L'objectif est la reproductibilité, une base vide et un environnement neuf révèlent donc davantage qu'une copie ressemblant à la production.

Après les premiers succès, répétez à l'échelle et avec concurrence. Copiez assez de données représentatives pour révéler les index lents et les longues migrations. Rejouez du trafic de lecture sûr si vous en disposez, créez des écritures synthétiques avec des identifiants connus et vérifiez que les tâches d'arrière-plan sont idempotentes avant d'autoriser les tentatives. Une tâche d'e-mail qui envoie deux fois n'est pas inoffensive sous prétexte que la base de données est restée cohérente.

Mesurez la pause des écritures séparément de toute la fenêtre de maintenance. Vous pouvez souvent effectuer la copie massive tandis que la source reste active, puis ne suspendre le service que pour le différentiel et la validation. Si la répétition montre que le différentiel ne peut pas se terminer dans la fenêtre autorisée, ajoutez une réplication ou une capture des changements. Ne découvrez pas cette exigence avec des clients qui attendent.

Conservez les preuves après la migration : versions de la source et de la destination, horodatages, vérifications des lignes, résultats des tests de bon fonctionnement, réponses DNS, décisions des opérateurs et heure de désactivation des anciens services. Ces éléments accélèrent le débogage et évitent que le prochain plan de migration dépende des souvenirs de quelqu'un.

Choisissez l'étape selon la réversibilité

La meilleure étape pour migrer est celle où l'échec que vous pouvez raisonnablement provoquer reste réversible. Avant le lancement, le produit offre peu d'éléments concrets mais une liberté presque illimitée. Après les premiers succès, le produit apporte des informations mais transporte un état qui doit rester cohérent pendant tout le déplacement.

J'utilise six critères de décision :

• Migrez avant le lancement si une contrainte connue de conformité, de propriété, d'export, d'hébergement ou d'architecture bloque la mise en production prévue.
• Restez et lancez si la plateforme répond aux besoins actuels et que l'équipe migrerait autrement uniquement par anxiété.
• Migrez après les premiers succès si l'usage mesuré révèle une contrainte et si vous pouvez répéter la continuité des identités, des données et du trafic.
• Reportez la migration si vous ne pouvez pas exporter une base de données restaurable, contrôler le domaine, recenser les secrets ou définir qui possède les écritures.
• Préférez une séparation progressive lorsque l'authentification ou les données peuvent rester temporairement en place pendant le déplacement du calcul et de l'hébergement.

Lovable, Bolt, v0 et Replit peuvent tous produire des projets dont la portabilité dépend des services choisis, de l'offre utilisée et du code généré à ce moment-là. Examinez le dépôt réel et les contrôles du compte. Une catégorie de fournisseur ne répond pas à la question de savoir si vos hachages de mots de passe, extensions de base de données, fichiers ou paramètres de déploiement précis peuvent être déplacés.

Si vous choisissez un nouvel environnement de développement par chat, les contrôles de planification et de retour arrière réduisent le coût d'un découpage de la migration en modifications vérifiables. Koder.ai prend en charge l'export du code source, le déploiement et l'hébergement, les domaines personnalisés, les instantanés et le retour arrière : une équipe peut donc intégrer ces vérifications de propriété au plan de migration sans faire dépendre les conseils de l'article d'une seule plateforme.

Prévoyez un budget de migration avant le lancement, même si vous décidez de rester. Gardez le code source sous votre contrôle, versionnez le schéma, documentez le contrat d'environnement et répétez une restauration. Ces actions coûtent bien moins cher tant que l'application est petite, et elles préservent l'option de migrer lorsque les premiers succès apportent une raison plutôt qu'une crise.

Si l'équipe ne peut pas effectuer cette restauration aujourd'hui, la portabilité reste une intention plutôt qu'une propriété de l'application.