For a decade, the pitch for managed IoT services was simple: connect your devices, click together a rules engine and a dashboard, and let the cloud provider worry about the plumbing. That pitch has aged badly. Google retired Cloud IoT Core in 2023. AWS ended support for AWS IoT Analytics on December 15, 2025, and for AWS IoT Events on May 20, 2026. Microsoft has now published a retirement date of September 20, 2029 for Azure IoT Central. If your connected-product or industrial monitoring stack was built on any of these “all-in-one” services, you are either mid-migration, overdue, or about to start one.
This article explains why the hyperscalers are pulling back from opinionated IoT application services, what they are steering customers toward instead, and how to run a migration that leaves you with a more durable platform rather than a rushed copy of the old one. It closes with a decision checklist and a worked example you can adapt.
What Has Actually Been Retired, and What Replaces It
The pattern across vendors is consistent: the low-level, high-volume building blocks (device connectivity, identity, messaging, provisioning) stay; the higher-level, IoT-specific application layers are folded back into general-purpose data, streaming and analytics services.
AWS IoT Analytics (end of support December 15, 2025)
IoT Analytics bundled ingestion channels, processing pipelines, a managed data store and SQL datasets. AWS’s own migration options map each stage to general services: Amazon Kinesis Data Streams or Amazon Data Firehose for collection, Amazon Managed Service for Apache Flink (or Firehose with AWS Lambda transforms) for processing, Amazon S3 or Amazon Timestream for storage, AWS Glue and Amazon Athena for analysis, and Amazon QuickSight for visualization. In other words, the “IoT” part disappears and you are left with a standard streaming lakehouse.
AWS IoT Events (end of support May 20, 2026)
IoT Events let teams model device state machines visually: “if temperature exceeds a threshold for five minutes, enter alarm state and notify.” AWS stopped onboarding new customers in May 2025, and its published replacement pattern rebuilds detector models in code: AWS IoT Core rules route messages into a Kinesis stream partitioned by device ID, a Lambda “evaluator” holds the state logic, Amazon DynamoDB persists per-device state, and Amazon EventBridge Scheduler implements timers. Alarm models that relied on AWS IoT SiteWise have their own migration procedure.
Azure IoT Central (retirement September 20, 2029)
Microsoft’s retirement notice points customers to Azure IoT Hub and the Device Provisioning Service for connectivity and onboarding, Azure Device Registry as part of the Azure-native device platform, and Microsoft Fabric (notably Real-Time Intelligence) for analytics and dashboards. On the edge side, Azure IoT Operations, a Kubernetes-based platform with an MQTT broker, data flows and connectors for OPC UA and other protocols, continues to evolve; its 2603 release in April 2026 added no-code dataflow graphs and governed cloud-to-edge management actions.
Four years sounds like plenty of runway for IoT Central. It is not, if you have tens of thousands of devices in the field whose firmware, certificates and provisioning flows are bound to IoT Central’s application model. Device fleets move at the speed of maintenance windows, not sprints.
Why the Hyperscalers Are Unbundling IoT
It is tempting to read these retirements as a loss of interest in IoT. A more accurate reading is that IoT data has become ordinary enterprise data. Three forces are at work:
- Convergence with the data platform. Telemetry used to sit in a separate “IoT silo” with its own store and dashboards. Today, organizations want sensor data joined with ERP, maintenance and customer data in the same lakehouse, governed by the same catalog. Purpose-built IoT analytics stores make that harder, not easier.
- Streaming has matured. Managed Flink, Kafka-compatible services, Fabric eventstreams and time-series databases now do what bespoke IoT pipelines did, with better scaling, tooling and talent availability.
- Edge AI shifts logic outward. More filtering, inference and control now happen on gateways and industrial PCs. A cloud-side visual rules engine is less central when the first decision is made at the edge.
The practical implication is that “IoT platform” no longer means a single product. It means an architecture: a device connectivity and identity layer, an event backbone, a state and rules layer, a data platform, and an application and operations layer. The migrations above force you to make that architecture explicit, which is the opportunity.
Step One: Build a Dependency Inventory Before Choosing Anything
Most failed migrations start with a target-architecture diagram. Successful ones start with an inventory of what the retiring service actually does for you today, including the implicit behaviors nobody wrote down. Capture at least the following:
- Device-facing contracts: MQTT topics, payload schemas, device twin or property models, command and direct-method patterns, and anything burned into firmware. These are the hardest to change.
- Identity and provisioning: certificate authorities, enrollment groups, X.509 versus symmetric keys, rotation processes and who owns them.
- Rules and state logic: every detector model, rule or alarm, its thresholds, timers and actions, plus the downstream systems it notifies.
- Data products: datasets, retention, schemas, and every report, notebook or API that reads them.
- User-facing features: dashboards, device management screens, role-based access, and the operators who rely on them daily.
- Operational signals: alerts, SLAs, on-call runbooks and cost baselines, so you can prove the new platform is at least as good.
For AWS IoT Events, export detector model definitions before anything else; the console and the describe-detector-model API both give you a machine-readable record of the logic. For IoT Central, export device templates, rules and dashboard definitions, and list which devices use which templates.
Step Two: Choose a Target Architecture With Clear Layers
Once you know what you depend on, design the replacement layer by layer. The guidance below is expressed as decisions rather than products, because the right product depends on your cloud estate and team skills.
Connectivity and identity
Keep this on the hyperscaler’s core service (AWS IoT Core, Azure IoT Hub with DPS) unless you have strong reasons for an independent MQTT broker. These services are not being retired, they handle device identity at scale, and they are where firmware already points. Changing the device endpoint is a firmware project; avoid it unless the business case demands it.
Event backbone
Introduce a durable stream between ingestion and everything else: Kinesis, Event Hubs, a Kafka-compatible service or a Fabric eventstream. Partition by device or asset ID so per-device ordering is preserved. This one decision decouples device traffic from consumers and makes future migrations far cheaper.
State and rules
Decide between three options: rules in code (Lambda or Azure Functions with a key-value state store, as in AWS’s IoT Events replacement pattern), a stream processor with keyed state and timers (Apache Flink is a strong fit for complex event processing), or a rules capability inside your analytics platform (for example, Fabric Activator for threshold-style alerts). Code gives control and testability; Flink gives scale and windowing; platform-native activators give speed for simple rules. Many teams use two of the three.
Data platform
Land raw telemetry in object storage in an open format, then curate into time-series and lakehouse tables. Use a time-series database where you need low-latency queries on recent data and the lakehouse for history, joins and machine learning. Register everything in the catalog with owners and retention policies.
Application and operations
Rebuild device management and dashboards deliberately. IoT Central users often lose a ready-made operator UI in migration; budget for a lean web application or a BI layer plus a small device-operations console, rather than discovering the gap at cutover.
A retirement notice is a forced architecture review. Teams that only “lift and shift” the old service’s features end up repeating the migration in five years; teams that separate connectivity, events, state, data and applications end up with a platform that can absorb the next change.
Step Three: Migrate Device Logic Without Changing Behavior
State-machine logic is where subtle regressions hide. A detector model that “enters alarm after five minutes above threshold” encodes decisions about timer resets, out-of-order messages and what happens when a device goes silent. Rewriting it in code is an opportunity to make those decisions explicit and testable.
- Write behavior tests first. Turn each detector model or rule into a set of input sequences and expected outputs, including edge cases such as duplicate messages, late arrivals and missing heartbeats.
- Make state explicit. Store per-device state with a schema (current state, entered-at timestamp, active timers, last-seen) rather than opaque blobs.
- Treat timers as first-class events. In AWS’s reference pattern, EventBridge Scheduler pushes timer events back into the same stream; whatever you choose, make timer creation and cancellation idempotent.
- Review sample code critically. Vendor migration samples are explicitly illustrative. AWS’s own IoT Events guide notes that its examples need customization before production use; check naming consistency, ARNs, error handling and retry behavior before you copy anything.
- Plan for poison messages. Add dead-letter handling so a malformed payload from one device cannot stall a partition.
Step Four: Run in Parallel, Then Cut Over by Cohort
Where the old service is still running (as IoT Central is until 2029), the safest pattern is a shadow run. Fork telemetry into the new pipeline, evaluate rules in both places, and compare outputs automatically. Differences become test cases. When the new path matches for an agreed period, cut over by device cohort or site, not all at once.
Where the old service is already gone, as with IoT Analytics and IoT Events, you are in recovery mode: reconstruct logic from exported definitions and historical alarms, replay stored telemetry through the new rules to validate, and prioritize alarms with safety or contractual impact. Document any behavior you consciously changed.
Cutover checklist
- Historical data backfilled and reconciled (record counts and spot checks per device).
- All rules covered by automated tests, with shadow-run differences explained.
- Dashboards and reports re-pointed, with owners signed off.
- Alerting and on-call runbooks updated for the new components.
- Rollback path defined for each cohort, including how to re-route device traffic.
- Cost monitoring in place, with budgets per environment and alerts on stream and function spend.
A Worked Example: Cold-Chain Monitoring Off IoT Events
Consider a generic logistics operator with several thousand refrigerated containers reporting temperature, door state and location every minute through AWS IoT Core. Alarms were modeled in AWS IoT Events: a container enters “warning” after ten minutes above its setpoint band, “critical” after thirty, and resets only after fifteen minutes back in range. Historical telemetry went to IoT Analytics for weekly compliance reports.
The replacement keeps AWS IoT Core and the existing topics, so no firmware changes are needed. An IoT rule writes every message to a Kinesis stream keyed by container ID. A Managed Service for Apache Flink application implements the warning, critical and reset logic with keyed state and event-time timers, which handles late messages from containers that briefly lose connectivity more gracefully than wall-clock timers. Alarm transitions are published to an output topic and to an operations queue. Raw telemetry lands in S3 through Firehose in Parquet, is cataloged in Glue, and compliance reports are rebuilt as Athena queries feeding the existing BI tool.
The team builds a replay harness that feeds three months of stored telemetry through the Flink job and compares state transitions against the alarm history exported earlier. Discrepancies reveal two undocumented behaviors (a door-open suppression rule and a site-specific setpoint override), which are then implemented and tested. The result is not just a replacement but a platform where logic is versioned, tested and portable.
Pitfalls to Avoid
- Underestimating the operator UI. Losing IoT Central’s built-in device views without a replacement creates shadow spreadsheets within weeks.
- Rebuilding a silo. Recreating a separate IoT data store instead of landing telemetry in the enterprise lakehouse forfeits the main benefit of the migration.
- Ignoring security obligations. In the EU, the Cyber Resilience Act’s reporting duties for products with digital elements, including the back-end services they depend on, have applied since September 11, 2026. Your new platform must support vulnerability tracking, update delivery and incident evidence.
- Cost surprises. Per-message, per-shard and per-invocation pricing behaves differently from bundled services. Model costs at peak load, not average.
- Big-bang cutovers. Cohort-based migration with rollback is slower on paper and faster in reality.
Future Outlook: Platforms as Composable Architecture
Expect the trend to continue. Vendors are investing in edge runtimes (AWS IoT Greengrass, including a lightweight nucleus and a compact C, C++ and Rust component SDK announced in April 2026; Azure IoT Operations on Kubernetes), in asset and device registries that integrate with general identity and governance, and in real-time analytics inside broad data platforms. Standard interfaces such as MQTT 5, OPC UA and open table formats make it more realistic to keep device contracts stable while swapping the services behind them.
The organizations that come out ahead will treat their IoT platform as a set of contracts and layers they own, with managed services plugged in where they add value. That is a different mindset from buying a single IoT application service, and it is the most useful lesson of the current wave of retirements.
Conclusion
The end of AWS IoT Analytics and IoT Events, and the scheduled retirement of Azure IoT Central, are not reasons to panic, but they are reasons to act deliberately. Inventory what the old service really does, keep device-facing contracts stable, introduce a durable event backbone, make state logic explicit and tested, and land data in your enterprise platform. Do that, and the migration becomes an upgrade: a more observable, portable and secure IoT platform that is ready for edge AI and regulatory scrutiny alike.
How Hanoi Technology Can Help
Hanoi Technology helps teams inventory, re-architect and migrate IoT workloads off retiring managed services, from device connectivity and stream processing to dashboards and ongoing managed operations.
Further Reading
- AWS IoT Events end of support – AWS Documentation
- Migration procedure for detector models in AWS IoT Events – AWS Documentation
- AWS IoT Analytics migration options – AWS Documentation
- Retirement: Azure IoT Central will be retired on September 20, 2029 – Azure service notice (AZ569914)
- Azure IoT Operations 2603 is now available – Microsoft Tech Community