Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
This article explains the lifecycle stages for Azure infrastructure products and features and what you should do at each stage to keep workloads supported.
What are the lifecycle stages for Azure infrastructure products and features?
There are five primary lifecycle stages for Azure infrastructure products and features:
Private preview
Private preview is an invitation-only stage where a limited set of customers can evaluate early functionality and provide feedback before broader release.
In private preview:
- Features might be incomplete and can change significantly.
- Availability is often limited by region, subscription type, capacity, or onboarding requirements.
- Support and documentation might be limited, and there is typically no service level agreement (SLA).
Important
Private preview features aren't intended for production workloads.
Who private preview is generally open to?
Private previews are generally offered to a small, selected set of customers and partners who:
- Have an Azure subscription and can meet any onboarding requirements.
- Have a clear scenario that helps validate the feature (for example, performance, scale, or integration needs).
- Can provide timely feedback and participate in validation (such as surveys, calls, or issue tracking).
- Can meet any legal or compliance requirements (for example, NDA or preview terms), if applicable.
To request access, follow the instructions on the product’s lifecycle or preview announcement page, or contact your Microsoft representative.
Public preview
Public preview is a stage where features are available to all Azure customers to evaluate and provide feedback before general availability.
In public preview:
- Features are more mature than private preview but might still change based on feedback.
- Availability might be limited by region, subscription type, or capacity.
- Support and documentation are more complete than private preview, but there is typically no SLA.
- Service level agreements and production support commitments are not guaranteed.
Important
Public preview features aren't intended for production workloads unless explicitly stated otherwise.
Who public preview is generally open to?
Public previews are generally available to all Azure customers who:
- Have an Azure subscription.
- Can test and provide feedback on the feature.
- Understand the feature is not yet generally available and might change.
- Can meet any applicable terms or conditions for preview features.
General availability (GA)
General availability (GA) is the stage where a feature is fully released and supported for production use by all Azure customers.
In general availability:
- Features are stable and fully tested for production workloads.
- Availability is not restricted by region, subscription type, or capacity (unless stated otherwise).
- Full support and comprehensive documentation are available.
- Service level agreements (SLAs) and production support commitments are guaranteed.
- Features are supported for the duration of their supported lifecycle.
Important
General availability features are fully supported and recommended for production workloads.
Deprecation & Previous-gen
Deprecation is a stage where a feature or product is still available and supported but is being phased out. Microsoft recommends migrating to alternative solutions before the feature reaches retirement.
In deprecation:
- Features remain functional and supported but will not receive new enhancements or improvements.
- Alternatives are available and recommended for new workloads.
- Typical notice period is at least 12 months before retirement.
- Support and documentation continue to be provided.
- Service level agreements (SLAs) remain in effect during the deprecation period.
Important
Deprecation features should be migrated away from as part of your upgrade and migration planning.
Who is affected by deprecation?
Deprecation impacts customers who:
- Currently use the deprecated feature in their workloads.
- Are planning new deployments (should choose the recommended alternative instead).
- Need to update their applications before the retirement date.
Previous-gen
Previous-gen refers to VM sizes that are fully supported but have a replacement that is also generally available. These are older versions of a service that have been replaced by newer or improved alternatives, with Microsoft continuing to support previous-gen VM sizes during their designated lifecycle while recommending upgrades to current versions.
In previous-gen:
- VM sizes are fully supported but may have limitations compared to current versions.
- Support duration is typically limited to a specific timeframe.
- Newer versions with enhanced capabilities are available.
- Migration paths and guidance are provided to help move to current versions.
For example, see Azure Virtual Machine sizes - Previous generation for details on previous-generation VM sizes and recommended current-generation alternatives.
Retirement
Retirement is the final stage where a feature or product is no longer available. After the retirement date, the feature is removed and no longer supported.
In retirement:
- Features are no longer available for new or existing deployments.
- Existing resources using the retired feature might be automatically migrated, disabled, or require manual action.
- Support and updates are no longer provided.
- Service level agreements (SLAs) are no longer applicable.
- APIs or interfaces associated with the feature may be removed.
Important
Retirement features must be migrated away from before the retirement date to avoid service disruption.
Who is affected by retirement?
Retirement impacts customers who:
- Currently use the retired feature in their workloads and have not migrated.
- Have resources that will be affected by the removal of the feature.
- Need to take immediate action to prevent service interruption.
Tip
Subscribe to the product’s update channels so you don’t miss retirement notices.
Your responsibilities
- Review lifecycle notices for the services you use.
- Maintain an upgrade and migration plan.
- Validate changes in test environments before production rollout.