Ouch 
Et si tu repars sur ton ancien yaml (en mode bridge) et restore le backup, tu obtiens la meme erreur SQL ?
Je vais m’y atteler ce WE, j’espérai ne pas avoir besoin de passer de temps sur la migration Jeedom mais plutôt sur l’implémentation des nouveaux containers zwave & zigbee mqtt 
EDIT: pour finir j’ai restauré à la main la BDD de mon ancien Jeedom sur ma nouvelle BDD et j’ai pu relancer Jeedom. Par sécurité j’ai refait une restauration du backup dans l’interface Jeedom. Un coup de mise à jour des sources APT et les dépendances de mes plugin ont pu se réinstaller proprement. Je suis à présent revenu à situation nominale.
J’enchaine avec l’intégration des plugin Jeezigbee, Zwave JS, MQTT Manager en lien avec mon serveur Mosquitto (déjà du mieux côté MQTT Manager que j’ai pu lier à Mosquitto) 
EDIT 2: Migration Zwave JS effectuée
Bien joué 
Donc ton container Jeedom est désormais délesté du role de broker et en macvlan ?
Absolument et la brique zigbee est aussi opérationnelle.
Maintenant j’ai un autre soucis, j’exposais à l’extérieur mon jeedom au travers de cloudflare.
Le container cloudflare étant sur mon host Synology, il ne peut pas dialoguer par défaut avec mon réseau macvlan (limitation de ce type de réseau, le parent host n’est pas joignable)
Avec une petite règle de routage j’arrive depuis le syno à pinger mes ip du macvlan mais malgré tout cloudflare n’arrive pas à router le traffic sur mon container jeedom…et là…je sèche…
sudo ip link add host2macvlan link ovs_bond0 type macvlan mode bridge
sudo ip link set host2macvlan up
sudo ip route add 192.168.1.192/27 dev host2macvlan
Connais pas le container cloudflare…
Perso j’ai contourné avec le reverse proxy du NAS dans Panneau de configuration / protail de connexion / Avancé / proxy inversé :
Oui c’est ce que je faisais auparavant, je m’étais amusé ensuite avec cloudflare pour sécuriser quelques services de mon NAS à l’extérieur tout en ajoutant une authentification Google par dessus.
Je vais peut-être revenir en arrière pour jeedom.