O HiveMQ Cloud Serverless deixa de aceitar conexões de clientes depois de 31 de dezembro de 2026, e em seguida o HiveMQ exclui permanentemente os clusters e seus dados. Um prazo tão próximo deixa pouco espaço para surpresas, por isso os melhores planos de migração partem dele de trás para a frente e terminam com antecedência. Este cronograma divide uma migração típica em marcos semanais, com uma versão condensada para equipes que estão começando tarde.
Para o contexto completo, veja fim do HiveMQ Cloud Serverless.
Planeje de trás para a frente a partir do prazo
Três datas importam mais do que o próprio 31 de dezembro:
| Marco | Meta | Por quê |
|---|---|---|
| Última onda de dispositivos concluída | Meados de dezembro de 2026, no máximo | Deixa tempo para retardatários e rollback enquanto o HiveMQ ainda funciona |
| Congelamento de fim de ano | Fim de dezembro | Muitas equipes e parceiros estão indisponíveis; evite mudanças arriscadas |
| Fim de vida do HiveMQ | 31 de dezembro de 2026 | Os clientes não conseguem mais se conectar |
Na prática, planeje como se o seu prazo real fosse meados de dezembro. Qualquer atraso ainda terá margem de segurança.
O plano padrão de seis semanas
Semana 1: Inventário e decisão
- Monte um inventário completo de clientes: dispositivos, gateways, aplicações, dashboards e parceiros. Use o checklist de migração do HiveMQ.
- Meça o pico de conexões, a taxa de mensagens, o tamanho dos payloads e os níveis de QoS.
- Decida o destino: um broker serverless, um broker gerenciado dedicado ou um autogerenciado. A comparação em Licença de migração do HiveMQ vs broker MQTT gerenciado ajuda.
- Crie um broker de teste gratuito em app.connectmq.com no mesmo dia.
Semana 2: Credenciais e testes
- Projete o esquema de credenciais e client IDs e separe as fronteiras de confiança.
- Teste conectividade, TLS, QoS, retained messages, Last Will e latência a partir dos locais reais dos dispositivos.
- Exporte as retained messages e documente credenciais e permissões. Veja exclusão de dados do HiveMQ Serverless.
- Contrate o plano de produção: Serverless (Paid) ou um broker MQTT gerenciado na nuvem da ConnectMQ (Dedicated).
Semana 3: Firmware, configuração e relay
- Prepare o novo firmware ou a nova configuração para cada tipo de cliente. Os exemplos estão em Reconfigurar clientes MQTT depois do HiveMQ.
- Torne hostnames e credenciais configuráveis remotamente para o futuro.
- Implante e teste o relay entre os dois brokers. Veja migração do HiveMQ sem interrupção.
Semana 4: Consumidores e piloto
- Mova os consumidores de backend, os fluxos do Node-RED e os dashboards para o novo broker.
- Mova um grupo piloto de dispositivos de sites e versões de firmware diferentes.
- Observe desconexões, mudanças de latência e topics ausentes por vários dias.
Semana 5: Ondas de dispositivos
- Mova os demais dispositivos em lotes, por site ou linha de produto.
- Depois de cada lote, compare o número de conexões com o seu inventário e confira o explorador de topics.
- Mova os produtores de comandos quando os dispositivos deles já tiverem migrado.
Semana 6: Virada e margem de segurança
- Confirme que nenhum cliente além do relay continua no HiveMQ.
- Pare o relay, observe por alguns dias se aparecem retardatários e então exclua o cluster Serverless.
- Atualize a documentação, os runbooks e os cofres de segredos.
- Use o tempo restante como margem para dispositivos que se conectam raramente.
Um plano condensado de duas semanas para quem começa tarde
Se você está começando em dezembro, concentre-se no que mantém o negócio funcionando:
| Dias | Foco |
|---|---|
| 1 a 2 | Inventário apenas dos clientes críticos; crie o broker; teste o TLS e um cliente real |
| 3 a 4 | Mova os consumidores de backend e os dashboards; inicie o relay |
| 5 a 8 | Mova os dispositivos que podem ser reconfigurados remotamente, em lotes rápidos |
| 9 a 11 | Trate os dispositivos que precisam de firmware ou de visitas em campo, começando pelos mais importantes |
| 12 a 14 | Virada, exporte o que restar, documente tudo o que não pôde ser migrado |
Priorize pelo impacto no negócio. Os dispositivos que não puderem ser atualizados a tempo devem ao menos ser documentados, para que você saiba exatamente o que para em 1º de janeiro de 2027 e possa agendar uma visita técnica.
O que costuma causar atrasos
- Dispositivos com configurações fixas no código, que exigem build de firmware, testes e rollout via OTA.
- Clientes desconhecidos, descobertos apenas quando param de receber dados.
- Trust stores de TLS em dispositivos mais antigos que não têm o certificado raiz do novo broker.
- Aprovações: revisões de segurança, comitês de mudança e coordenação com parceiros.
- Dispositivos que se conectam raramente, que só se comunicam uma vez por dia ou por semana e, por isso, são atualizados devagar.
Cada um desses pontos é administrável com tempo, e por isso começar cedo é a melhor forma de reduzir o risco.
Comece agora
O primeiro passo útil leva minutos: crie um broker Serverless gratuito da ConnectMQ em app.connectmq.com, aponte um cliente real para ele e confirme que os seus topics e payloads funcionam sem alterações. Depois, siga o guia de migração do HiveMQ Serverless e use este cronograma como o seu calendário.
Perguntas frequentes
Qual é o prazo do HiveMQ Cloud Serverless?
O HiveMQ descontinua o Serverless Free e o Pay As You Go em 31 de dezembro de 2026. Depois dessa data, os clientes MQTT não conseguem mais se conectar aos clusters Serverless, e o HiveMQ os exclui permanentemente.
Com quanta antecedência devo começar a migração?
O quanto antes. Uma migração típica com dispositivos em campo leva cerca de seis semanas, incluindo testes e ondas escalonadas, e o ideal é terminar até meados de dezembro para manter uma margem de segurança.
Posso conseguir uma prorrogação com o HiveMQ?
Consulte o HiveMQ diretamente. A documentação deles recomenda migrar os clientes antes da data de fim de vida para evitar interrupções no serviço, então planeje como se não houvesse prorrogação.
E se alguns dispositivos não puderem ser migrados a tempo?
Documente-os, priorize pelo impacto e planeje visitas técnicas ou substituições. Dispositivos que não conseguirem alcançar nenhum broker depois de 31 de dezembro de 2026 vão continuar tentando até serem reconfigurados.
