Hello @Reganti Naday Kumar
For this requirement, the Microsoft Lifecycle Data Export is currently the most appropriate Microsoft-published source for automation. Microsoft provides the Lifecycle product search and an export containing lifecycle information such as product, edition, release, support policy, start date, mainstream support date, extended support date, retirement date, release end date, and documentation URL.
Microsoft Lifecycle Data Export
Regarding your specific questions:
- Official API: I don't see a publicly documented/supported Microsoft Lifecycle REST API for retrieving the complete Product Lifecycle dataset. I would therefore avoid depending on undocumented endpoints used internally by the Lifecycle website.
- Change notifications/webhooks: I also don't see Microsoft documenting a webhook or event-based notification service specifically for changes to the Lifecycle dataset.
- Lifecycle Data Export: Yes, Microsoft provides the official Product Export and documents the structure of the exported lifecycle data. However, I don't see a documented SLA stating that the export is regenerated immediately after every lifecycle change. I wouldn't design an automation that assumes real-time synchronization unless Microsoft confirms that behavior.
- RSS: I don't see an official RSS/Atom feed specifically covering every change made to the Product Lifecycle dataset. Microsoft does publish Lifecycle announcements, but that isn't equivalent to a machine-readable change feed for the entire dataset. The Lifecycle site currently surfaces announcements alongside its product lifecycle information.
- Recommended automation: Without a documented API/webhook, I would periodically retrieve the official Lifecycle Data Export, normalize the relevant columns, and compare it with the previous successful snapshot.
For example:
I would store the previous dataset rather than only checking whether the export file itself changed. That allows you to generate useful notifications such as:
SQL Server xxxx
Extended Support:
Old: 2030-01-01
New: 2030-06-01
or:
Product XYZ
New retirement date: 2027-10-01
For products under the Modern Lifecycle Policy, I'd supplement this with the appropriate product/service announcement channels. Microsoft states that Modern Policy products can change more frequently and provides notification requirements for changes requiring customer action and for product retirement.
For an enterprise implementation, I would use Lifecycle Data Export as the authoritative baseline, periodically compare snapshots, and supplement it with product-specific channels such as Azure Updates or Microsoft 365 roadmap/communications, where applicable.
I would not scrape the HTML Lifecycle pages or reverse-engineer their internal APIs, since those interfaces aren't documented contracts and could change without notice.
Sharing these references with you:
Microsoft Lifecycle Data Export | Lifecycle Data Export guidance | Microsoft Lifecycle Policy | Modern Lifecycle Policy
Help make this community better for everyone: if this answer resolved your issue, please accept it or leave an upvote. If not, share more details in a comment so we can continue the discussion and find the right solution.