# Questions About Thin Edge MQTT Topic Structure After Migration **URL:** \ **Category:** Forum\ **Tags:** thin-edge-io, cumulocity\ **Created:** [April 14, 2025, 2:46pm UTC](https://community.cumulocity.com/t/questions-about-thin-edge-mqtt-topic-structure-after-migration/12154 "2025-04-14T14:46:50Z")\ **Posts on this page:** 4\ **Page:** 1
**Author:** ![dacsystemsw](https://avatars.discourse-cdn.com/v4/letter/d/e79b87/32.png) [@dacsystemsw](https://community.cumulocity.com/u/dacsystemsw)\ **Post date:** [April 14, 2025, 2:46pm UTC](https://community.cumulocity.com/t/questions-about-thin-edge-mqtt-topic-structure-after-migration/12154/1 "2025-04-14T14:46:50Z")
Hi, I’m Luca from DAC. We successfully migrated our system from a Java agent to Thin Edge, as documented [here](https://community.cumulocity.com/t/thin-edge-migration/10716). Previously, our sensors (child devices) sent data to Cumulocity via MQTT using topics like: `s/us/atc-poc-rf-5` After migrating to Thin Edge, I updated the topics to: `c8y/s/us/atc-poc-rf-5` This setup works, and I can see data arriving in Cumulocity. However, while reviewing the Thin Edge documentation [here](https://thin-edge.github.io/thin-edge.io/references/mqtt-api/#telemetry-data), I noticed that telemetry data should use topics in the format: `te//m/` So, while my current solution seems to work, I’m wondering if I’m using Thin Edge correctly. If not, what are the potential downsides of continuing with my topic structure? ---
**Author:** ![Tristan\_Bastian](https://dub1.discourse-cdn.com/flex005/user_avatar/community.cumulocity.com/tristan_bastian/32/18259_2.png) [@Tristan\_Bastian](https://community.cumulocity.com/u/Tristan_Bastian)\ **Post date:** [April 14, 2025, 3:46pm UTC](https://community.cumulocity.com/t/questions-about-thin-edge-mqtt-topic-structure-after-migration/12154/2 "2025-04-14T15:46:05Z")
The `c8y/` prefixed topics are bridged directly to Cumulocity. So any payload you send via these topics is directly forwarded to Cumulocity without any further processing on your thin-edge device. By not using the [thin-edge JSON format](https://thin-edge.github.io/thin-edge.io/understand/thin-edge-json/) and the corresponding topics, you are missing out on the multi cloud provider support of thin-edge. You can read more about this [here](https://thin-edge.github.io/thin-edge.io/understand/tedge-mapper/). ---
**Author:** ![Reuben\_Miller2](https://dub1.discourse-cdn.com/flex005/user_avatar/community.cumulocity.com/reuben_miller2/32/317_2.png) [@Reuben\_Miller2](https://community.cumulocity.com/u/Reuben_Miller2)\ **Post date:** [April 14, 2025, 4:58pm UTC](https://community.cumulocity.com/t/questions-about-thin-edge-mqtt-topic-structure-after-migration/12154/3 "2025-04-14T16:58:40Z")
Just extending what @Tristan_Bastian already mentioned. [thin-edge.io](http://thin-edge.io) is flexible enough that it allows you to easily adapt any existing agents to use the local MQTT topics for each cloud (e.g. `c8y/`) without having to change much on your existing agent However, long term, we’d encourage to start thinking about slowly transitioning the existing agent to make use of the `te/` topics as it improves the overall extensibility of your setup. For instance, if you publish measurements to the `te/` topics, then it gives other future components to easily subscribe locally to the data to also perform addition logic (e.g. conditional publishing, message logging etc.). In short, by using the more `te/` topics topics, it makes your overall solution more future proof, and easier to meet future requirements (the ones that you might not even know about yet!) ---
**Author:** ![system](https://dub1.discourse-cdn.com/flex005/user_avatar/community.cumulocity.com/system/32/31990_2.png) [@system](https://community.cumulocity.com/u/system)\ **Post date:** [April 15, 2025, 4:58pm UTC](https://community.cumulocity.com/t/questions-about-thin-edge-mqtt-topic-structure-after-migration/12154/4 "2025-04-15T16:58:44Z")
This topic was automatically closed 24 hours after the last reply. New replies are no longer allowed.