Checklist de Migração do HiveMQ: Avalie a Carga, Planeje Credenciais e Teste um Broker Privado

Sair do HiveMQ Cloud Serverless corre bem quando três coisas são feitas antes de mexer em qualquer dispositivo: você conhece a sua carga de trabalho, planejou as novas credenciais e testou um broker privado com o seu tráfego real. Este checklist transforma esses três passos em itens concretos que você pode ir marcando. Ele funciona com qualquer broker de destino; quando ajuda, mostramos como cada item se aplica à ConnectMQ.

O HiveMQ descontinua o Serverless em 31 de dezembro de 2026. Para o contexto, leia fim do HiveMQ Cloud Serverless.

Parte 1: Avalie a sua carga de trabalho

A sua carga de trabalho determina qual plano você precisa e quanto tempo a migração vai levar.

Conexões

• Pico de conexões simultâneas no cluster HiveMQ (confira no console durante o seu horário de maior movimento).
• Crescimento esperado nos próximos 12 a 18 meses.
• Número de conexões que são aplicações ou dashboards, e não dispositivos.
• Clientes que abrem várias conexões (por exemplo, um gateway por site ou um backend com workers).

Mensagens

• Taxa média e taxa de pico de mensagens.
• Maior tamanho de payload, incluindo formatos binários como Sparkplug B.
• Níveis de QoS em uso; anote qualquer fluxo com QoS 2.
• Topics que usam a flag retain e se o estado retido importa na inicialização.
• Clientes que usam sessões persistentes e esperam mensagens enfileiradas enquanto estão offline.

Topologia

• Lista completa de prefixos de topics e quem publica ou assina cada um.
• Assinaturas com wildcards usadas pelos backends.
• Shared subscriptions usadas para balanceamento de carga.
• Parceiros ou clientes que se conectam ao seu cluster.

Como dimensionar o novo plano

Dimensione sempre pelo pico, com folga. Um plano que atende à média vai recusar conexões durante a tempestade de reconexões após uma queda de rede.

Parte 2: Planeje as novas credenciais

A URL e as credenciais do seu cluster HiveMQ não podem ser transferidas, então cada cliente recebe novas. Planeje o esquema uma única vez, em vez de improvisar dispositivo por dispositivo.

• Liste todas as credenciais do HiveMQ e o que usa cada uma.
• Associe credenciais a brokers. Na ConnectMQ, cada broker emite um usuário, uma senha e um client ID. Agrupe em um mesmo broker os clientes que pertencem à mesma fronteira de confiança.
• Projete os client IDs. A ConnectMQ vincula o client ID às credenciais; os clientes podem usar o ID emitido ou acrescentar um sufixo, como YOUR_CLIENT_ID_line1-plc. Derive os sufixos de um identificador de hardware único para que dois dispositivos nunca colidam. Veja boas práticas de client ID MQTT.
• Separe as fronteiras de confiança. Se você usava permissões de topic do HiveMQ para isolar clientes ou parceiros entre si, dê a cada um o seu próprio broker, em vez de uma credencial compartilhada.
• Guarde os segredos corretamente. Mantenha as credenciais em um gerenciador de segredos e, nos dispositivos, em armazenamento protegido, nunca no controle de versão. Veja como proteger credenciais MQTT nos dispositivos.
• Planeje a rotação. Defina como você vai rotacionar as credenciais no futuro sem outra migração. Veja rotacionar credenciais MQTT.
• Torne os endpoints configuráveis. Hostname, porta, credenciais e client ID devem poder ser alterados remotamente, para que esta seja a última vez que você precisa mudar o firmware por causa de uma troca de broker.

Parte 3: Teste um broker gerenciado privado

Nunca deixe que o primeiro dispositivo de produção seja o primeiro teste. Crie um broker privado, por exemplo um gratuito em app.connectmq.com, e execute estes testes.

Conectividade

• Conecte via TLS na porta 8883 a partir de cada tipo de rede que os seus dispositivos usam.
• Conecte via WebSocket seguro na porta 8084 (caminho /mqtt) a partir do seu dashboard web.
• Confirme que os dispositivos confiam no certificado do broker. A ConnectMQ usa Let's Encrypt; a raiz ISRG Root X1 precisa estar no trust store. Veja configuração de TLS no MQTT.

Comportamento

• Publique e assine com a sua estrutura real de topics e payloads.
• Teste cada nível de QoS que você usa.
• Publique uma retained message e confirme que um novo assinante a recebe.
• Defina uma mensagem Last Will e derrube o cliente para confirmar que ela é entregue.
• Reconecte com uma sessão persistente e confirme que as mensagens enfileiradas chegam.
• Envie o seu maior payload.

Desempenho e limites

• Meça a latência de ida e volta a partir dos locais dos dispositivos, e não só do escritório.
• Reconecte um lote de clientes de teste ao mesmo tempo para simular a recuperação após uma queda.
• Confirme como os seus clientes se comportam quando um limite é atingido; clientes MQTT 5 recebem o reason code 0x97 para cota excedida.
• Acompanhe o teste no explorador de topics ao vivo e no dashboard.

Um teste rápido de latência com 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: Go / no-go antes da primeira onda

• Inventário completo e responsáveis definidos para cada tipo de cliente.
• Plano escolhido e dimensionado pelo pico, com folga.
• Esquema de credenciais e client IDs documentado.
• Todos os testes da Parte 3 aprovados.
• Estado retido exportado ou republicado pelos clientes ao conectar. Veja exclusão de dados do HiveMQ Serverless.
• Relay para operação paralela testado. Veja migração do HiveMQ sem interrupção.
• Plano de rollback: como uma onda volta para o HiveMQ se algo falhar, enquanto o cluster antigo ainda funciona.
• Data-alvo para a última onda, várias semanas antes de 31 de dezembro de 2026.

Com todos os itens marcados, siga o guia de migração do HiveMQ Serverless para a migração em si.

Perguntas frequentes

Como descubro o meu pico de conexões no HiveMQ Serverless?

Confira as informações de conexão no console do HiveMQ Cloud durante o seu período de maior movimento e compare com o seu próprio inventário de dispositivos. Na dúvida, dimensione o novo plano com generosidade.

Preciso de uma credencial por dispositivo?

Não necessariamente. Na ConnectMQ, muitos dispositivos podem compartilhar um conjunto de credenciais usando sufixos de client ID únicos. Use brokers ou credenciais separados quando dispositivos ou usuários pertencerem a fronteiras de confiança diferentes.

Posso testar a ConnectMQ antes de pagar?

Sim. O plano Serverless (Free) não exige cartão de crédito e suporta até 25 conexões, o suficiente para executar todos os testes deste checklist.

E se um teste falhar?

Corrija antes de mover os clientes de produção. A maioria das falhas envolve trust stores de TLS, regras de client ID ou limites do plano, e as três são mais fáceis de corrigir enquanto o cluster antigo ainda funciona.