Checklist de migración desde HiveMQ: analiza tu carga, planifica las credenciales y prueba un broker privado

Salir de HiveMQ Cloud Serverless es sencillo si haces tres cosas antes de tocar ningún dispositivo: conocer tu carga de trabajo, planificar tus nuevas credenciales y probar un broker privado con tu tráfico real. Este checklist convierte esos tres pasos en tareas concretas que puedes ir marcando. Sirve para cualquier broker de destino; cuando resulta útil, mostramos cómo se traduce cada punto a ConnectMQ.

HiveMQ retira Serverless el 31 de diciembre de 2026. Para el contexto, lee el fin de HiveMQ Cloud Serverless.

Parte 1: analiza tu carga de trabajo

Tu carga de trabajo determina qué plan necesitas y cuánto durará la migración.

Conexiones

• Pico de conexiones simultáneas en el clúster de HiveMQ (consulta la consola durante tu hora de más actividad).
• Crecimiento previsto en los próximos 12 a 18 meses.
• Número de conexiones que son aplicaciones o dashboards y no dispositivos.
• Clientes que abren varias conexiones (por ejemplo, un gateway por planta o un backend con workers).

Mensajes

• Tasa de mensajes media y de pico.
• Tamaño del payload más grande, incluidos formatos binarios como Sparkplug B.
• Niveles de QoS en uso; anota cualquier flujo QoS 2.
• Topics que usan el flag retain y si el estado retenido importa durante el arranque.
• Clientes que usan sesiones persistentes y esperan mensajes en cola mientras están desconectados.

Topología

• Lista completa de prefijos de topic y quién publica o se suscribe a cada uno.
• Suscripciones con comodines que usan los backends.
• Suscripciones compartidas usadas para balanceo de carga.
• Partners o clientes que se conectan a tu clúster.

Cómo dimensionar el nuevo plan

Dimensiona siempre según el pico más un margen. Un plan que encaja con la media rechazará conexiones durante la avalancha de reconexiones que sigue a una caída de red.

Parte 2: planifica tus nuevas credenciales

La URL y las credenciales de tu clúster de HiveMQ no se pueden trasladar, así que cada cliente recibe unas nuevas. Planifica el esquema una sola vez en lugar de improvisar dispositivo por dispositivo.

• Enumera cada credencial de HiveMQ y qué la usa.
• Asigna credenciales a brokers. En ConnectMQ, cada broker emite un usuario, una contraseña y un client ID. Agrupa en un mismo broker los clientes que pertenecen a la misma frontera de confianza.
• Diseña los client IDs. ConnectMQ vincula el client ID a las credenciales; los clientes pueden usar el ID emitido o añadir un sufijo, como YOUR_CLIENT_ID_line1-plc. Deriva los sufijos de un identificador de hardware único para que dos dispositivos nunca colisionen. Consulta las buenas prácticas para el client ID de MQTT.
• Separa las fronteras de confianza. Si usabas los permisos de topic de HiveMQ para aislar entre sí a clientes o partners, dale a cada uno su propio broker en lugar de una credencial compartida.
• Guarda los secretos correctamente. Mantén las credenciales en un gestor de secretos y, en los dispositivos, en almacenamiento protegido; nunca en el control de versiones. Consulta cómo proteger las credenciales MQTT en los dispositivos.
• Planifica la rotación. Decide cómo rotarás las credenciales más adelante sin otra migración. Consulta rotar credenciales MQTT.
• Haz configurables los endpoints. Hostname, puerto, credenciales y client ID deberían poder cambiarse en remoto, para que esta sea la última vez que necesitas cambiar el firmware por un cambio de broker.

Parte 3: prueba un broker gestionado privado

Nunca dejes que el primer dispositivo de producción sea la primera prueba. Crea un broker privado, por ejemplo uno gratuito en app.connectmq.com, y completa estas pruebas.

Conectividad

• Conéctate por TLS en el puerto 8883 desde cada tipo de red que usan tus dispositivos.
• Conéctate por WebSocket seguro en el puerto 8084 (ruta /mqtt) desde tu dashboard web.
• Confirma que los dispositivos confían en el certificado del broker. ConnectMQ usa Let's Encrypt; la raíz ISRG Root X1 debe estar en el almacén de confianza. Consulta la configuración de TLS en MQTT.

Comportamiento

• Publica y suscríbete con tu estructura de topics y tus payloads reales.
• Prueba cada nivel de QoS que uses.
• Publica un mensaje retenido y confirma que un nuevo suscriptor lo recibe.
• Configura un mensaje Last Will y mata el cliente para confirmar que se entrega.
• Reconéctate con una sesión persistente y confirma que llegan los mensajes en cola.
• Envía tu payload más grande.

Rendimiento y límites

• Mide la latencia de ida y vuelta desde las ubicaciones de los dispositivos, no solo desde la oficina.
• Reconecta a la vez un lote de clientes de prueba para simular la recuperación tras una caída.
• Confirma cómo se comportan tus clientes cuando se alcanza un límite; los clientes MQTT 5 reciben el reason code 0x97 cuando se supera la cuota.
• Sigue la prueba en el explorador de topics en vivo y en el dashboard.

Una prueba rápida de latencia con MQTT.js:

// npm install mqtt
const mqtt = require("mqtt");
const topic = "migration-test/rtt";
const client = mqtt.connect("mqtts://broker.connectmq.com:8883", {
  username: process.env.MQTT_USERNAME,
  password: process.env.MQTT_PASSWORD,
  clientId: `${process.env.MQTT_CLIENT_ID}_rtt`,
  protocolVersion: 5,
});

let sentAt = 0, n = 0;
client.on("connect", () => client.subscribe(topic, { qos: 1 }, send));
function send() { sentAt = Date.now(); client.publish(topic, String(n), { qos: 1 }); }
client.on("message", () => {
  console.log(`round trip ${n}: ${Date.now() - sentAt} ms`);
  if (++n < 20) setTimeout(send, 250); else client.end();
});

Parte 4: decisión de seguir o no antes de la primera oleada

• Inventario completo y responsables identificados para cada tipo de cliente.
• Plan elegido y dimensionado según el pico más un margen.
• Esquema de credenciales y client IDs documentado.
• Todas las pruebas de la Parte 3 superadas.
• Estado retenido exportado o republicado por los clientes al conectarse. Consulta el borrado de datos de HiveMQ Serverless.
• Relay para el funcionamiento en paralelo probado. Consulta la migración desde HiveMQ sin interrupciones.
• Plan de marcha atrás: cómo vuelve una oleada a HiveMQ si algo falla, mientras el clúster antiguo sigue funcionando.
• Fecha objetivo para la última oleada, varias semanas antes del 31 de diciembre de 2026.

Cuando tengas todas las casillas marcadas, sigue la guía de migración de HiveMQ Serverless para el cambio en sí.

Preguntas frecuentes

¿Cómo encuentro mi pico de conexiones en HiveMQ Serverless?

Consulta la información de conexiones en la consola de HiveMQ Cloud durante tu periodo de más actividad y contrástala con tu propio inventario de dispositivos. En caso de duda, dimensiona el nuevo plan con generosidad.

¿Necesito una credencial por dispositivo?

No necesariamente. En ConnectMQ, muchos dispositivos pueden compartir un conjunto de credenciales usando sufijos de client ID únicos. Usa brokers o credenciales separados cuando los dispositivos o usuarios pertenezcan a fronteras de confianza distintas.

¿Puedo probar ConnectMQ antes de pagar?

Sí. El plan Serverless (Free) no requiere tarjeta de crédito y admite hasta 25 conexiones, suficiente para ejecutar todas las pruebas de este checklist.

¿Y si falla una prueba?

Corrígela antes de mover clientes de producción. La mayoría de los fallos se deben a almacenes de confianza TLS, reglas de client ID o límites del plan, y los tres son más fáciles de corregir mientras el clúster antiguo sigue funcionando.