HiveMQ retires Cloud Serverless Free and Serverless PAYG on December 31, 2026. New Serverless clusters are already unavailable. Existing cluster hostnames cannot transfer; clients, retained messages, sessions, credentials, and permissions do not move automatically. After retirement, HiveMQ permanently deletes the clusters and data. This notice does not cover every HiveMQ service. Details were checked on October 20, 2026 against the official notice.
Use the alternative overview to decide whether RunMQTT fits. HiveMQ also offers eligible customers a free self-managed Migration license: that option requires you to operate your own broker. RunMQTT is independent of HiveMQ.
1. Inventory and choose a plan
Record peak device and backend connections, average and burst publish rates, payload sizes, fan-out, subscriptions per client, retained topics, persistent sessions, queued work, integrations, TLS trust, and the way each deployed device receives a new endpoint. Identify offline devices and firmware with hard-coded hostnames before setting a cutover date.
Use the capacity calculator and billing guide. Each publish and subscriber delivery counts in rounded-up 512-byte units. Twenty always-connected devices publishing once per minute to one subscriber consume about 1,728,000 message units over 30 days when payloads are at most 512 bytes. That exceeds Starter's 1,000,000-unit allowance even though the connection count fits.
Starter includes QoS 0/1. Retained messages and QoS 2 require Growth or Scale. Check actual packet, rate, subscription, session, regional and SLA requirements with support; monthly quotas are not a guarantee of these limits. A trial requires a payment method and renews at the selected price unless canceled before its displayed end.
2. Recreate access and connection settings
Create a private Broker, wait for activation, then create policy templates and device identities. Follow devices and topic policies. Keep a private copy of the topic/permission inventory, without putting passwords in tickets or public repositories.
| Setting | Target RunMQTT value |
|---|---|
| TLS hostname | Copy the Broker's secure hostname, such as <broker>.tls-broker.runmqtt.com |
| Native TLS port | 8883 |
| Browser URL | wss://<broker>.tls-broker.runmqtt.com/mqtt |
| Username | Generated <broker-id>/<device-name>; copy it exactly |
| Password | The generated device secret; replace the HiveMQ password |
| Client ID | Unique for every simultaneous connection; stable for a persistent session |
| Trust | Keep certificate and hostname verification enabled; update pinned trust when required |
Preserve topic names and payload contracts where possible. Test an allowed publish/subscribe and a denied out-of-scope operation with synthetic data. The template name and Client ID do not automatically scope topics. Use the ACL linter for local review and real clients for enforcement checks.
Use the secure RunMQTT hostname. Adding your own CNAME alone does not make a custom-domain endpoint with a valid certificate. Keep endpoint settings updateable so another future move does not require replacing firmware everywhere.
3. Run a local client check
The public verification script uses MQTT.js. It opens temporary clean-session clients, publishes unique synthetic messages under a test prefix, verifies actual receipt, and optionally checks retained replay and its packet flag. It sends messages only to the target broker you configure, may incur usage charges, and does not copy source data or migrate credentials.
Create an isolated local directory with Node >=22.12, install mqtt@5.15.2, and download the script for review:
mkdir mqtt-migration-check
cd mqtt-migration-check
npm init -y
npm install mqtt@5.15.2
curl -fsSLo verify.mjs https://runmqtt.com/examples/hivemq-migration/verify.mjs
node verify.mjs --help
Create a local migration.env file, keep it out of version control, and restrict access to it. Replace the placeholders with a dedicated test device's settings. Grant publish and subscribe only on migration-check/# for that identity:
MQTT_URL=mqtts://YOUR_BROKER.tls-broker.runmqtt.com:8883
MQTT_USERNAME=YOUR_BROKER/YOUR_TEST_DEVICE
MQTT_PASSWORD=YOUR_TEST_SECRET
MQTT_TEST_PREFIX=migration-check
MQTT_VERSION=5
MQTT_CHECK_RETAINED=0
node --env-file=migration.env verify.mjs
Require connected, roundtrip, cleanup, and passed to be true. Repeat with MQTT_VERSION=4 for MQTT 3.1.1 and the full WSS URL for browser transport. Set MQTT_CHECK_RETAINED=1 only on a plan with retained support. For retained checks, both observed and retainFlag must be true; payload replay alone is not a pass. A timeout or cleanup=false means you must inspect the test namespace and remove retained test state before accepting the run. Remove the local credential file and revoke the temporary device after testing.
Managed checks on October 20, 2026 did not pass retained conformance: the original observation included retain=false, and stricter replay checks did not receive the expected saved value. Treat this as an unresolved compatibility limitation. See sessions and delivery. Validate your exact client and plan before moving retained-dependent applications.
4. Plan state and backend recovery
- Recreate subscriptions on the new broker. Reusing a Client ID does not transfer the old session.
- Existing offline queues and in-flight QoS exchanges do not move. Drain required work while the old service is available or recover from your application's durable event source.
- Republish current retained state deliberately with the retain flag. Preserve versions or timestamps, clear obsolete values, and distinguish state from commands. Do not replay one-time commands as retained state.
- If you snapshot retained messages from the old broker, use only topics you are authorized to read. A wildcard snapshot is not an atomic export and cannot prove that every retained topic was captured. Validate the topic inventory and coordinate updates during cutover.
- Coordinate backend subscribers and command publishers across both environments. Dual delivery can create duplicate business actions; use application event IDs, deduplication, and an explicit command-routing plan.
5. Switch, verify, and close out
Move a small representative batch first, including a constrained device and a backend consumer. Check normal and burst traffic, reconnects, session expiry, LWT, permission failures, application-level acknowledgements and usage. Repeat after restarting the application and network connection. Increase the batch only after the acceptance criteria pass.
Maintain an explicit rollback window while the source is still available. Stop expansion if the acceptance checks fail; coordinate credentials, backend routing, and current state when switching back. Do not delete the source cluster until required devices and applications have been accepted. HiveMQ cannot recreate a deleted Serverless cluster.
Download the cutover checklist. For ESP32 or Node-RED, use the client guide; for Home Assistant use the discovery and restart guide.
For an assessment, contact RunMQTT with approximate connections, publish rate, payload size, required features, client versions, integrations and target date. Never include passwords or customer payloads. Agree assistance scope and contractual requirements before cutover.