HiveMQ Cloud Serverless stops accepting client connections after December 31, 2026, and HiveMQ then permanently deletes the clusters and their data. A deadline that close leaves little room for surprises, so the best migration plans work backwards from it and finish early. This timeline breaks a typical migration into weekly milestones, with a compressed version for teams starting late.
For the full background, see HiveMQ Cloud Serverless end of life.
Work Backwards From the Deadline
Three dates matter more than December 31 itself:
| Milestone | Target | Why |
|---|---|---|
| Last device wave complete | Mid-December 2026 at the latest | Leaves time for stragglers and rollback while HiveMQ still works |
| Holiday freeze | Late December | Many teams and partners are unavailable; avoid risky changes |
| HiveMQ end of life | December 31, 2026 | Clients can no longer connect |
In practice, plan as if your real deadline is the middle of December. Anything that slips then still has a safety margin.
The Standard Six-Week Plan
Week 1: Inventory and Decision
- Build a full client inventory: devices, gateways, applications, dashboards and partners. Use the HiveMQ migration checklist.
- Measure peak connections, message rate, payload sizes and QoS levels.
- Decide the destination: a serverless broker, a dedicated managed broker or a self-managed one. The comparison in HiveMQ Migration License vs a Managed MQTT Broker helps.
- Create a free test broker at app.connectmq.com the same day.
Week 2: Credentials and Testing
- Design the credential and client ID scheme, and separate trust boundaries.
- Test connectivity, TLS, QoS, retained messages, Last Will and latency from real device locations.
- Export retained messages and document credentials and permissions. See HiveMQ Serverless data deletion.
- Order the production plan: Serverless (Paid) or a Dedicated Managed Cloud MQTT Broker.
Week 3: Firmware, Configuration and Relay
- Prepare new firmware or configuration for each client type. Examples are in Reconfigure MQTT clients after HiveMQ.
- Make hostnames and credentials remotely configurable for the future.
- Deploy and test the relay between both brokers. See zero-downtime HiveMQ migration.
Week 4: Consumers and Pilot
- Move backend consumers, Node-RED flows and dashboards to the new broker.
- Move a pilot group of devices from different sites and firmware versions.
- Watch for disconnects, latency changes and missing topics for several days.
Week 5: Device Waves
- Move the remaining devices in batches, by site or product line.
- After each batch, compare the connection count with your inventory and check the topic explorer.
- Move command producers once their devices have moved.
Week 6: Cutover and Buffer
- Confirm no clients except the relay remain on HiveMQ.
- Stop the relay, watch for stragglers for a few days, then delete the Serverless cluster.
- Update documentation, runbooks and secrets stores.
- Use the remaining time as buffer for devices that connect rarely.
A Compressed Two-Week Plan for Late Starters
If you are starting in December, focus on what keeps the business running:
| Days | Focus |
|---|---|
| 1 to 2 | Inventory of critical clients only; create the broker; test TLS and one real client |
| 3 to 4 | Move backend consumers and dashboards; start the relay |
| 5 to 8 | Move devices that can be reconfigured remotely, in quick batches |
| 9 to 11 | Handle devices that need firmware or on-site visits, starting with the most important |
| 12 to 14 | Cutover, export what is left, document anything that could not move |
Prioritise by business impact. Devices that cannot be updated in time should at least be documented, so you know exactly what stops on January 1, 2027 and can schedule a field visit.
What Usually Causes Delays
- Devices with hard-coded settings that need a firmware build, testing and OTA rollout.
- Unknown clients discovered only when they stop receiving data.
- TLS trust stores on older devices that lack the new broker's root certificate.
- Approvals: security reviews, change boards and partner coordination.
- Rarely connected devices that only check in daily or weekly and therefore update slowly.
Each of these is manageable with time, which is why starting early is the single best risk reduction.
Start Now
The first useful step takes minutes: create a free ConnectMQ Serverless broker at app.connectmq.com, point one real client at it and confirm that your topics and payloads work unchanged. Then follow the HiveMQ Serverless migration guide and keep this timeline as your schedule.
Frequently Asked Questions
What is the HiveMQ Cloud Serverless deadline?
HiveMQ retires Serverless Free and Pay As You Go on December 31, 2026. After that date MQTT clients can no longer connect to Serverless clusters, and HiveMQ permanently deletes them.
How early should I start migrating?
As soon as possible. A typical migration with field devices takes about six weeks including testing and staged waves, and you should aim to finish by mid-December to keep a buffer.
Can I get an extension from HiveMQ?
Check with HiveMQ directly. Their documentation advises moving clients before the end-of-life date to avoid service interruption, so plan as if no extension is available.
What if some devices cannot be migrated in time?
Document them, prioritise by impact and plan field visits or replacements. Devices that cannot reach any broker after December 31, 2026 will keep retrying until they are reconfigured.
