How to Evaluate an Azure IoT Central Alternative
Evaluate Azure IoT Central alternatives by device connectivity, data modeling, dashboards, rules, integrations, security, migration complexity, deployment flexibility, and long-term product roadmap. The right shortlist depends on the estate already running, the workload it serves, and how much operating responsibility the buyer is willing to carry.
Feature breadth is not a buyer-independent result. Research comparing industrial IoT platforms found that although these platforms “revolve around similar business objectives, they address a variety of use cases and, thus, differ considerably in their architectural setup.” It sorts them into four architectural archetypes (FIM Research Center, 2021). A separate study noted that “there is a lack of comparison frameworks for IoT platforms,” leaving buyers without a defensible method, and applied multicriteria decision analysis instead (University of Twente, 2021).
One variable reorders every shortlist: the responsibility model. NIST defines the boundary: with software as a service, “the consumer does not manage or control the underlying cloud infrastructure including network, servers, operating systems, storage, or even individual application capabilities.” With platform as a service, the consumer “has control over the deployed applications and possibly configuration settings for the application-hosting environment” (NIST SP 800-145, 2011). Industrial security standards start from the same premise, treating shared responsibility as “an essential building block of automation cybersecurity” (ISA/IEC 62443 series).
As a rule of thumb, classify the responsibility model first. Then set the requirements a candidate must meet and the weights that matter for the specific estate before looking at vendor results. Reversing that order lets the vendor with the longest feature page win by default.
Unresolved evidence is unresolved—not zero, and not proof that a capability is missing.
What Microsoft Actually Said About Azure IoT Central Retirement
The correction applies to the February 14 system message. It does not establish Azure IoT Central’s future lifecycle.
Microsoft said the February 14 system message was inaccurate and presented in error. Its response records what the message had claimed: “The error message stated that Azure IoT Central will be deprecated on March 31st, 2027 and starting April 1, 2024, you won’t be able to create new application resources. This message is not accurate and was presented in error” (Microsoft, 2024).
The March 2027 date and the April 2024 creation cutoff were claims made by that erroneous message. They were not a lifecycle announcement. The same response adds that “Microsoft does not communicate product retirements using system messages.”
The reviewed official record contains no verified service-wide Azure IoT Central retirement date. Microsoft’s lifecycle product search returns no result for the product, while the retirement filter in Azure Updates returns only two limited records: classic data export in 2023 and the version 3 upgrade in 2022. This silence proves no future outcome in either direction for continuity, support, billing, service levels, access, or data retention.
Microsoft’s 2025 documentation still describes “multiple ways to create an IoT Central application,” which contradicts the alleged April 2024 cutoff. However, procedural availability today is not a lifecycle guarantee for tomorrow.
For products in the relevant Azure categories, Microsoft “typically offers a notification period of up to 3-years before discontinuing support unless stated otherwise.” The policy also lists exceptions for free products, preview products, products with fixed lifecycles, and products depending on components that follow a different lifecycle. No retirement date can be reconstructed from this policy.
As of its April 2026 revision, Microsoft’s portfolio page states that “the Azure IoT portfolio includes two primary platforms and two shared cloud services.” It names Azure IoT Operations as “Microsoft’s primary recommendation for new edge-connected solutions” and lists IoT Central in the device-management row alongside IoT DPS, Device Update, and Azure Device Registry.
A single dated page describes current portfolio positioning, but it supports no reliable inference about direction, intent, or timing.
The bottom line is to treat lifecycle evidence and workload fit as separate decisions.
What Can Be Extracted and What Every Target Still Has to Prove
Microsoft’s documentation lets a buyer inventory the source side today. Only target-specific tests can prove the other side for a particular product, version, and estate.
The Device Provisioning Service, or DPS, provides “zero-touch, just-in-time provisioning to the right IoT hub.” After that, “the DPS instance has no further role as an intermediary unless the device needs to reprovision” (Microsoft Learn, 2026).
IoT Hub “acts as a central message hub in a cloud-based IoT solution,” while a device twin carries desired and reported properties for a device. However, the estate includes several types of artifacts with separate extraction paths.
Start with models and extensions. A device template “isn’t a standard DTDL document,” and “you must use the UI to create and manage views” (Microsoft Learn, 2025). These assets can be exported and transformed, but target compatibility is not confirmed. The new platform must prove model import, extension mapping, unit handling, and command support.
Enrollment groups and certificates also need transformation. The “export process creates a CSV file,” while X.509 devices require leaf certificates generated from the root or intermediate certificate (Microsoft Learn, 2024). A target must demonstrate enrollment import, support for the required attestation class, and acceptable key-custody practices.
For identities and twins, IoT Hub accepts the “same JSON format that the ExportImportDevice job uses” and can “import the data for the device twin” (Microsoft Learn, 2025). Export, transformation, and import may therefore be possible after testing, but field mapping, twin semantics, and version handling still require proof.
Rules can be exported, but portability is incomplete. “All rule definitions are included,” while “actions, except for email actions, aren’t included” (Microsoft Learn, 2025). Test rule import, window semantics, and action binding on the target.
Dashboards and views may require rebuilding. Copied applications require operators to “reconfigure these tiles,” and “creating personal dashboards using API is currently not supported” (Microsoft Learn, 2025). The target must prove either a working import or a tested rebuild process, including bindings and roles.
Historical data requires special care. “When you turn on data export, you get only the data from that moment onward” (Microsoft Learn, 2025), and queries “can retrieve up to 10,000 records” (Microsoft Learn, 2024). Any export-and-import plan must test backfill limits, duplicate handling, and timestamp preservation.
Finally, application copies exclude device instances, device data history, user data, and continuous data export definitions (Microsoft Learn, 2025). Integrations and role state therefore need transformation, while identity recreation, endpoint binding, and secret handling remain target-specific proof points.
IoT Central artifacts have selective extraction paths. They do not form a single documented portable estate package. Where a target’s documentation says nothing, the honest conclusion is “not confirmed in the reviewed documentation.” That is not the same as “unsupported.”
The detailed cutover mechanics that do exist are Azure-specific. Microsoft’s guide opens conditionally: “If you decide to migrate from an IoT Central-based solution to an IoT Hub-based solution, you need to change the configuration of all the devices currently connected to your application” (Microsoft Learn, 2025).
The guide documents running the target in parallel, moving devices in phased groups, and establishing a failback step. It also identifies several prerequisites: a DeviceMove component on the device, destination DPS scope handling, target credentials using shared access signature keys or X.509 certificates, and devices that are reachable and compatible. Unassigned devices cannot currently be moved with the tool.
A warning sign is treating the migration as reversible before failback has been rehearsed on the actual estate. Microsoft describes recovery as reprovisioning devices from the new hub back to the old one. That is a procedure rather than proof of a successful outcome.
Ordinary cutover controls must also remain separate. The iotc-migrator repository was archived by its owner on June 15, 2026, and is now read-only. This is a fact about the repository and nothing else.
Commands expect a device to be connected and fail if it cannot be reached by default, unless offline queuing is configured. Bulk identity import can also update and delete existing devices, and an import operation cannot be undone.
The practical approach is to inventory the source estate artifact by artifact, then demand target-specific proof. This includes an import test, field-level semantic mapping, identity and credential handling, firmware compatibility, historical reconciliation, dashboard and rule acceptance tests, and a rehearsed failback for the exact versions and attestation classes in use.
Semantic interoperability is the hard part, not transport (W3C, 2023). A protocol match is connectivity evidence. It is not migration readiness.
Eight Paths Worth Testing Against Your Workload
This evidence snapshot was accessed on August 7, 2026. Many vendor pages do not provide a publication date. An access date is neither a publication date nor a roadmap commitment, so buyers should reverify capabilities and pricing before making a decision.
1. Azure IoT Operations
Azure IoT Operations provides an edge data plane on Arc-enabled Kubernetes. Microsoft describes it as “a unified data plane for the edge,” with Microsoft Fabric used “to build real-time dashboards” (Microsoft Learn, 2026).
Buyers still own cluster operations, capacity, the application UI, and identity design. Operator dashboards, fleet jobs, and white-label scope are not confirmed in the reviewed pages.
2. IoT Hub Plus DPS Plus Fabric or ADX
This is a composed cloud-services path rather than a single packaged platform. DPS provides “zero-touch, just-in-time provisioning,” while ADX supports “continuous ingestion from customer-managed IoT Hubs” (Microsoft Learn, 2026).
The buyer remains responsible for application architecture, the operator UI, business rules, cross-service identity, and releases.
3. AWS IoT Core Plus TwinMaker
AWS offers composed cloud services with several ways to provision devices, jobs for remote operations, and Grafana integration through an application plugin (AWS, accessed August 7, 2026).
Buyers must handle IAM design, model composition, and Grafana work. AWS also warns that shadow messages are not guaranteed to reach a device in a specific order.
4. ThingsBoard
ThingsBoard is self-managed or vendor-managed, depending on the edition. It is described as a horizontally scalable, multi-tenant platform supporting MQTT, HTTP, CoAP, LwM2M, and SNMP, with OTA updates for remotely pushing firmware and software packages (ThingsBoard, accessed August 7, 2026).
In self-managed deployments, the buyer owns uptime, database and queue operations, backups, upgrades, and security. Edition details, migration imports, and white-label entitlements require exact-version proof.
5. Cumulocity
Cumulocity is an industrial suite available in cloud and Edge topologies. Its documentation covers individual and bulk device registration as well as firmware, software, and configuration management (Cumulocity, 2025 documentation).
The topologies differ. Cumulocity Edge is documented as a single-server deployment without horizontal scalability (Cumulocity, 2026 documentation).
6. ThingWorx
ThingWorx is an industrial application platform, although the deployment detail remains unresolved in the reviewed public evidence. Kepware supports the ThingWorx Native Interface, and platform settings determine whether ThingWorx runs as a cluster or standalone server and whether SSO is enabled (PTC, accessed August 7, 2026).
Broader on-premise, cloud, and hybrid claims still need verification, while uptime and application work remain version-specific questions.
7. Losant
Losant combines an application platform with cloud and edge components. It provides a web interface for interacting with connected devices and customizable dashboards (Losant, accessed August 7, 2026).
YAML exports exclude keys, certificates, tokens, events, state history, and edge deployments, while edge setup requires an experienced developer. Those exclusions directly affect migration planning.
8. Ubidots
Ubidots is a vendor-managed portal built around devices, variables, synthetic variables, dashboards, and events. Device Types can automate onboarding at scale (Ubidots, 2025).
According to the vendor, private deployments operate only at the cloud level and are managed by its DevOps team. Buyers should therefore confirm whether that responsibility model fits their requirements.
This comparison has no total score or universal winner. Each vendor page proves what that vendor documents about its own product and nothing about a competitor’s performance or gaps. Microsoft, Azure, and all named platforms are trademarks of their respective owners.
When Staying in Azure Is the More Coherent Architecture
IoT Central bundles an operator surface. Microsoft describes a web UI that “lets you quickly connect devices, monitor device telemetry, create rules, and manage devices and their data throughout their life cycle” (Microsoft Learn, 2025). Nothing in the current Azure portfolio replaces that bundle as a single product.
IoT Hub carries messaging and device control, DPS handles provisioning, and Azure Data Explorer or Microsoft Fabric supplies analysis and reporting. Microsoft says IoT Hub’s features and extensibility model “enable device and back-end developers to build robust device management solutions” (Microsoft Learn, 2025).
The buyer owns the application UI, integration, identity, releases, and operations on top.
For an organization with existing Azure governance, that ownership may be cheaper to carry than a platform change. Microsoft’s security guidance covers private endpoints, Microsoft Entra ID authentication, and Azure Policy for IoT Hub. Existing skills, contracts, and identity design are legitimate factors to consider.
This is not a drop-in replacement, and nothing in the reviewed evidence establishes a cost, staffing, delivery-time, or total-cost advantage in either direction.
Limitations
Public evidence cannot answer five important buyer questions.
First, what tenant-specific lifecycle, support, billing, and continuity commitments has Microsoft provided outside its public pages? This review covers public information, not private or contractual commitments.
Second, what will a migration actually cost, how long will it take, what downtime should be expected, and how often has failback worked for a comparable estate? No admissible source supplies comparable cost, duration, downtime, success, or failback rates.
Third, which models, rules, jobs, dashboards, views, identities, credentials, integrations, and historical records can a given target import with semantic parity under the exact versions in use? Source-side documentation cannot answer a target-side question.
Fourth, how much historical data is recoverable for a specific tenant? The reviewed official pages conflict on the retained-history window, so no duration is published here.
Finally, which roadmap, pricing, deployment, and support terms will each vendor commit to contractually for a given region and term? Product pages and an access date cannot answer that.
Test Iotellect Against the Same Framework
Apply the same method to Iotellect: map documented capabilities to the workload, identify what the buyer must build and operate, and require target-specific migration proof before putting it on the shortlist.
On connectivity, Iotellect documents MQTT, Modbus/RTU, Modbus/ASCII, Modbus/TCP, Modbus/UDP, and full support for the OPC UA stack. The platform can run on industrial PCs, Linux PLCs, single-board computers, and specialized IoT gateways.
For application building, Iotellect states that it is a white-label platform that can integrate over HTTP, MQTT, or JDBC/ODBC and provides open-source Java, .NET, and C++ APIs through its development and integration capabilities.
For operations, changes, operations, and events can be queued if a device is offline. Workflows constitute the code of the IoT application’s logic, while the Web UI Builder provides a visual interface editor. These are vendor statements about the vendor’s own product, and they carry exactly that weight.
Iotellect documents relevant connectivity and application-building capabilities, but the public pages reviewed for this article do not document an Azure IoT Central migration path. Any move would require a separately designed and validated migration project held to the same target-proof standard demanded of every other candidate.
Review the Iotellect IoT platform deployment options and its protocol and connectivity coverage. Then request a technical demonstration based on your device mix, protocol list, identity model, and target deployment topology.
Define the workload before you shortlist. Verify the evidence before you move.