Migration Report n8n : la checklist automatique avant de passer à la 2.0

Passer à une version majeure d'un logiciel qui fait tourner des workflows en production est toujours un moment délicat : quel node va se comporter différemment, quelle variable d'environnement va changer de valeur par défaut, quel credential va soudainement être refusé ? Pour la sortie de n8n 2.0, l'éditeur a ajouté un outil dédié à cette question précise : le Migration Report, un scanner intégré qui audite votre instance avant la mise à jour et liste noir sur blanc ce qui va casser. Ce guide explique ce que couvre l'outil, comment lire son rapport, et comment l'utiliser pour migrer sans mauvaise surprise.

Pourquoi n8n a ajouté un outil de migration dédié

n8n 2.0 introduit plusieurs changements de comportement par défaut, pensés pour durcir la sécurité des instances self-hosted : les Task Runners isolent désormais systématiquement l'exécution du node Code, les nodes Execute Command et Local File Trigger sont désactivés d'office, et l'accès aux variables d'environnement depuis un node Code est bloqué par défaut. Chacun de ces changements est justifié individuellement, mais mis bout à bout, ils peuvent silencieusement casser des workflows qui reposaient sur l'ancien comportement — souvent sans message d'erreur clair au moment de la mise à jour elle-même.

Plutôt que de laisser chaque équipe découvrir ces cassures après coup, n8n a intégré le Migration Report directement dans le produit, disponible depuis la version 1.121.0 (donc bien avant la sortie de la 2.0), accessible aux administrateurs globaux dans Settings > Migration Report.

Ce que le rapport vérifie concrètement

Le Migration Report scanne l'instance selon deux axes :

• Problèmes au niveau des workflows : un node ou un comportement spécifique qui va cesser de fonctionner tel quel après la mise à jour (par exemple un workflow utilisant Execute Command sans que le node ait été explicitement réautorisé).
• Problèmes au niveau de l'instance : des variables d'environnement ou une configuration serveur qui doivent être ajustées avant de migrer, indépendamment d'un workflow en particulier.

Chaque point détecté est classé par niveau de gravité :

Gravité	Signification	Action recommandée
Critique	Le workflow cessera de fonctionner après la mise à jour	Corriger avant de migrer
Moyenne	Comportement modifié, à valider selon le contexte	Vérifier avant ou juste après la migration
Faible	Changement mineur, sans impact fonctionnel majeur	Peut attendre

Le rapport affiche aussi un résumé global de compatibilité : combien de workflows continueront de fonctionner sans aucune modification après la mise à jour. Une fois les corrections faites, un clic sur « rafraîchir » recalcule ce score — un rapport propre (zéro point critique) est le signal que l'instance est prête à migrer.

Les cas les plus fréquents détectés par le rapport

Dans la pratique, trois familles de problèmes reviennent le plus souvent :

1. Execute Command ou Local File Trigger utilisés sans réautorisation. Ces nodes sont désactivés par défaut en 2.0 pour réduire la surface d'attaque ; il faut les retirer explicitement de la liste d'exclusion via NODES_EXCLUDE dans vos variables d'environnement si vous en avez réellement besoin.
2. Code node dépendant des variables d'environnement. Un script qui lisait process.env directement doit être adapté : le blocage par défaut protège vos credentials et secrets d'une fuite accidentelle via un node Code mal maîtrisé.
3. Comportements liés aux Task Runners. Certains scripts très spécifiques (accès disque, timing précis) peuvent réagir différemment une fois exécutés dans l'environnement isolé du runner plutôt qu'en processus interne — voir notre guide sur les Task Runners pour les variables de configuration disponibles.

Un rapport qui ne remonte aucun de ces trois points sur une instance ancienne mérite d'ailleurs une vérification manuelle : cela signifie généralement que l'instance utilise déjà peu de fonctionnalités self-hosted avancées, ou qu'elle tourne sur n8n Cloud où ces contraintes ne s'appliquent pas de la même façon.

Checklist pour une migration sans incident

1. Sauvegarder la base de données avant toute chose — voir notre guide de sauvegarde et restauration PostgreSQL. Le Migration Report réduit le risque, il ne le supprime pas.
2. Ouvrir Settings > Migration Report et laisser le scan s'exécuter sur l'instance actuelle (avant toute mise à jour de version).
3. Traiter les points critiques en premier : réactiver un node nécessaire, adapter un script Code, ajuster une variable d'environnement.
4. Rafraîchir le rapport pour confirmer qu'il ne reste plus de point critique, puis traiter les points de gravité moyenne selon le temps disponible.
5. Mettre à jour l'instance, puis relancer le Migration Report une seconde fois après coup — l'outil reste accessible en 2.0 et permet de vérifier que rien n'a été oublié.
6. Tester manuellement les workflows critiques pour votre activité (facturation, notifications clients, synchronisations) avant de considérer la migration terminée.

Pour une instance qui héberge des workflows sensibles — pistes d'audit RGPD, automatisations de conformité proches de celles du Pack Conformité & Audit (149 €) — cette étape de vérification avant migration n'est pas optionnelle : une automatisation de conformité qui s'arrête silencieusement après une mise à jour est justement le genre d'incident qu'un audit régulier est censé prévenir.

Un bénéfice de la migration au-delà de la sécurité : moins d'erreurs « Database Locked »

Corriger les points remontés par le Migration Report n'est pas la seule bonne raison de migrer. n8n 2.0 embarque aussi un nouveau driver de pooling pour SQLite, qui réduit nettement la fréquence des erreurs SQLITE_BUSY: database is locked — un problème classique sur les instances self-hosted en SQLite dès que plusieurs exécutions tournent en parallèle (voir notre guide sur la migration vers PostgreSQL pour la solution la plus radicale à ce problème). Le phénomène sous-jacent est documenté depuis longtemps en informatique : une étude fondatrice de Gray, Lorie, Putzolu et Traiger sur la granularité des verrous dans les bases de données partagées (Granularity of Locks and Degrees of Consistency in a Shared Data Base, IBM Research, 1976) montre que la contention de verrous augmente fortement avec le nombre d'écritures concurrentes sur un même fichier de données — exactement le mécanisme à l'origine des blocages SQLite quand plusieurs workflows n8n écrivent en même temps dans la même base. Un meilleur pooling ne supprime pas la contention par nature, mais il limite le nombre de requêtes qui se bloquent mutuellement au même instant, avec un effet direct sur la stabilité en usage réel.

En résumé

Le Migration Report transforme une mise à jour majeure — toujours source d'inquiétude légitime sur une instance en production — en une checklist actionnable : ce qui va casser, pourquoi, et comment le corriger avant plutôt qu'après. Pour toute instance self-hosted qui fait tourner des automatisations métier, qu'il s'agisse des workflows des packs FlowKit ou de scripts maison, passer par Settings > Migration Report avant une mise à jour vers la 2.0 prend quelques minutes et évite des heures de débogage a posteriori.