Una migración de HiveMQ Cloud Serverless es, sobre todo, un proyecto de reconfiguración: el protocolo MQTT sigue siendo el mismo, pero cada cliente necesita un nuevo hostname, nuevas credenciales y quizá un nuevo client ID, y todo el estado que vivía en el clúster antiguo hay que reconstruirlo. Esta guía recorre el procedimiento completo en seis pasos, con un broker privado de ConnectMQ como destino. Los mismos pasos sirven para cualquier broker MQTT basado en estándares.
Si todavía no conoces el contexto, empieza por el fin de HiveMQ Cloud Serverless para ver las fechas y lo que HiveMQ elimina después del 31 de diciembre de 2026.
Paso 1: inventaría todo lo que se conecta
No puedes migrar lo que no has listado. Abre la consola de HiveMQ Cloud, anota el hostname de tu clúster y todas las credenciales de acceso, y crea una tabla con una fila por tipo de cliente:
| Campo | Ejemplo | Por qué importa |
|---|---|---|
| Tipo de cliente | Sensor de temperatura ESP32 | Determina cómo lo reconfiguras |
| Cantidad | 140 | Define el dimensionamiento del plan |
| Patrón de client ID | sensor-<mac> |
Debe encajar con las reglas de client ID del nuevo broker |
| Credencial utilizada | devices-rw |
Pasa a ser una nueva credencial en el nuevo broker |
| Publica en | site1/+/temp |
Estructura de topics que verificar tras el cambio |
| Se suscribe a | site1/+/cmd |
Estructura de topics que verificar tras el cambio |
| QoS, retenidos, clean start | QoS 1, estado retenido | Funciones que confirmar en el plan de destino |
| Transporte | MQTT sobre TLS, puerto 8883 | Puerto y ajustes de TLS que cambiar |
| Vía de actualización | OTA, archivo de configuración, manual | Esfuerzo y plazo |
No olvides los clientes silenciosos: un flujo de Node-RED en una Raspberry Pi olvidada, una entrada de Grafana o Telegraf, una app móvil con el hostname escrito en el código o un partner que se suscribe a un solo topic. El checklist de migración desde HiveMQ incluye una versión imprimible de este inventario.
Paso 2: mapea las funciones al nuevo broker
Compara tu inventario con el plan de destino antes de cambiar nada:
| Qué usas en HiveMQ Serverless | Qué revisar en el destino | ConnectMQ |
|---|---|---|
| MQTT 3.1.1 / 5.0 | Las mismas versiones | Ambas compatibles |
| TLS en 8883, WebSocket seguro | Puertos y ruta | 1883, 8883 (TLS), 8083 (WS), 8084 (WSS, ruta /mqtt) |
| Credenciales creadas en la consola | Cómo se emiten las credenciales | Usuario, contraseña y client ID generados en el portal |
| Cualquier client ID | Reglas de client ID | Client ID vinculado a las credenciales; se permiten variantes con _sufijo |
| Permisos de topic por credencial | Modelo de control de acceso | No hay ACL por topic; usa brokers o credenciales separados por cada frontera de confianza |
| QoS 2 | Soporte en el plan | Serverless (Paid) y superiores |
| Mensajes retenidos | Soporte y durabilidad | Compatibles; los clientes deberían volver a publicar su estado al conectarse |
| Número de clientes simultáneos | Límites del plan | 25 en Serverless Free, hasta 1.000 en Serverless Paid, Dedicated a partir de ahí |
Dos filas requieren una decisión.
Client IDs. HiveMQ Cloud permite que cada cliente elija su propio client ID. ConnectMQ vincula el client ID a las credenciales emitidas: un cliente puede usar exactamente el client ID emitido o una variante con sufijo, como YOUR_CLIENT_ID_sensor140. Planifica dar a cada dispositivo un sufijo derivado de su número de serie o su dirección MAC. Consulta las buenas prácticas para el client ID de MQTT para ver patrones.
Permisos. Si usabas los permisos de topic de HiveMQ para separar a partes que no confían entre sí (por ejemplo, clientes que no deben ver los datos de los demás), no intentes reproducirlo en un único broker. Usa un broker por cliente o por frontera de confianza, o coloca un backend en medio.
Paso 3: crea el broker de destino
- Regístrate en app.connectmq.com. El plan Serverless gratuito no requiere tarjeta de crédito, lo que es ideal para hacer pruebas.
- Elige un plan dimensionado para tu pico de conexiones más un margen. Usa Serverless (Paid) para flotas en producción de hasta 1.000 conexiones, o Dedicated para cargas más grandes o sensibles a la latencia. Nuestras guías sobre la alternativa serverless y la alternativa gestionada en la nube te ayudan a elegir.
- Crea el broker y copia el usuario, la contraseña y el client ID generados.
- Esta vez, haz que la dirección del broker sea configurable. Guarda hostname, puerto, credenciales y client ID en un archivo de configuración, un servicio de aprovisionamiento o ajustes actualizables por OTA, en lugar de en el firmware compilado. Un simple alias DNS bajo tu propio dominio no basta por sí solo con TLS, porque el certificado del broker se emite para el hostname del proveedor y los clientes que verifican el hostname lo rechazarían.
Paso 4: prueba con un cliente real
Antes de mover clientes de producción, comprueba lo básico con las mismas librerías que usan tus dispositivos. Con los clientes de mosquitto sobre TLS:
# Terminal 1: suscripción
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: publicación
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
Después prueba los detalles que importan para tu flota: niveles de QoS, mensajes retenidos, mensajes Last Will, sesiones persistentes si las usas, tamaños de mensaje cercanos a tu payload más grande y la latencia desde la red que usan realmente tus dispositivos. El explorador de topics en vivo del portal de ConnectMQ muestra cada mensaje según llega, que es la forma más rápida de confirmar las estructuras de topics. Hay ejemplos de código para ESP32, Python, Node.js y Node-RED en Reconfigurar clientes MQTT después de HiveMQ.
Paso 5: ejecuta ambos en paralelo y migra por oleadas
La migración más segura mantiene ambos brokers en funcionamiento y retransmite el tráfico entre ellos, de modo que un dispositivo en el broker antiguo y una aplicación en el nuevo siguen viendo los mensajes del otro. Un pequeño proceso relay se suscribe en un broker y vuelve a publicar en el otro. Mostramos un script de relay completo y el orden de las oleadas en Migración desde HiveMQ sin interrupciones.
El orden recomendado es:
- Primero los consumidores. Mueve bases de datos, motores de reglas, flujos de Node-RED y dashboards al nuevo broker. Gracias al relay siguen recibiendo datos de los dispositivos del clúster antiguo.
- Un grupo piloto de dispositivos. Unos pocos de distintas ubicaciones y versiones de firmware. Obsérvalos durante unos días.
- El resto de la flota por lotes, con un punto de control después de cada lote.
- Los productores de comandos al final, cuando los dispositivos que controlan ya se hayan movido.
Durante cada oleada, vigila el número de conexiones frente a tu plan. Si superas la cuota, los clientes MQTT 5 reciben el reason code 0x97 (quota exceeded). Amplía el plan antes de una oleada, no durante ella.
Paso 6: haz el cambio y limpia
Cuando el clúster de HiveMQ ya no muestre conexiones de clientes aparte del relay:
- Detén el relay.
- Confirma que todos los topics esperados están activos en el nuevo broker y que el estado retenido se ha vuelto a publicar.
- Exporta lo que quieras conservar del clúster antiguo, como una lista de credenciales para tus registros.
- Elimina el clúster Serverless, teniendo en cuenta que HiveMQ no puede volver a crearlo.
- Quita el hostname antiguo de los valores por defecto del firmware, la documentación, los runbooks y los almacenes de secretos.
Intenta terminar con bastante antelación al 31 de diciembre de 2026. Un margen de varias semanas deja espacio para los dispositivos que se conectan rara vez, como equipos de temporada o sensores que se despiertan una vez al día.
Errores habituales
- Colisiones de client ID. Dos dispositivos con el mismo client ID se desconectarán mutuamente una y otra vez en cualquier broker. Deriva los sufijos de identificadores de hardware únicos.
- Certificados de CA fijados en el código. Los dispositivos que fijan un bundle de CA concreto pueden rechazar el certificado de un nuevo broker. ConnectMQ usa un certificado Let's Encrypt; asegúrate de que la raíz ISRG Root X1 está en el almacén de confianza del dispositivo. Consulta la configuración de TLS en MQTT.
- Suponer que el estado retenido se traslada. No se traslada. Haz que los dispositivos publiquen su estado actual con el flag retain justo después de conectarse.
- Olvidar la lógica de reconexión. Un dispositivo sin un backoff adecuado puede saturar un nuevo broker durante una oleada. Revisa antes el keep alive de MQTT y los ajustes de reconexión de tu cliente.
Preguntas frecuentes
¿Cuánto tarda una migración de HiveMQ Serverless?
Para unas pocas aplicaciones, un día. Para flotas de dispositivos en campo que necesitan actualizaciones de firmware, cuenta con semanas: desarrollar y probar el nuevo firmware, el despliegue escalonado y la espera a los dispositivos que se conectan rara vez. Empieza ya para que la fecha límite no sea tu día de pruebas.
¿Puedo migrar sin actualizar el firmware de los dispositivos?
Solo si el hostname, las credenciales y el client ID se pueden configurar sin cambiar el firmware, por ejemplo mediante un archivo de configuración o un servicio de aprovisionamiento. Si están compilados en el firmware, necesitas una actualización over-the-air.
¿Tengo que cambiar mi estructura de topics?
No. Los topics son solo cadenas de texto, y ConnectMQ admite los comodines estándar y las profundidades de topic habituales en los diseños IoT. Mantén tu estructura actual para que los dashboards y las reglas sigan funcionando.
¿Con qué plan de ConnectMQ debería empezar?
Empieza con el plan Serverless gratuito para hacer pruebas. Para producción, elige Serverless (Paid) para hasta 1.000 conexiones, o el broker MQTT gestionado en la nube de ConnectMQ (Dedicated) cuando necesites un clúster aislado.
