HiveMQ Cloud Serverless deja de aceptar conexiones de clientes después del 31 de diciembre de 2026, y después HiveMQ elimina de forma permanente los clústeres y sus datos. Una fecha límite tan cercana deja poco margen para sorpresas, así que los mejores planes de migración se construyen hacia atrás desde ella y terminan antes. Este calendario divide una migración típica en hitos semanales e incluye una versión comprimida para los equipos que empiezan tarde.
Para el contexto completo, consulta el fin de HiveMQ Cloud Serverless.
Planifica hacia atrás desde la fecha límite
Hay tres fechas que importan más que el propio 31 de diciembre:
| Hito | Objetivo | Por qué |
|---|---|---|
| Última oleada de dispositivos completada | Mediados de diciembre de 2026 como muy tarde | Deja tiempo para rezagados y para dar marcha atrás mientras HiveMQ sigue funcionando |
| Congelación por vacaciones | Finales de diciembre | Muchos equipos y partners no están disponibles; evita cambios arriesgados |
| Fin de vida de HiveMQ | 31 de diciembre de 2026 | Los clientes ya no pueden conectarse |
En la práctica, planifica como si tu fecha límite real fuera mediados de diciembre. Cualquier cosa que se retrase seguirá teniendo un margen de seguridad.
El plan estándar de seis semanas
Semana 1: inventario y decisión
- Elabora un inventario completo de clientes: dispositivos, gateways, aplicaciones, dashboards y partners. Usa el checklist de migración desde HiveMQ.
- Mide el pico de conexiones, la tasa de mensajes, los tamaños de payload y los niveles de QoS.
- Decide el destino: un broker serverless, un broker gestionado dedicado o uno autogestionado. La comparación en Licencia de migración de HiveMQ frente a un broker MQTT gestionado te ayuda.
- Crea ese mismo día un broker de prueba gratuito en app.connectmq.com.
Semana 2: credenciales y pruebas
- Diseña el esquema de credenciales y client IDs, y separa las fronteras de confianza.
- Prueba la conectividad, TLS, QoS, los mensajes retenidos, Last Will y la latencia desde las ubicaciones reales de los dispositivos.
- Exporta los mensajes retenidos y documenta credenciales y permisos. Consulta el borrado de datos de HiveMQ Serverless.
- Contrata el plan de producción: Serverless (Paid) o un broker MQTT gestionado en la nube de ConnectMQ dedicado.
Semana 3: firmware, configuración y relay
- Prepara el nuevo firmware o la nueva configuración para cada tipo de cliente. Hay ejemplos en Reconfigurar clientes MQTT después de HiveMQ.
- Haz que los hostnames y las credenciales sean configurables en remoto de cara al futuro.
- Despliega y prueba el relay entre ambos brokers. Consulta la migración desde HiveMQ sin interrupciones.
Semana 4: consumidores y piloto
- Mueve al nuevo broker los consumidores backend, los flujos de Node-RED y los dashboards.
- Mueve un grupo piloto de dispositivos de distintas ubicaciones y versiones de firmware.
- Vigila durante varios días las desconexiones, los cambios de latencia y los topics que falten.
Semana 5: oleadas de dispositivos
- Mueve el resto de dispositivos por lotes, por ubicación o línea de producto.
- Después de cada lote, compara el número de conexiones con tu inventario y revisa el explorador de topics.
- Mueve los productores de comandos cuando sus dispositivos ya se hayan movido.
Semana 6: cambio final y margen
- Confirma que en HiveMQ no queda ningún cliente salvo el relay.
- Detén el relay, vigila durante unos días por si aparecen rezagados y después elimina el clúster Serverless.
- Actualiza la documentación, los runbooks y los almacenes de secretos.
- Usa el tiempo restante como margen para los dispositivos que se conectan rara vez.
Un plan comprimido de dos semanas para quienes empiezan tarde
Si empiezas en diciembre, céntrate en lo que mantiene el negocio en marcha:
| Días | Enfoque |
|---|---|
| 1 a 2 | Inventario solo de los clientes críticos; crea el broker; prueba TLS y un cliente real |
| 3 a 4 | Mueve los consumidores backend y los dashboards; arranca el relay |
| 5 a 8 | Mueve en lotes rápidos los dispositivos que se pueden reconfigurar en remoto |
| 9 a 11 | Ocúpate de los dispositivos que necesitan firmware o visitas in situ, empezando por los más importantes |
| 12 a 14 | Cambio final, exporta lo que quede y documenta todo lo que no se haya podido mover |
Prioriza por impacto en el negocio. Los dispositivos que no puedan actualizarse a tiempo deberían, como mínimo, quedar documentados, para que sepas exactamente qué deja de funcionar el 1 de enero de 2027 y puedas programar una visita en campo.
Qué suele provocar retrasos
- Dispositivos con ajustes escritos en el código que necesitan compilar firmware, probarlo y desplegarlo por OTA.
- Clientes desconocidos que solo se descubren cuando dejan de recibir datos.
- Almacenes de confianza TLS de dispositivos antiguos a los que les falta el certificado raíz del nuevo broker.
- Aprobaciones: revisiones de seguridad, comités de cambios y coordinación con partners.
- Dispositivos que se conectan rara vez, que solo se comunican a diario o cada semana y, por tanto, se actualizan despacio.
Todo esto es manejable con tiempo, y por eso empezar pronto es la mejor forma de reducir el riesgo.
Empieza ya
El primer paso útil lleva minutos: crea un broker Serverless gratuito de ConnectMQ en app.connectmq.com, apunta un cliente real hacia él y confirma que tus topics y payloads funcionan sin cambios. Después sigue la guía de migración de HiveMQ Serverless y usa este calendario como tu planificación.
Preguntas frecuentes
¿Cuál es la fecha límite de HiveMQ Cloud Serverless?
HiveMQ retira Serverless Free y Pay As You Go el 31 de diciembre de 2026. A partir de esa fecha los clientes MQTT ya no pueden conectarse a los clústeres Serverless, y HiveMQ los elimina de forma permanente.
¿Con cuánta antelación debería empezar a migrar?
Lo antes posible. Una migración típica con dispositivos en campo lleva unas seis semanas, incluidas las pruebas y las oleadas escalonadas, y deberías intentar terminar a mediados de diciembre para conservar un margen.
¿Puedo conseguir una prórroga de HiveMQ?
Consúltalo directamente con HiveMQ. Su documentación recomienda mover los clientes antes de la fecha de fin de vida para evitar interrupciones del servicio, así que planifica como si no hubiera prórroga.
¿Y si algunos dispositivos no se pueden migrar a tiempo?
Documéntalos, priorízalos por impacto y planifica visitas en campo o sustituciones. Los dispositivos que no puedan llegar a ningún broker después del 31 de diciembre de 2026 seguirán reintentando hasta que se reconfiguren.
