Google Cloud IoT Core Alternative: Options and Migration After the Shutdown

If you are searching for a Google Cloud IoT Core alternative, you are either migrating a fleet that was stranded by the shutdown or designing a new project on Google Cloud without a native device gateway. This guide explains what IoT Core did, compares the realistic replacement options fairly, maps IoT Core concepts to standard MQTT, and walks through moving devices to a managed MQTT broker while your data keeps flowing into Google Cloud services.

What Happened to Google Cloud IoT Core

Google announced in 2022 that Cloud IoT Core would be discontinued, and the service was retired on August 16, 2023. After that date devices could no longer connect to its MQTT and HTTP bridges. Google did not launch a direct successor; instead it pointed customers towards partner solutions and towards building on general Google Cloud services. Other Google Cloud products, such as Pub/Sub, Dataflow and BigQuery, were unaffected and remain common destinations for IoT data.

IoT Core combined three functions, and each needs a replacement:

1. Device connectivity: an MQTT endpoint at mqtt.googleapis.com on port 8883 (and 443).
2. Device registry and authentication: devices identified by long client IDs of the form projects/PROJECT/locations/REGION/registries/REGISTRY/devices/DEVICE, authenticated with a JWT signed by a per-device private key and sent as the MQTT password.
3. Data routing: telemetry published to /devices/DEVICE_ID/events was forwarded to Pub/Sub topics; configuration and commands came down on /devices/DEVICE_ID/config and /devices/DEVICE_ID/commands/#, and device state went up on /devices/DEVICE_ID/state.

Google Cloud IoT Core Alternative Options Compared

There is no single right answer. The best replacement depends on how deeply you used IoT Core features and where you want your data to live.

Each option is legitimate. Hyperscaler IoT services offer rich rule engines and integration; partner platforms can reduce firmware changes; self-hosting gives maximum control. A managed MQTT broker sits in the middle: standard protocol, minimal lock-in and no servers to run, at the cost of building your own forwarding into Google Cloud. For a broader comparison of hyperscaler services, see our AWS IoT Core alternative guide.

Mapping IoT Core Concepts to Plain MQTT

Moving to a standard broker is mostly a translation exercise:

The topic layout is now yours to design. Drop the leading slash IoT Core used, since it adds an empty first level, and consider an ISA-95 style hierarchy if you work in manufacturing.

Step by Step: Move Devices to a Managed MQTT Broker

1. Prepare the Broker

Sign up at app.connectmq.com, choose a plan sized to your peak connections, create a broker and issue credentials. The free Serverless plan (up to 25 connections, QoS up to 1) is enough to validate firmware and the forwarding service; Serverless Paid supports up to 1,000 connections and QoS 2.

2. Update Device Firmware

Replace the JWT generation and the IoT Core client ID with the issued username, password and client ID, change the host and update topic names. Keep TLS on port 8883; ConnectMQ uses a Let's Encrypt certificate, so your trust store must include the ISRG Root X1 certificate instead of Google's roots. Remove the JWT refresh logic, which often caused reconnect bugs on IoT Core devices. If your devices are ESP32-based, the ESP32 MQTT tutorial shows a complete TLS client.

3. Forward Telemetry to Pub/Sub

ConnectMQ does not include cloud data bridges, so data reaches Pub/Sub through a small forwarding service that connects as an ordinary MQTT client. Run it on Cloud Run, GKE or a VM with a service account allowed to publish to the topic. Install with pip install "paho-mqtt>=2.0" google-cloud-pubsub.

import os
import ssl

import paho.mqtt.client as mqtt
from google.cloud import pubsub_v1

PROJECT = os.environ["GCP_PROJECT"]
PUBSUB_TOPIC = os.environ.get("PUBSUB_TOPIC", "device-telemetry")
MQTT_FILTER = os.environ.get("MQTT_FILTER", "fleet/+/+/telemetry")

publisher = pubsub_v1.PublisherClient()
topic_path = publisher.topic_path(PROJECT, PUBSUB_TOPIC)


def on_connect(client, userdata, flags, reason_code, properties):
    print("Connected:", reason_code)
    client.subscribe(MQTT_FILTER, qos=1)


def on_message(client, userdata, msg):
    device_id = msg.topic.split("/")[2]
    future = publisher.publish(
        topic_path,
        msg.payload,
        mqtt_topic=msg.topic,
        device_id=device_id,
    )
    future.add_done_callback(
        lambda f: f.exception() and print("Pub/Sub publish failed:", f.exception())
    )


client = mqtt.Client(
    mqtt.CallbackAPIVersion.VERSION2,
    client_id=os.environ["MQTT_CLIENT_ID"],
    protocol=mqtt.MQTTv5,
)
client.username_pw_set(os.environ["MQTT_USERNAME"], os.environ["MQTT_PASSWORD"])
client.tls_set(cert_reqs=ssl.CERT_REQUIRED)
client.on_connect = on_connect
client.on_message = on_message
client.reconnect_delay_set(min_delay=1, max_delay=60)
client.connect("broker.connectmq.com", 8883, keepalive=60)
client.loop_forever()

Set MQTT_USERNAME, MQTT_PASSWORD and MQTT_CLIENT_ID to the values from the portal (YOUR_USERNAME, YOUR_PASSWORD, YOUR_CLIENT_ID), ideally from Secret Manager. Attributes such as device_id let downstream subscribers and Dataflow jobs filter without parsing payloads, much as IoT Core added device attributes. The official Pub/Sub client library documentation covers batching and flow control for high volumes. To scale out, run several instances with an MQTT 5 shared subscription such as $share/forwarders/fleet/+/+/telemetry, available on Serverless Paid and above.

4. Replace Configuration and Commands

IoT Core's config messages map naturally to retained MQTT messages: publish each device's configuration retained to its config topic, and the device receives it on every connect. Commands map to a QoS 1 command topic. Make commands idempotent with a unique ID and an expiry, as described in our guide to surviving an MQTT broker outage.

5. Roll Out in Waves

Move a pilot group first, watch connection state on $SYS/broker/connection/{clientId}/state and in the portal's topic explorer, then migrate the rest by region or product line. If some devices cannot be updated quickly, a local gateway can translate their old topics and republish to the new hierarchy.

Checklist Before You Switch

1. Inventory of devices, firmware versions and IoT Core features in use.
2. New topic hierarchy designed and documented.
3. Broker plan sized for peak connections, QoS and message size.
4. Credentials issued per device and stored securely.
5. Firmware updated for new host, trust store, credentials and topics.
6. Forwarding service running and verified in Pub/Sub.
7. Config and command flows tested end to end.
8. Rollout plan with pilot group and rollback steps.

If part of your fleet already runs on a local broker, the guide to migrate Mosquitto to cloud MQTT covers bridging and wave-based cutover in more detail.

Move Your Fleet to ConnectMQ

Create a free broker at app.connectmq.com on the Serverless plan, no credit card required, and validate your firmware and forwarding service before migrating the fleet. ConnectMQ is a fully managed MQTT service with standard MQTT 3.1.1 and 5.0, TLS, WebSockets and a portal with a live topic explorer. Read the cloud MQTT broker guide for deployment options, or try the free public MQTT broker for a first test.

Frequently Asked Questions

When did Google Cloud IoT Core shut down?

Google retired Cloud IoT Core on August 16, 2023, after announcing the discontinuation in 2022. Devices can no longer connect to its endpoints.

Can I keep using Pub/Sub and BigQuery after moving to another broker?

Yes. Those services were not affected. A small subscriber service forwards MQTT messages from the broker into Pub/Sub, and existing pipelines continue from there.

Do I need JWT authentication on a new MQTT broker?

Not necessarily. Most managed brokers, including ConnectMQ, use per-device username and password over TLS, which removes JWT refresh logic from firmware.

What is the closest replacement for IoT Core device configuration?

Retained MQTT messages. Publish each device's configuration retained to its own config topic, and the device receives the latest version every time it connects.