Guide de migration HiveMQ Cloud Serverless : migrer vos clients MQTT étape par étape

Une migration depuis HiveMQ Cloud Serverless est avant tout un projet de reconfiguration : le protocole MQTT ne change pas, mais chaque client a besoin d'un nouveau nom d'hôte, de nouveaux identifiants et éventuellement d'un nouveau client ID, et tout l'état qui résidait sur l'ancien cluster doit être reconstruit. Ce guide déroule la procédure complète en six étapes, avec un broker privé ConnectMQ comme destination. Les mêmes étapes s'appliquent à tout broker MQTT conforme aux standards.

Si vous n'avez pas encore lu le contexte, commencez par Fin de vie de HiveMQ Cloud Serverless pour les dates et ce que HiveMQ supprime après le 31 décembre 2026.

Étape 1 : inventorier tout ce qui se connecte

On ne peut pas migrer ce qu'on n'a pas listé. Ouvrez la console HiveMQ Cloud, notez le nom d'hôte de votre cluster et chaque identifiant d'accès, puis construisez un tableau avec une ligne par type de client :

N'oubliez pas les clients discrets : un flux Node-RED sur un Raspberry Pi oublié, une entrée Grafana ou Telegraf, une application mobile avec un nom d'hôte codé en dur, ou un partenaire abonné à un seul topic. La checklist de migration HiveMQ contient une version imprimable de cet inventaire.

Étape 2 : faire correspondre les fonctionnalités avec le nouveau broker

Comparez votre inventaire avec le plan de destination avant de modifier quoi que ce soit :

Deux lignes demandent une décision.

Client IDs. HiveMQ Cloud laisse chaque client choisir son propre client ID. ConnectMQ lie le client ID aux identifiants délivrés : un client peut utiliser exactement le client ID délivré ou une variante avec suffixe, comme YOUR_CLIENT_ID_sensor140. Prévoyez de donner à chaque appareil un suffixe dérivé de son numéro de série ou de son adresse MAC. Voir bonnes pratiques pour le client ID MQTT pour des modèles.

Permissions. Si vous utilisiez les permissions de topics de HiveMQ pour séparer des parties non fiables (par exemple des clients qui ne doivent pas voir les données les uns des autres), n'essayez pas de reproduire cela sur un seul broker. Utilisez un broker par client ou par périmètre de confiance, ou placez un backend entre les deux.

Étape 3 : créer le broker de destination

1. Inscrivez-vous sur app.connectmq.com. Le plan Serverless gratuit ne demande pas de carte bancaire, ce qui est idéal pour les tests.
2. Choisissez un plan dimensionné sur votre pic de connexions plus une marge. Utilisez Serverless (Paid) pour les flottes de production jusqu'à 1 000 connexions, ou Dedicated pour les charges plus importantes ou sensibles à la latence. Nos guides sur l'alternative serverless et l'alternative cloud managée vous aident à choisir.
3. Créez le broker et copiez le nom d'utilisateur, le mot de passe et le client ID générés.
4. Cette fois, rendez l'adresse du broker configurable. Stockez le nom d'hôte, le port, les identifiants et le client ID dans un fichier de configuration, un service de provisioning ou des paramètres modifiables par OTA plutôt que dans le firmware compilé. Un simple alias DNS sous votre propre domaine ne suffit pas à lui seul pour le TLS, car le certificat du broker est émis pour le nom d'hôte du fournisseur et les clients qui vérifient le nom d'hôte le rejetteraient.

Étape 4 : tester avec un vrai client

Avant de migrer les clients de production, validez les bases avec les mêmes bibliothèques que vos appareils. Avec les clients mosquitto en TLS :

# Terminal 1 : abonnement
mosquitto_sub -h broker.connectmq.com -p 8883 --capath /etc/ssl/certs \
  -u YOUR_USERNAME -P YOUR_PASSWORD -i YOUR_CLIENT_ID_test1 \
  -t 'site1/#' -v

# Terminal 2 : publication
mosquitto_pub -h broker.connectmq.com -p 8883 --capath /etc/ssl/certs \
  -u YOUR_USERNAME -P YOUR_PASSWORD -i YOUR_CLIENT_ID_test2 \
  -t 'site1/room1/temp' -m '{"temp":21.7}' -q 1

Testez ensuite les détails qui comptent pour votre flotte : niveaux de QoS, messages retenus, messages Last Will, sessions persistantes si vous en utilisez, tailles de messages proches de votre plus gros payload et latence depuis le réseau qu'utilisent réellement vos appareils. L'explorateur de topics en direct du portail ConnectMQ affiche chaque message à son arrivée : c'est le moyen le plus rapide de valider les structures de topics. Des exemples de code pour ESP32, Python, Node.js et Node-RED se trouvent dans Reconfigurer ses clients MQTT après HiveMQ.

Étape 5 : faire tourner les deux brokers, puis migrer par vagues

La migration la plus sûre maintient les deux brokers en service et relaie le trafic entre eux, de sorte qu'un appareil sur l'ancien broker et une application sur le nouveau continuent de voir les messages l'un de l'autre. Un petit processus de relais s'abonne sur un broker et republie sur l'autre. Nous présentons un script de relais complet et l'ordre des vagues dans Migration HiveMQ sans interruption.

L'ordre recommandé est le suivant :

1. Les consommateurs d'abord. Migrez les bases de données, les moteurs de règles, les flux Node-RED et les tableaux de bord vers le nouveau broker. Grâce au relais, ils reçoivent toujours les données des appareils restés sur l'ancien cluster.
2. Un groupe pilote d'appareils. Quelques-uns, issus de sites et de versions de firmware différents. Surveillez-les pendant quelques jours.
3. Le reste de la flotte par lots, avec un point de contrôle après chaque lot.
4. Les producteurs de commandes en dernier, une fois que les appareils qu'ils pilotent ont migré.

Pendant chaque vague, surveillez le nombre de connexions par rapport à votre plan. Si vous dépassez le quota, les clients MQTT 5 reçoivent le reason code 0x97 (quota exceeded). Montez en gamme avant une vague plutôt que pendant.

Étape 6 : basculer et nettoyer

Lorsque le cluster HiveMQ n'affiche plus aucune connexion client en dehors du relais :

1. Arrêtez le relais.
2. Vérifiez que chaque topic attendu est actif sur le nouveau broker et que l'état retenu a été republié.
3. Exportez tout ce que vous souhaitez conserver de l'ancien cluster, comme la liste des identifiants pour vos archives.
4. Supprimez le cluster Serverless, en gardant à l'esprit que HiveMQ ne peut pas le recréer.
5. Retirez l'ancien nom d'hôte des valeurs par défaut du firmware, de la documentation, des runbooks et des gestionnaires de secrets.

Visez une fin de migration bien avant le 31 décembre 2026. Une marge de plusieurs semaines laisse de la place pour les appareils qui se connectent rarement, comme les équipements saisonniers ou les capteurs qui se réveillent une fois par jour.

Pièges courants

• Collisions de client ID. Deux appareils utilisant le même client ID se déconnecteront mutuellement en boucle, sur n'importe quel broker. Dérivez les suffixes d'identifiants matériels uniques.
• Certificats de CA codés en dur. Les appareils qui épinglent un bundle de CA spécifique peuvent rejeter le certificat d'un nouveau broker. ConnectMQ utilise un certificat Let's Encrypt ; assurez-vous que la racine ISRG Root X1 figure dans le magasin de confiance de l'appareil. Voir configuration TLS de MQTT.
• Supposer que l'état retenu est transféré. Ce n'est pas le cas. Faites publier leur état actuel aux appareils avec le flag retain juste après la connexion.
• Oublier la logique de reconnexion. Un appareil sans backoff correct peut inonder un nouveau broker pendant une vague. Revoyez d'abord l'intervalle keep alive MQTT et les paramètres de reconnexion de votre client.

Questions fréquentes

Combien de temps dure une migration HiveMQ Serverless ?

Pour quelques applications, une journée. Pour des flottes d'appareils de terrain qui nécessitent des mises à jour de firmware, comptez plusieurs semaines : développement et test du nouveau firmware, déploiement progressif et attente des appareils rarement connectés. Commencez dès maintenant pour que l'échéance ne soit pas votre date de test.

Puis-je migrer sans mettre à jour le firmware des appareils ?

Uniquement si le nom d'hôte, les identifiants et le client ID sont configurables sans modification du firmware, par exemple via un fichier de configuration ou un service de provisioning. S'ils sont compilés dans le firmware, il vous faut une mise à jour over-the-air.

Dois-je modifier ma structure de topics ?

Non. Les topics ne sont que des chaînes de caractères, et ConnectMQ prend en charge les wildcards standard ainsi que les profondeurs de topics habituelles des architectures IoT. Conservez votre structure actuelle pour que les tableaux de bord et les règles continuent de fonctionner.

Par quel plan ConnectMQ commencer ?

Commencez par le plan Serverless gratuit pour tester. Pour la production, choisissez Serverless (Paid) jusqu'à 1 000 connexions, ou le broker MQTT managé dans le cloud de ConnectMQ en Dedicated lorsque vous avez besoin d'un cluster isolé.