Azure IoT Central alternatives include application platforms such as Iotellect, ThingsBoard, Cumulocity, ThingWorx, Losant, and Ubidots, as well as architectures built with Azure IoT Hub, Azure IoT Operations, or AWS IoT Core.
The right choice depends on what you need to retain or improve: device management, dashboards, industrial connectivity, application customization, deployment flexibility, or predictable platform costs. Migration requirements also matter because replacing a platform involves more than reconnecting devices.
This guide compares nine options, explains which projects they may suit, and outlines what to check before moving an existing Azure IoT Central application.
Quick takeaways
- Compare application platforms separately from cloud services that require additional application development.
- Evaluate industrial protocols, dashboards, rules, security, deployment options, and pricing against your actual project.
- Include the cost of operating infrastructure and rebuilding application functionality.
- Test device connectivity, data mapping, commands, and historical data before committing to a migration.
Lifecycle note: Microsoft corrected an erroneous February 2024 message that claimed Azure IoT Central would be retired in March 2027. That message should not be treated as a verified retirement announcement. Check Microsoft’s clarification and current official communications when making lifecycle decisions.
Azure IoT Central Alternatives at a Glance
The following table provides a starting point for evaluation. “Suitable for” describes a potential project fit, rather than a universal ranking.
| Option | Suitable for | Deployment or architecture | What to evaluate closely |
|---|---|---|---|
| Iotellect | Custom industrial applications, system integrators, and OEM solutions | Cloud, on-premises, hybrid, and edge options, depending on the plan | Application configuration, instance sizing, and migration requirements |
| ThingsBoard | Telemetry, dashboards, and developer-led IoT applications | Self-hosted or vendor-managed options | Edition features, gateway requirements, and operating responsibilities |
| Cumulocity | Device fleets, equipment monitoring, and connected services | Cloud and edge deployment options | Deployment-specific capabilities, integrations, and commercial terms |
| ThingWorx | Industrial applications and equipment connectivity | Industrial application platform | Platform architecture, implementation effort, and licensing |
| Losant | Connected products and applications built around visual workflows | Application platform with cloud and edge components | Application design, deployment terms, and migration of existing functionality |
| Ubidots | Monitoring applications centered on dashboards and alerts | Managed cloud platform | Data volumes, retention, subscription limits, and connectivity requirements |
| Azure IoT Hub with supporting services | Custom cloud applications within the Azure ecosystem | Composed Azure architecture | Development of dashboards, business logic, integrations, and access control |
| Azure IoT Operations | Edge-connected industrial and operational technology environments | Edge data plane on Azure Arc-enabled Kubernetes | Cluster operations, connectors, and application-layer requirements |
| AWS IoT Core with supporting services | Custom applications within the AWS ecosystem | Composed AWS architecture | Application development, service integration, security, and usage costs |
A platform’s support for MQTT or OPC UA does not establish that it can import an Azure IoT Central application. Connectivity and migration compatibility should be tested separately.
Why Consider an Azure IoT Central Alternative?
Azure IoT Central provides a hosted application environment for connecting devices, monitoring telemetry, configuring dashboards, creating rules, and managing devices.
Teams may evaluate alternatives when their requirements change in one or more of the following areas.
Deployment control
Some projects require on-premises processing, local data storage, or operation at sites with intermittent connectivity. Evaluate where the application runs, which functions remain available offline, and whether licensing or management requires a cloud connection.
For a broader deployment comparison, see our guide to on-premise IoT platforms for industrial use.
Industrial connectivity
Manufacturing and infrastructure projects often involve PLCs, gateways, meters, and existing control systems. Check the exact protocols, device models, authentication methods, and read/write operations required by your equipment.
Distinguish built-in drivers from gateway connectors, third-party integrations, and custom development.
Application customization
A monitoring dashboard may be sufficient for one project, while another needs customer portals, operator interfaces, tenant isolation, or equipment-specific workflows.
Evaluate how much functionality you can configure visually and which requirements need code, additional services, or specialist support.
Pricing and operating costs
Compare platform subscriptions alongside infrastructure, storage, integration, support, and ongoing administration. For usage-based services, model expected message volumes and data retention. For fixed subscriptions, check instance capacity and the features included in each plan.
Device and customer management
A growing deployment may need bulk device operations, firmware updates, customer-specific access, audit trails, and integration with business systems. Test these functions against realistic fleet and user scenarios.
Azure IoT Central Alternatives Compared
1. Iotellect
Iotellect is a low-code IoT/IIoT platform for building custom monitoring, control, and connected-product applications. It provides a software foundation that teams configure for their equipment, workflows, and users.
Its documented protocol and connectivity coverage includes MQTT, Modbus variants, and OPC UA. Its visual interface tools, workflows, and development and integration capabilities support application building and integration with external systems.
When to shortlist it: Industrial projects that need custom applications, white-label interfaces, and deployment flexibility.
What you build or operate: Teams configure the data model, interfaces, workflows, and integrations. Hosting and administration responsibilities depend on the deployment.
Pricing and deployment: The Iotellect pricing model uses fixed subscriptions for dedicated platform instances rather than per-device or per-message charges. Practical capacity depends on computing resources, bandwidth, and storage. Deployment and white-label entitlements vary by plan.
Its industrial edge platform is relevant where processing and application functionality must run close to equipment.
What to verify before switching: Test device authentication, telemetry mapping, commands, rules, and data migration. The public material reviewed does not establish a ready-made Azure IoT Central migration path.
2. ThingsBoard
ThingsBoard provides device management, telemetry processing, dashboards, and rule-based functionality. Self-hosted and vendor-managed options allow teams to choose different operating models.
When to shortlist it: Projects centered on device telemetry, visualization, and configurable processing rules.
What you build or operate: Teams configure devices, dashboards, rule chains, and integrations. Self-hosting adds responsibility for databases, backups, upgrades, security, and availability.
What to verify before switching: Confirm the edition required for white-labeling, access control, integrations, and other commercial features. Test industrial gateway connections and the effort needed to rebuild existing dashboards and rules.
For a wider comparison, read our guide to ThingsBoard alternatives for industrial IoT.
3. Cumulocity
Cumulocity combines device integration, fleet management, streaming analytics, dashboards, and application enablement. Its portfolio includes cloud and edge deployment options.
When to shortlist it: Equipment manufacturers and operations teams developing device-management and connected-service applications.
What you build or operate: Teams configure device integrations, asset models, dashboards, and business applications. Responsibilities depend on the chosen deployment and service agreement.
What to verify before switching: Check firmware and configuration management, customer isolation, data export, and integration requirements. Confirm scalability and feature availability for the specific cloud or edge deployment being proposed.
4. ThingWorx
ThingWorx is an industrial application platform. Kepware connectivity can form part of an architecture connecting industrial equipment to ThingWorx applications.
When to shortlist it: Industrial teams evaluating application development around existing equipment and Kepware connectivity.
What you build or operate: Implementation involves configuring equipment connections, application models, interfaces, integrations, and the operating architecture.
What to verify before switching: Confirm the current product version, deployment options, licensing, support arrangements, and infrastructure requirements. Test how existing device models, commands, dashboards, and workflows would be represented in the target application.
5. Losant
Losant is an application-enablement platform with visual workflows, dashboards, custom end-user experiences, and edge components.
When to shortlist it: Connected-product teams building applications that combine device data, business workflows, and customer-facing interfaces.
What you build or operate: Teams design workflows, interfaces, integrations, and customer access. Edge requirements should be evaluated alongside the cloud application.
What to verify before switching: Confirm deployment terms and the effort required to recreate device models, rules, and interfaces. Review export coverage carefully: Losant’s application documentation describes exclusions that affect what an application export preserves.
6. Ubidots
Ubidots provides a managed environment for applications built around device data, dashboards, events, and alerts.
When to shortlist it: Monitoring projects where visualization and notifications are central requirements.
What you build or operate: Teams configure device data ingestion, variables, dashboards, event conditions, and integrations.
What to verify before switching: Evaluate subscription limits, ingestion rates, retention, user access, and branding requirements. Confirm how industrial equipment will connect and whether the proposed deployment meets local-processing or data-residency requirements.
7. Azure IoT Hub with Supporting Services
Azure IoT Hub is a foundation for cloud-connected devices. It can be combined with Device Provisioning Service, data storage, analytics, and application services to build a custom Azure solution.
When to shortlist it: Organizations that want to retain Azure infrastructure, skills, and governance while taking greater responsibility for application development.
What you build or operate: The solution needs an application layer for operator interfaces, business workflows, integrations, and access control. Supporting services must be selected and integrated.
What to verify before switching: Estimate the engineering and operating effort required to reproduce the functions currently used in IoT Central. Microsoft provides guidance for migrating devices from IoT Central to IoT Hub, but device movement does not recreate the complete application.
8. Azure IoT Operations
Azure IoT Operations provides an edge data plane on Azure Arc-enabled Kubernetes. Microsoft recommends it for new edge-connected industrial solutions.
When to shortlist it: Industrial environments requiring local connectivity and processing within an Azure-managed architecture.
What you build or operate: Teams must account for Kubernetes infrastructure, edge configuration, connectors, data flows, and the application experience.
What to verify before switching: Check hardware requirements, cluster administration, connectivity dependencies, and integration with analytics and visualization services. Evaluate it as an edge architecture rather than assuming it reproduces IoT Central’s hosted application interface.
9. AWS IoT Core with Supporting Services
AWS IoT Core provides managed connectivity and messaging for devices. A complete application typically combines it with other AWS services and a separately developed user interface.
When to shortlist it: Teams building custom IoT applications within the AWS ecosystem.
What you build or operate: Developers implement the application architecture, permissions, data processing, storage, interfaces, and business integrations.
What to verify before switching: Test device credentials, messaging behavior, command handling, and data mapping. Estimate costs across the full architecture, including connectivity, processing, storage, and supporting services.
Which Option Fits Your Project?
Use project requirements to narrow the list before comparing commercial proposals.
| Project requirement | Options to investigate | Deciding question |
|---|---|---|
| Custom industrial applications with flexible deployment | Iotellect, ThingsBoard, Cumulocity, ThingWorx | How much functionality is configurable, and what requires development? |
| Telemetry dashboards and alerts | ThingsBoard, Ubidots, Losant | Does the platform support the required data volumes, workflows, and user access? |
| Device fleet operations | Cumulocity, ThingsBoard, Azure IoT Hub-based architectures | Which provisioning, update, and remote-management functions are available? |
| Continued use of Azure | Azure IoT Hub or Azure IoT Operations | Is the workload primarily cloud-connected or edge-connected? |
| Custom development within AWS | AWS IoT Core-based architecture | Can the team build and maintain the application layer? |
| Fixed platform subscription costs | Iotellect | Which plan and instance resources fit the expected workload? |
These are starting points for evaluation. A candidate should move onto the final shortlist only after a technical demonstration using representative devices, data, users, and workflows.
Azure IoT Central, IoT Hub, and IoT Operations: What Is the Difference?
The three services address different parts of an IoT solution.
Azure IoT Central provides a hosted application environment with device templates, telemetry views, dashboards, rules, and operator functions.
Azure IoT Hub provides cloud connectivity and device-management building blocks. Teams combine it with other services to create an application.
Azure IoT Operations provides an edge data plane for industrial connectivity and local processing on Kubernetes.
Microsoft’s current Azure IoT portfolio overview distinguishes cloud-connected and edge-connected architectures. Use that distinction to choose an Azure path, then identify the application functions and supporting services required.
What to Check Before Migrating from Azure IoT Central
Migration involves device connections, application behavior, identities, integrations, and data. An export file or matching protocol does not demonstrate that the target will reproduce the existing solution.
Inventory the Existing Application
Document the devices, templates, telemetry fields, properties, commands, rules, dashboards, users, certificates, integrations, and historical data currently in use.
Identify dependencies such as gateway software, device firmware, authentication settings, and external systems.
Map Each Component to the Target
| Component | Migration questions |
|---|---|
| Device identities and credentials | Can devices authenticate to the target? Must credentials, endpoints, or firmware change? |
| Device templates and data models | How will telemetry, units, properties, and commands map to the new model? |
| Rules and actions | Must rules be rebuilt? Will timing, thresholds, and notifications behave correctly? |
| Dashboards and views | Can interfaces be imported, or must they be recreated? |
| Historical data | What data can be retrieved, transformed, and imported without losing timestamps or context? |
| Users and permissions | How will roles, tenant boundaries, and access policies be recreated? |
| Integrations | Which endpoints, secrets, exports, and business-system connections must change? |
Run a Representative Pilot
Test a small but realistic group of devices, including equipment with different protocols, credentials, firmware, and connectivity conditions.
Verify telemetry, commands, alerts, permissions, and integration behavior. Reconcile historical records where data transfer is required.
Plan Phased Cutover and Recovery
Define device groups, acceptance criteria, monitoring, and rollback procedures before production migration.
Rehearse recovery using the actual devices and target configuration. Estimate migration cost, downtime, and staffing from the pilot rather than assuming a universal migration timeline.
Frequently Asked Questions
What are the main alternatives to Azure IoT Central?
Options include Iotellect, ThingsBoard, Cumulocity, ThingWorx, Losant, and Ubidots. Teams can also build applications using Azure IoT Hub, Azure IoT Operations, or AWS IoT Core with supporting services. Compare them by application functionality, deployment, device management, industrial connectivity, pricing, and migration effort.
Is Azure IoT Hub a direct replacement for Azure IoT Central?
Azure IoT Hub provides device connectivity and management building blocks. Replacing an IoT Central application with an IoT Hub-based solution also requires dashboards, rules, integrations, access control, and other application functions. Microsoft’s device migration guidance should therefore be considered one part of a wider application migration project.
Can an Azure IoT Central alternative run on-premises?
Some alternatives support self-hosted or on-premises deployments. Iotellect offers on-premises options on applicable plans, and ThingsBoard provides self-hosted editions. Check each vendor’s deployment requirements, licensing dependencies, local-processing capabilities, and operating responsibilities before choosing an architecture.
What must be rebuilt when migrating from Azure IoT Central?
Dashboards, views, rules, integrations, and user permissions may need to be recreated or transformed. Device models, credentials, commands, and historical data require separate mapping and validation. The work depends on the source application and target platform; there is no universal migration package that guarantees equivalent behavior across vendors.
When should an industrial IoT team consider Iotellect?
Consider Iotellect when the project needs custom industrial applications, protocol connectivity, visual application building, white-label interfaces, or flexible deployment. Its fixed platform subscriptions may also suit teams seeking predictable licensing costs. Validate the relevant plan, instance capacity, and migration requirements through a demonstration based on the existing application.
Comparison Methodology
This guide combines vendor-documented capabilities with recommendations about potential project fit. It is published by Iotellect and includes Iotellect among the options evaluated.
Features, pricing, licensing, and deployment terms vary by edition and can change. A documented capability does not establish migration compatibility, while a capability absent from the reviewed documentation should be confirmed with the vendor rather than assumed unavailable.
Review the Iotellect IoT platform and request a technical demonstration using your device mix, application requirements, identity model, and preferred deployment.