HiveMQ Cloud Serverless nimmt nach dem 31. Dezember 2026 keine Client-Verbindungen mehr an, und HiveMQ löscht danach die Cluster und ihre Daten endgültig. Eine so nahe Frist lässt wenig Raum für Überraschungen. Die besten Migrationspläne rechnen deshalb von ihr rückwärts und sind früher fertig. Dieser Zeitplan zerlegt eine typische Migration in wöchentliche Meilensteine und enthält eine verkürzte Version für Teams, die spät beginnen.
Alle Hintergründe finden Sie unter HiveMQ Cloud Serverless End of Life.
Von der Frist rückwärts planen
Drei Termine sind wichtiger als der 31. Dezember selbst:
| Meilenstein | Ziel | Warum |
|---|---|---|
| Letzte Gerätewelle abgeschlossen | Spätestens Mitte Dezember 2026 | Lässt Zeit für Nachzügler und Rollback, solange HiveMQ noch läuft |
| Feiertags-Freeze | Ende Dezember | Viele Teams und Partner sind nicht erreichbar; vermeiden Sie riskante Änderungen |
| End of Life von HiveMQ | 31. Dezember 2026 | Clients können sich nicht mehr verbinden |
Planen Sie in der Praxis so, als wäre Mitte Dezember Ihre eigentliche Frist. Was sich dann verschiebt, hat immer noch einen Sicherheitspuffer. In vielen Werken im DACH-Raum fällt das Jahresende zudem mit Betriebsferien und Wartungsfenstern zusammen – stimmen Sie Ihre Wellen frühzeitig mit Produktion und Instandhaltung ab.
Der Standardplan über sechs Wochen
Woche 1: Bestandsaufnahme und Entscheidung
- Erstellen Sie ein vollständiges Client-Inventar: Geräte, Gateways, Anwendungen, Dashboards und Partner. Nutzen Sie die HiveMQ-Migrationscheckliste.
- Messen Sie Spitzenverbindungen, Nachrichtenrate, Payload-Größen und QoS-Stufen.
- Legen Sie das Ziel fest: einen Serverless-Broker, einen dedizierten verwalteten Broker oder einen selbst betriebenen. Der Vergleich in HiveMQ Migration License vs. verwalteter MQTT-Broker hilft dabei.
- Legen Sie noch am selben Tag unter app.connectmq.com einen kostenlosen Broker zum Testen an.
Woche 2: Zugangsdaten und Tests
- Entwerfen Sie das Schema für Zugangsdaten und Client-IDs und trennen Sie Vertrauensgrenzen.
- Testen Sie Konnektivität, TLS, QoS, Retained Messages, Last Will und Latenz von echten Gerätestandorten aus.
- Exportieren Sie Retained Messages und dokumentieren Sie Zugangsdaten und Berechtigungen. Siehe Datenlöschung bei HiveMQ Serverless.
- Bestellen Sie den Produktionstarif: Serverless (Paid) oder einen dedizierten verwalteten Cloud-MQTT-Broker von ConnectMQ.
Woche 3: Firmware, Konfiguration und Relay
- Bereiten Sie neue Firmware oder Konfiguration für jeden Client-Typ vor. Beispiele finden Sie unter MQTT-Clients nach HiveMQ umstellen.
- Machen Sie Hostnamen und Zugangsdaten für die Zukunft aus der Ferne konfigurierbar.
- Richten Sie das Relay zwischen beiden Brokern ein und testen Sie es. Siehe HiveMQ-Migration ohne Ausfallzeit.
Woche 4: Consumer und Pilot
- Ziehen Sie Backend-Consumer, Node-RED-Flows und Dashboards auf den neuen Broker um.
- Ziehen Sie eine Pilotgruppe von Geräten aus verschiedenen Standorten und Firmware-Versionen um.
- Achten Sie mehrere Tage lang auf Verbindungsabbrüche, Latenzänderungen und fehlende Topics, etwa Lücken in Ihrer ISA-95-Hierarchie im Unified Namespace (UNS).
Woche 5: Gerätewellen
- Ziehen Sie die übrigen Geräte in Gruppen um, nach Standort oder Produktlinie.
- Vergleichen Sie nach jeder Gruppe die Verbindungszahl mit Ihrem Inventar und prüfen Sie den Topic-Explorer.
- Ziehen Sie Befehlsgeber um, sobald ihre Geräte umgezogen sind.
Woche 6: Umschaltung und Puffer
- Bestätigen Sie, dass außer dem Relay keine Clients mehr auf HiveMQ verbleiben.
- Stoppen Sie das Relay, achten Sie einige Tage lang auf Nachzügler und löschen Sie dann den Serverless-Cluster.
- Aktualisieren Sie Dokumentation, Runbooks und Secret Stores.
- Nutzen Sie die verbleibende Zeit als Puffer für Geräte, die sich selten verbinden.
Ein verkürzter Zwei-Wochen-Plan für Spätstarter
Wenn Sie erst im Dezember beginnen, konzentrieren Sie sich auf das, was den Betrieb am Laufen hält:
| Tage | Schwerpunkt |
|---|---|
| 1 bis 2 | Nur kritische Clients erfassen; Broker anlegen; TLS und einen echten Client testen |
| 3 bis 4 | Backend-Consumer und Dashboards umziehen; Relay starten |
| 5 bis 8 | Geräte, die sich aus der Ferne umkonfigurieren lassen, in schnellen Gruppen umziehen |
| 9 bis 11 | Geräte bearbeiten, die Firmware-Updates oder Einsätze vor Ort brauchen, beginnend mit den wichtigsten |
| 12 bis 14 | Umschaltung, Rest exportieren, alles dokumentieren, was nicht umziehen konnte |
Priorisieren Sie nach geschäftlicher Auswirkung. Geräte, die sich nicht rechtzeitig aktualisieren lassen, sollten Sie mindestens dokumentieren, damit Sie genau wissen, was am 1. Januar 2027 ausfällt, und einen Vor-Ort-Einsatz planen können.
Was typischerweise zu Verzögerungen führt
- Geräte mit fest eingetragenen Einstellungen, die einen Firmware-Build, Tests und einen OTA-Rollout brauchen.
- Unbekannte Clients, die erst auffallen, wenn sie keine Daten mehr erhalten.
- TLS-Trust-Stores auf älteren Geräten, denen das Root-Zertifikat des neuen Brokers fehlt.
- Freigaben: Sicherheitsprüfungen, Change Boards und Abstimmung mit Partnern.
- Selten verbundene Geräte, die sich nur täglich oder wöchentlich melden und daher langsam aktualisiert werden.
Jeder dieser Punkte ist mit genügend Zeit beherrschbar. Deshalb ist ein früher Start die wirksamste Maßnahme zur Risikominimierung.
Jetzt starten
Der erste sinnvolle Schritt dauert nur Minuten: Legen Sie unter app.connectmq.com einen kostenlosen Serverless-Broker von ConnectMQ an, richten Sie einen echten Client darauf aus und bestätigen Sie, dass Ihre Topics und Payloads unverändert funktionieren. Folgen Sie dann dem Migrationsleitfaden für HiveMQ Serverless und nutzen Sie diesen Zeitplan als Ihren Fahrplan.
Häufig gestellte Fragen
Was ist die Frist für HiveMQ Cloud Serverless?
HiveMQ stellt Serverless Free und Pay As You Go am 31. Dezember 2026 ein. Nach diesem Datum können sich MQTT-Clients nicht mehr mit Serverless-Clustern verbinden, und HiveMQ löscht sie endgültig.
Wie früh sollte ich mit der Migration beginnen?
So früh wie möglich. Eine typische Migration mit Feldgeräten dauert inklusive Tests und gestaffelter Wellen etwa sechs Wochen, und Sie sollten bis Mitte Dezember fertig sein, um einen Puffer zu behalten.
Kann ich bei HiveMQ eine Fristverlängerung bekommen?
Klären Sie das direkt mit HiveMQ. Die Dokumentation von HiveMQ empfiehlt, Clients vor dem End-of-Life-Datum umzuziehen, um Serviceunterbrechungen zu vermeiden. Planen Sie also so, als gäbe es keine Verlängerung.
Was, wenn sich manche Geräte nicht rechtzeitig migrieren lassen?
Dokumentieren Sie sie, priorisieren Sie nach Auswirkung und planen Sie Vor-Ort-Einsätze oder einen Austausch. Geräte, die nach dem 31. Dezember 2026 keinen Broker erreichen, versuchen es so lange weiter, bis sie umkonfiguriert sind.



