Microsoft published an Azure update on September 24, 2026, announcing that multiple standalone Azure Communication Services (ACS) offerings will retire on September 30, 2028. Other calling capabilities will face breaking changes and require supported Teams usage and updated SDKs. Read the retirement announcement.
This is not a single package upgrade. For teams using ACS across messaging, calling, and customer-facing applications, it is a dependency review with different outcomes for different parts of the same solution.
My recommendation: start with the customer journey and work backward to the services it uses. A resource inventory alone will not tell you which business process breaks when a capability disappears.
Separate Retirement from Breaking Changes
The retirement list includes Email, SMS, Advanced Messaging with WhatsApp, Chat, Chat for Teams Meeting Interop, Rooms, Number Management (Direct Offer), Direct Routing, Job Router, and the web and mobile UI Library SDKs.
The separate breaking-change group includes Voice/Video Calling SDK, Call Diagnostics, Call Automation, Audio Streaming, Call Recording, and Closed Captions. Microsoft says standalone calling implementations, or implementations that fail to update to the required SDKs, will stop functioning after the deadline. Affected services and required action.
I would label every dependency with one of those two categories before estimating migration work. Replacing an unavailable service is a different project from modifying an application to meet a supported integration contract.
Also distinguish the user interface from the underlying service. A replacement screen does not, by itself, establish that the messaging or calling workflow behind it will remain supported.
There Is an Earlier Date for New Customers
Microsoft's transition guide says new customers cannot sign up for retiring ACS services beginning October 23, 2026. Customers with an ACS resource created before that date can continue using existing resources and retiring services for current workloads during the transition. Official retirement and breaking-changes guide.
My advice for a new project is to review this before committing to an architecture or delivery estimate. A two-year end date should not be read as permission to assume every new deployment remains available on the same terms throughout that period.
For an existing project, record the current resources and verify the applicable guidance with the service owner. Avoid trying to solve uncertainty by creating spare resources or expanding usage without a defined business requirement.
Teams Integration Is Not a Blanket Compatibility Guarantee
For affected calling capabilities, the guide describes supported paths through Teams Phone Extensibility, Teams Meeting Interoperability, and Click-2-Call for Teams Voice Apps. It requires updated major-version SDKs and warns that an eligible integration does not guarantee feature parity. Connecting an AI service alone does not qualify standalone Call Automation for continued support. Retired services do not gain extra life merely because another component uses Teams. Integration boundaries.
That is the section I would put in front of an architecture review. Do not approve a migration based only on the statement that the application already integrates with Teams.
Instead, list each required operation: who initiates the interaction, who participates, what media is involved, which events the application consumes, and what records it must retain. Have the proposed destination demonstrate those operations individually.
An agent-assisted support flow is a useful example. Joining a conversation, routing it, displaying messages, recording audio, and processing events are separate requirements. Evaluate the whole journey, including the failure paths, before calling the replacement equivalent.
Make the Inventory Useful to Application Owners
My proposed inventory would connect each ACS dependency to a repository, environment, business owner, and customer-facing workflow. Include scheduled jobs and background integrations, not only the application people can open in a browser.
For each row, record the migration decision and the evidence still missing. Examples include a required capability demonstration, a deployment dependency, a licensing review, or a retention decision.
Keep unknowns visible. A blank cell is easy to overlook; an explicitly unverified requirement can be assigned to a person and given a review date.
Plan Data and Cutover as Their Own Workstreams
The guide warns that supporting data and telemetry for retired and standalone services will be decommissioned after retirement, and tells customers to export what they need. It also flags potential additional licensing or service costs for supported alternatives. Data and transition considerations.
My recommendation is to define the required records and their destination before changing the live communication path. Test whether an authorized operator can retrieve an exported record and understand its context; a successful export job is only one part of that check.
For cutover, use a representative nonproduction journey first. Verify identity, routing, delivery or connection outcomes, failure handling, and the operational information available to support staff.
Set a clear acceptance threshold and a rollback decision point. A replacement can pass a happy-path demonstration while still leaving the support team unable to diagnose an interrupted interaction.
Practical Cloud Engineer Takeaway
My proposed next steps are:
Inventory ACS dependencies by business workflow, not just resource name.
Separate retiring services from capabilities with breaking changes.
Review the October 2026 restriction before planning new adoption.
Validate the precise Teams scenario and each required capability.
Assign owners for SDK changes, replacement services, and data export.
Review licensing and operational costs before approving the destination.
Rehearse a complete customer journey and its failure paths before cutover.
These are planning recommendations, not a claim that a particular migration path has been tested for your application.
Who Should Care?
Teams using ACS for application email, customer messaging, contact workflows, embedded calling, or communication interfaces, together with the platform owners supporting those applications.
Bottom Line
The deadline is September 2028, but the useful work starts with a precise dependency map now. Separate what is retiring from what can continue under changed requirements, then prove the replacement against the actual customer experience.
Sources
Stay radical, stay curious, and keep pushing the boundaries of what is possible in the cloud.
Chriz
Beyond Cloud with Chriz
Comments