Wednesday 30 September 2026 495 stories on file Full archive
Daily Edition
newscms

Volume III Edition Daily

Azure IoT Central Closes the Door: New Apps Halt, Existing Fleets Get Until September 2029

For a decade, Azure IoT Central was the friendly front door into the industrial internet of things. You defined a device template, pointed it at a fleet of sensors or gateways, and got provisioning, telemetry…

IoT 1,912 words 9 min read

Azure IoT Central Closes the Door: New Apps Halt, Existing Fleets Get Until September 2029 — IoT No Image IoT
Lead image · Filed 29 September 2026, 23:40

Azure IoT Central Closes the Door: New Apps Halt, Existing Fleets Get Until September 2029

Introduction

For a decade, Azure IoT Central was the friendly front door into the industrial internet of things. You defined a device template, pointed it at a fleet of sensors or gateways, and got provisioning, telemetry, dashboards and rules without touching a single provisioning service. That ease is now on a clock. Microsoft announced on September 23, 2026 that new IoT Central application creation is unavailable starting that same day, that existing applications keep working "as-is" through September 20, 2029, and that after that date IoT Central applications are no longer available at all. The recommended destination is not another managed application — it is Azure IoT Hub with Device Provisioning Service, plus Microsoft Fabric for analytics, with Azure Device Registry coming in preview for fleet governance.

The announcement arrived in a post on Microsoft's IoT blog titled "Azure IoT Central is evolving: what you need to know." It reads like a product update, but for anyone who has stood up an IoT Central tenant it is a three-year migration notice with a hard edge. The reporting on Microsoft's decision has been consistent with the vendor's own guidance: Windows Forum noted that Microsoft has blocked new IoT Central apps and that existing apps remain available through September 20, 2029, and Microsoft's own Q&A threads already carry user questions about the deprecation date.

What follows is what actually changes, what does not, and the work an IoT Central tenant now has ahead of it.

What Microsoft Actually Changed

Three dates matter, and they are deliberately staggered.

September 23, 2026 — new application creation stops. If your team is standing up a fresh IoT Central tenant today, you no longer can. This is the date that already bit; it is not a future deadline. The fix is not to wait and see. The new build has to start on IoT Hub and Device Provisioning Service.

Through September 20, 2029 — existing applications run unchanged. Microsoft is explicit that current tenants continue to function and can be managed as-is. No forced cutover, no emergency migration weekend. Devices keep checking in, telemetry keeps flowing, dashboards keep rendering. This is the single most important fact for capacity planning: there are roughly three years to do the work properly.

After September 20, 2029 — IoT Central is gone. Not deprecated-with-a-sunset, but unavailable. Whatever was not migrated by then stops.

Behind those dates sits a positioning statement. Microsoft argues that IoT Central pioneered the managed application experience but that the platform has since grown into something the fixed application model cannot hold. Azure IoT Hub and Device Provisioning Service carry secure, high-scale device connectivity and provisioning; new investment has added richer device lifecycle features such as certificate management, and deeper integration with Azure Device Registry. The company's argument is that by concentrating investment on a unified Azure-native platform built on core constructs like Azure Resource Manager and role-based access control — rather than on a fixed application experience — it can move faster and give customers a more flexible foundation.

That is a coherent argument, and it is also the standard playbook: fold a product into the platform underneath it and let the platform's newer services absorb the value. The strategic logic can be sound while the migration burden still lands on customers, which is the part that matters operationally.

The Migration Map, Capability by Capability

Microsoft published a table mapping what IoT Central does today to where each function lives in the Azure-native stack. It is worth reading as an inventory of work, not as reassurance.

  • Device connectivity and messaging → Azure IoT Hub. This is the layer IoT Central always sat above, so the underlying transport story is familiar. The difference is that you now own it directly.
  • Device onboarding and provisioning → Device Provisioning Service. Also pre-existing and well documented. The lift is that your enrollment logic becomes yours to write, version and test.
  • Device inventory and governance → Azure Device Registry, in preview. This is the genuinely new piece. It brings devices into the Azure management plane as ARM resources, which promises more consistent governance across connected environments. It is also in preview, which is the part a risk register should note.
  • Rules, automation and integration → message routing, Event Grid, Functions, Fabric Activator. An IoT Central rule engine becomes distributed Azure primitives. Simple threshold rules inflate into event routing plus compute plus an activation layer.
  • Dashboards and analytics → Microsoft Fabric Real-Time Intelligence, Power BI. The managed dashboard experience is replaced by a real-time analytics stack you assemble.

The pattern is consistent: every convenient abstraction is exchanged for a set of composable services you must assemble, secure and operate. For a team that chose IoT Central precisely to avoid that assembly, this is a change in kind rather than degree.

Microsoft has pushed two pieces of scaffolding. There is a Fabric solution accelerator on GitHub that deploys an end-to-end Fabric Real-Time Intelligence workload on top of existing IoT Hub telemetry — Eventstream ingestion, an Eventhouse with KQL, and ready-to-use real-time dashboards. And there is a customer migration playbook that maps common IoT Central scenarios to Azure IoT-native services. Microsoft also named two migration partners: Mesh Systems, which builds on Azure IoT Hub and Azure IoT Operations, and Helin, which delivers an intelligent edge application platform for industrial AI on IoT Hub, DPS, Azure Device Registry and Fabric.

Why This Is a Platform Story, Not a Product Story

Two details in the announcement are more consequential than the retirement date itself.

The first is where the intelligence layer goes. Microsoft's target architecture routes dashboards and analytics into Microsoft Fabric, and the accelerator described in the post is built around Fabric Real-Time Intelligence with an operations agent. The company frames this as connected operations — operational technology, enterprise data, analytics and AI converging on one platform — and says it is moving customers from monitoring toward real-time intelligence and automation. Read plainly, telemetry is being positioned as the fuel for a data-and-AI layer rather than the end product of an IoT application. A utility meter, a cold-store sensor and a factory gateway become data sources feeding analytics workloads.

The second is the governance story. Azure Device Registry representing devices as ARM resources is a real architectural change, because it means device identity, policy and lifecycle inherit the same role-based governance model as the rest of an Azure estate. That is the strongest argument in Microsoft's favour: consistency of governance across a mixed connected environment is genuinely hard, and doing it through a device-specific special case is a tax. The cost is that the capability is in preview.

The Backstory: A Retirement Date That Already Moved Once

This is not the first time IoT Central has been on notice. In February 2024, Microsoft announced that IoT Central would be retired, with the widely reported position that existing applications would continue to function through a 2027 sunset — a position The Register covered at the time, and which connectivity vendors in the space, Davra among them, documented for their customers. The sunset date has since moved to 2029.

That history is worth sitting with. It means the announced 2029 date carries a track record of slipping, which cuts both ways: teams who planned a rushed 2027 migration overpaid for panic, and teams who assumed 2027 was firm now have a real, dated deadline with published guidance behind it. It also explains why the announcement is framed as "evolving" rather than "retiring." Microsoft had already spent credibility once on this product. The current messaging is careful — existing applications keep working, the roadmap is on Azure IoT Hub, and the transition is presented as a natural next step.

For IoT buyers elsewhere on news.jualin.id's IoT desk, the wider pattern is now familiar. Managed-application convenience in IoT has been retreating across the board — a recurring theme we tracked in our coverage of edge AI shifting onto the module and the industry's long migration away from turnkey application layers. The direction of travel is toward platforms you assemble, with the productivity gains expected to come from AI-assisted operations rather than from a simpler UI.

What Operators Should Do Now

Microsoft's own four-step framing is a reasonable starting point, and the ordering matters more than the wording.

  1. Inventory the current deployment. Device templates, device groups, jobs, rules, exports, dashboards and users. The exports and the rules engine are where the undocumented dependencies hide, because both are easy to configure and rarely documented outside the tenant.
  2. Evaluate the target architecture. IoT Hub plus DPS as the connectivity core, Azure Device Registry where it applies, Fabric for analytics. Assume the device-registry dependency stays in preview for the life of the migration and plan accordingly.
  3. Phase the work. Run IoT Central and the new path in parallel. Shadow telemetry from a subset of devices into the Fabric workload and compare before you trust it with production.
  4. Use the playbook and the accelerator rather than rebuilding pipelines from scratch, and bring in a partner if the assembly work exceeds the team's current platform bandwidth.

Two practical warnings. First, certificate management is one of the named IoT Hub capabilities that becomes newly relevant, which usually means credential rotation work that a managed application quietly abstracted. Budget for it. Second, cost models shift: managed per-application pricing gives way to consumption pricing across Hub messaging, Functions invocations, Event Grid events and Fabric capacity. A fleet that looked cheap under IoT Central may not look cheap after the migration, and that arithmetic should be done before the commitment, not after.

Conclusion

Azure IoT Central is not being switched off next week. It is being switched off on September 20, 2029, for anyone who has not left before then, and the door for new applications closed on September 23, 2026. The message Microsoft is sending is that the managed application was a waypoint, not a destination — that the durable value now lives in IoT Hub, Device Provisioning Service, Azure Device Registry and Fabric, and that a connected estate should be governed like any other cloud resource.

That argument is largely credible, and the platform underneath IoT Central has genuinely improved. It is also a large amount of work, spread across provisioning, rules, dashboards and governance, that used to be one tenant. The organizations with the smoothest migration will be the ones that treat the next three years as a re-platforming programme with real dependencies on preview services, not as a compliance checkbox.

For the broader cloud and edge story, the takeaway is that managed application layers keep getting disassembled into platforms. The winners will be the builders who can assemble; the ones who chose convenience will now pay for it.

Images

A smart meter gateway mounted on a DIN rail inside a service cabinet, the kind of edge hardware that has to survive an IoT backend migration untouched. Illustrative photograph.

A DIN-rail smart meter gateway unit inside a utility service cabinet, surrounded by wiring and terminal blocks

An open equipment rack holding network switches and cabling — the ingest side that an IoT Central tenant always hid, and now has to assemble and operate directly. Illustrative photograph.

Close-up of an open rack containing network switches, patch panels and cabling with status lights illuminated

References