Microsoft defines its Azure instance lifecycle, without any info about timing
Microsoft has introduced a four-stage lifecycle framework for Azure virtual machine instances, defining how they progress from Current (recommended for new deployments) through Extended, End of Life, and Retired statuses. However, the company has not disclosed timing information about how long instances remain in each phase, limiting customers' ability to plan infrastructure transitions strategically.
When asked by The Register about the cadence of these transitions, Microsoft provided only a vague response, confirming it would provide advance notice of End of Life stages and notify customers of specific retirements, but declining to commit to a predictable schedule. Microsoft previously stated it runs Azure servers for six years, though it remains unclear whether the new lifecycle aligns with that hardware retirement cycle. The updates ultimately benefit Microsoft's bottom line: newer VMs use more efficient processors, which offer better density and lower power consumption for the company, whilst customers access more powerful hardware in return.
- Microsoft defined four-stage Azure VM lifecycle without revealing transition timing.
- Company promises advance notice of retirements but offers no predictable schedule.
- Updates benefit Microsoft through processor efficiency whilst customers gain newer hardware.
New here? Start with this
Azure is Microsoft's cloud platform where customers rent virtual machines (computers managed and hosted by Microsoft) to run their applications. These machines have limited lifespans, and Microsoft has just announced a framework defining the stages a machine goes through from launch until retirement.
Microsoft has created four lifecycle stages: Current (newly available and recommended for new deployments), Extended (still available but ageing), End of Life (approaching shutdown), and Retired (no longer accessible). However, Microsoft has not disclosed how long each stage lasts, which makes it difficult for customers to plan when they will need to upgrade to newer machines.
Microsoft benefits because newer machines use more efficient processors that consume less power and occupy less space in its data centres. Without a clear timeline for each stage, customers cannot plan when they will need to budget for infrastructure upgrades.
Both sides, in good faith
The strongest fair case each way — we don't pick a winner.
The case for
The introduction of a structured lifecycle framework represents a genuine improvement over having no defined processes, providing customers with a clear pathway for infrastructure planning. Cloud infrastructure requires flexibility to respond to rapidly evolving hardware and security requirements; rigid timelines could force support of increasingly obsolete systems, creating costs and risks that ultimately harm all customers. Microsoft does provide advance notification before retirement and supports customers through transitions, and the approach aligns with industry practice at major cloud providers who similarly balance predictability with operational necessity. Customers ultimately benefit from access to more efficient hardware, improved cost efficiency, and ongoing innovation.
The case against
Without published timelines, customers cannot effectively plan infrastructure migrations or budget capital expenditures, leaving them uncertain whilst Microsoft retains full knowledge of its roadmap. This opacity creates an asymmetry favouring Microsoft's interests—encouraging faster migrations to newer tiers and optimising infrastructure density—whilst enterprise and public sector customers require substantial planning windows for major architectural changes. Microsoft's reference to six-year hardware lifecycles suggests the company possesses timing knowledge but has chosen not to share it, which differs notably from competitors' transparency practices and suggests disclosure primarily serves Microsoft's business interests. Customers deserve predictable phase lengths enabling genuine planning, rather than being forced to react to Microsoft's unilateral decisions.