Migrate · Guide
Moving from another IoT platform
A safe, step-by-step move from any cloud IoT service or your own MQTT server, without re-flashing devices.
Updated 11 Nov 20262 min read
All ThingsX IoT Core pages
- What ThingsX IoT Core does
- Quick start: connect your first device
- Key concepts
- Security and access
- Connect Wi-Fi and IoT devices
- BLE gateways, shelf labels and child devices
- LoRaWAN sensors and gateways
- Industrial I/O modules
- Device twins and state
- Send commands to devices
- Rules: react to device messages
- SDK and REST API
- Monitor your fleet and support customers
- Moving from another IoT platform
- From AWS IoT Core
- From Azure IoT Hub and other platforms
- Device can't connect
- Devices keep disconnecting or reconnecting
- Data isn't arriving or a rule doesn't fire
- Frequently asked questions
- Topics and limits reference
Most cloud IoT services and MQTT servers share the same building blocks: devices, groups, certificates, access policies, a state document per device, cloud-to-device messages and routing rules. A move is mostly a mapping exercise, and devices can usually keep their certificates.
- 1Inventorydevices, credentials, policies, rules, integrations
- 2Importdry run first, then for real
- 3Pilota handful of devices point at IoT Core
- 4Move backendsapps use the IoT Core API or SDK
- 5Cut over in wavesby store, site or model
- 6Retire the old serviceafter a quiet period
Concept map
| On your current platform | In ThingsX IoT Core |
|---|---|
| Devices, device types, groups | Things, thing types, groups |
| Device shadow or device twin | Twins (desired, reported, delta) |
| Access policies | JSON policies, with a simulator |
| X.509 device certificates | Kept, pinned by fingerprint: no re-flashing |
| Symmetric keys or tokens | Password credentials (device config changes) |
| Jobs, direct methods, cloud-to-device messages | Commands with acknowledgement |
| Message routing rules | Rules in SQL with a test bench |
| Serverless functions, queues, streams | HTTP and queue actions |
| Fleet search, device query | Thing search by name and attribute |
| A separate LoRaWAN service | Built in, same registry and rules |
What changes on a device
Usually two settings: the endpoint and the server root CA it trusts. Client ID, private key, device certificate and topics stay the same when the device already uses certificates. If you use your own server certificate from a public CA that the devices already trust, only the endpoint changes.
Plan the waves
- Inventory what you have: device count per model, how each signs in, topics used, rules and where they send data.
- Import devices, certificates and policies (see the platform guides below). Always run a dry run first.
- Pilot with 5 to 20 devices in one site. Compare data in both systems for a few days.
- Move backends to the IoT Core API or SDK. Rules that used serverless functions become HTTP actions to your services.
- Cut over in waves by site or model; keep the old endpoint available until each wave is stable.
Platform guides
Was this page helpful?
Can't find what you need? Contact support or read about ThingsX IoT Core.