polythings
HomePlatformMigrateBenchmarksBlogOpen sourceRoadmap
Migrate · planned

Move without starting over

Moving an IoT fleet usually means a rewrite and a risky weekend. We're designing it as three steps you can stop between, for the platforms teams most often outgrow and for the ones they built themselves. None of this is available yet; this is how it will work.

Three steps, from any platform

  1. 01

    Connect

    Your fleet's data flows into Polythings, through the old platform's API or a bridge. No device changes.

  2. 02

    Run side by side

    Both platforms run at once, so you compare data and alarms before moving anything.

  3. 03

    Move devices

    Devices move in groups, unchanged where we speak the old platform's protocol, with a way back for each group.

From another platform

What moves, and whether devices need to change. Checked against each platform's documentation on 2026-10-18.

Azure IoT Hub

Microsoft's device connectivity serviceDevices unchanged

Endpoints compatible with IoT Hub's MQTT topics, twins and direct methods, with SAS-token and X.509 authentication. Devices pinned to Azure's hostname get one configuration push first.

ImportedDevices and identities, twins, tags, message routes, DTDL models, history

AWS IoT Core

Amazon's device connectivity serviceDevices unchanged

Endpoints compatible with per-thing certificates, shadows and the jobs topics. Register the same CA and certificates keep working.

ImportedThings and certificates, thing types and groups, shadows, rules, SiteWise models, IoT Events detectors, history

Particle

Device cloud with its own hardware and Device OSOne last update

Connect through Particle's API in minutes with no firmware change. Later, the last update Particle delivers is firmware that talks to Polythings, with a SIM plan that works without Particle's cloud.

ImportedDevices, groups, firmware versions, events

ThingsBoard

Open-source IoT platform with a commercial editionDevices unchanged

An endpoint compatible with ThingsBoard's device MQTT and HTTP API: telemetry, attributes and RPC, with access tokens or X.509.

ImportedDevices, device profiles, assets and relations, alarm rules where they map, telemetry history

Thinger.io

Hosted IoT platform with open device librariesOne last update

A connector through Thinger.io's API until devices get a firmware update to our embedded SDK.

ImportedDevices, data buckets, history

Mender

Over-the-air updates for embedded Linux and microcontrollersOne last update

The last Mender deployment installs the Polythings device agent. Existing update images keep working through the installer interface.

ImportedDevices, inventory, artifacts, deployment history

Eclipse Hono

Open-source device connectivityDevices unchanged

An endpoint compatible with Hono's MQTT and HTTP adapters: telemetry, event and command topics.

ImportedTenants and the device registry

Eclipse Ditto

Open-source digital twinsNo device change

Ditto runs in the cloud, so devices don't change; its things become twins and assets.

ImportedThings, attributes and features

Eclipse hawkBit

Open-source update serverDevices unchanged

An endpoint compatible with hawkBit's device API, so SWUpdate's and RAUC's hawkBit clients keep updating.

ImportedSoftware modules, distribution sets, rollouts

Eclipse Kura and Kapua

Open-source gateway framework and its cloudDevices unchanged

Kura's cloud connection (MQTT with Kura payloads) as an input, so gateways keep their configuration.

ImportedGateways, devices, history

From a platform you built yourself

Most fleets run on a broker, a database and scripts a team built over the years. Every one is different, but the way out is the same eight steps. Each can be undone, and devices change only in step 6.

  1. 1

    Take stock

    List device models and firmware versions, protocols, how devices authenticate and connect; your data (payloads, volumes, retention); everything that uses it (dashboards, apps, ERP, alarms, people); and how you update devices today.

    ToolsThe cutover planner fills in what it can from a sample of your traffic.

  2. 2

    Connect without touching devices

    Bridge your existing broker or stream into Polythings with an MQTT bridge, Kafka or HTTP forwarding. Data starts landing in Polythings; nothing changes for devices or users.

    ToolsBridges for MQTT brokers, Kafka and HTTP.

  3. 3

    Model it

    Turn payloads into device models, bind devices to the assets they measure, and define metrics. Recreate alarms in shadow mode: they evaluate but don't notify anyone yet.

    ToolsDevice models proposed from sample payloads; bindings suggested from tag names.

  4. 4

    Compare

    Run both systems side by side for two to four weeks, until the numbers and alarms match.

    ToolsA parity report: missing, duplicated and late data per device, and alarms that fired on one side only.

  5. 5

    Move people and systems

    Point dashboards, apps and integrations at the Polythings API, SQL or exports, and backfill history.

    ToolsHistory import; Postgres-compatible SQL for existing dashboards.

  6. 6

    Move devices in cohorts

    Give devices Polythings certificates, or register your existing CA. Push the new endpoint and credentials through your current update mechanism to 1% of devices, then 10%, then everyone, with a way back for each group.

    ToolsThe certificate authority; cohorts with health checks.

  7. 7

    Take over updates

    The last update from your old system installs the Polythings device agent or embedded SDK. From then on, updates come from Polythings.

    ToolsThe open-source device agent and embedded SDK.

  8. 8

    Switch off

    Keep a read-only archive, export what the old system held, and turn it off.

    ToolsExports in open formats.