Microsoft's September 25, 2026 IoT announcement explains a transition first announced on September 23: existing Azure IoT Central applications remain available through September 20, 2029, then become unavailable. New application creation has been unavailable since September 23, 2026. Read Microsoft's announcement.
For an existing fleet, this is not an instruction to disconnect devices today. It is a reason to establish a migration owner, understand the operating model you need to preserve, and identify the devices that will be hardest to move.
My recommendation: begin with one complete operator workflow, not just a successful telemetry connection.
The Destination Is a Set of Services
Microsoft recommends Azure IoT Hub, Device Provisioning Service (DPS), and Microsoft Fabric, with Azure Device Registry where appropriate. Its announcement maps connectivity to IoT Hub, provisioning to DPS, and analytics to Fabric Real-Time Intelligence and Power BI. It identifies Azure Device Registry as preview. Recommended platform direction.
That is an architectural transition, not merely a new name for the existing application experience. I would ask the team to identify who will own the connections between services, who maintains the operator interface, and who is called when data stops appearing.
Keep a short decision record for each responsibility. A diagram with all the right service icons is not enough if a support engineer still cannot determine which team owns a failed command or missing dashboard record.
Put Firmware Constraints Near the Start
The migration playbook describes three device paths: DeviceMove with the IoTC Migrator tool, a firmware change to the destination DPS ID scope, or a Microsoft Support review where the scope cannot be changed. The support-assisted path is evaluated case by case, not guaranteed. Device migration options.
My proposed inventory would record the device family, deployed firmware, update mechanism, physical access requirements, and responsible supplier. A fleet count without those details can conceal very different migration lead times.
Choose an awkward but manageable device family for an early investigation. For example, a unit at a remote site with a restricted maintenance window may reveal delivery constraints that a permanently connected lab device never exercises.
Treat an unresolved firmware path as a named project risk. Give it an owner and a next decision date rather than allowing it to disappear inside a broad connectivity workstream.
Telemetry Is Only One Acceptance Test
Microsoft's playbook maps commands to direct methods or desired properties and device-administration screens to custom portals or internal tooling. It also offers a Fabric accelerator for Eventstream ingestion, an Eventhouse/KQL database, and dashboards. Capability mapping and analytics starting point.
For my acceptance test, I would ask an operator to complete an ordinary task without help from the engineer who built the pilot. Can they find the device, understand its latest state, take an authorized action, and explain the result?
Use explicit timestamps and identifiers in the test evidence. If a command appears successful, verify the observed device behavior rather than accepting a button click or queued request as the final outcome.
Also test the information the operator sees when the device is offline. A clear distinction between stale data, missing data, and a failed action is an operational requirement worth recording before the interface is considered complete.
Define the Cutover Boundary
My recommended pilot has a written boundary: the selected devices, the people who may change them, the observation period, and the conditions that stop expansion.
Decide which system is authoritative for each action during the transition. Two dashboards may be useful for comparison, but two independent automation paths issuing the same operational action deserve careful review.
I would give the pilot team a short incident exercise as well. Ask them to diagnose a deliberately simulated missing reading, using nonproduction data and approved test devices. Record which permissions, logs, and contacts they actually need.
The output should be a repeatable operational procedure, not only a technical demonstration. That procedure is what allows the next group of devices to move without depending on the original author being available.
Keep the Deadline Separate from the Project Schedule
The published end date is the outer boundary. My planning recommendation is to choose an earlier internal completion target that leaves room for supplier delays, a failed pilot, and operational handover.
Include application owners and field-support teams when choosing that target. Their calendar may be shaped by factory shutdowns, customer change windows, or equipment access rather than the cadence of a cloud deployment pipeline.
Do not decommission the old operating path just because the new dashboard looks correct. First agree what evidence is needed to close the transition, who accepts it, and how required historical records remain accessible.
Practical Cloud Engineer Takeaway
My proposed first actions are:
Record the creation restriction and the 2029 availability deadline.
Assign an accountable owner for the complete solution transition.
Classify devices by firmware and reprovisioning constraints.
Document responsibilities across connectivity, analytics, and operator tooling.
Prove an operator workflow, including offline and failure behavior.
Define the authority of each system during the pilot.
Agree acceptance evidence and an internal completion target with support teams.
These are planning recommendations, not a claim that a migration has been tested against your fleet.
Who Should Care?
Organizations running IoT Central applications, especially connected-product teams with long-lived devices, remote installations, or custom operational workflows.
Bottom Line
The transition window gives teams time to prepare, but the device and operating-model questions deserve attention now. A successful move preserves the work people need to perform, not just the flow of messages into a new service.
Sources
Stay radical, stay curious, and keep pushing the boundaries of what is possible in the cloud.
Chriz
Beyond Cloud with Chriz
Comments