---
title: "Azure Communication Services Retirement: The 2028 Guide"
slug: azure-communication-services-retirement-the-2028-migration-guide
date: 2026-09-24
author: Roopendra Talekar
categories: [General]
excerpt: "Azure Communication Services retires as a standalone offering on September 30, 2028, and new signups close October 23, 2026. Here is what breaks."
tldr: "Microsoft retires ACS as a standalone offering on September 30, 2028. Email, SMS, Chat, WhatsApp, PSTN and the UI Libraries go outright. Calling survives only alongside Teams."
canonical: https://clonepartner.com/blog/azure-communication-services-retirement-the-2028-migration-guide
---

# Azure Communication Services Retirement: The 2028 Guide


Azure Communication Services retires as a standalone offering on **September 30, 2028**. Microsoft announced it in September 2026, which gives you a two-year transition window and not a day more. There is a second, much nearer date most teams miss: beginning **October 23, 2026**, new customers cannot sign up for the retiring services.

This is not a uniform sunset. Microsoft split the portfolio in two. Email, SMS, Chat, WhatsApp, PSTN Direct Offer, Direct Routing, Rooms, Job Router and both UI Libraries are **retired** — gone, with API operations that depend on them returning errors. Voice and Video Calling, Call Automation, Call Recording, Audio Streaming, Call Diagnostics and Closed Captions are **breaking changes** — they survive, but only when paired with a Teams-aligned service, and only on a new major SDK version.

That distinction determines whether your migration is a replacement project or a rewrite project. This guide covers the exact timeline, which bucket each service falls into, what "supported" actually means after the date, the licence costs that arrive with the Microsoft-aligned paths, and the three realistic options in front of you.

## The September 30, 2028 Hard Deadline

> [!CAUTION]
> **Two dates, not one.** From **October 23, 2026**, new customers cannot sign up for the retiring ACS services — and tenants creating their first ACS resource after the September 2026 announcement are not eligible to request phone numbers at all. On **September 30, 2028**, retired services are permanently removed. Microsoft states this applies even when you use a retired product alongside a service that survives.

Here is the official timeline:

| **Date** | **Event** |
| --- | --- |
| **September 2026** | Microsoft announces ACS retirement and breaking changes; existing resources unaffected for now |
| **September 2026** | Customers without existing ACS phone numbers can no longer acquire new ones; short code registration closes for new resources |
| **October 23, 2026** | **New customers can no longer sign up for retiring ACS services** |
| September 2026 – September 30, 2028 | Two-year transition. Support, security updates and bug fixes continue per your Azure support plan. No new feature development. |
| **September 30, 2028** | **ACS retired as a standalone offering. Retired services removed; breaking-change services supported only with a Teams-aligned pairing** |
| After September 30, 2028 | Supporting data and telemetry for retired and standalone services is decommissioned |

Read the middle of that table carefully. The two-year window is explicitly a maintenance window. Microsoft says the engineering team is focused on "supporting existing functionality and critical security and stability updates" and that it cannot commit to new feature development. Upstream dependency changes — Fluent, React, .NET, Chrome, iOS, Android — are treated as break-fix problems you file a support ticket for. If your product roadmap assumed ACS would keep pace with the platforms it runs on, that assumption expired in September 2026.

The authoritative source is Microsoft's [retirement and breaking changes guide for Azure Communication Services](https://learn.microsoft.com/en-us/azure/communication-services/acs-retirement-and-breaking-changes-guide), which is the document every claim in this post traces back to.

### The October 2026 Date Is Sharper Than It Looks

"New customers can't sign up" sounds like somebody else's problem. It is not, for three reasons.

First, "new customer" is scoped to the ACS resource, not the Azure account. A tenant that has been on Azure for a decade but creates its first ACS resource after the announcement is a new customer for this purpose — and specifically is not eligible to request phone numbers.

Second, the phone number restriction has already landed. Microsoft states that after the September 2026 announcement, customers who do not have existing ACS phone numbers can no longer acquire new ones. The Phone Numbers option stays visible in the Azure portal, but acquisition is greyed out for new resources because they carry zero initial phone-number usage.

Third, it kills the obvious workaround. Teams sometimes plan to spin up a fresh, clean ACS resource to stage a migration against. After October 23, 2026, that resource cannot acquire numbers, cannot register short codes, and cannot initiate a port-in. **Your staging environment has to be built from the resources you already own.**

## Why Microsoft Is Retiring ACS

Microsoft's stated reason is strategic rather than technical. The retirement "reflects our evolving strategy to prioritize deeply integrated communication experiences within Microsoft platforms, specifically Teams, Dynamics 365, and Azure, while working with leading Communications Platform as a Service (CPaaS) providers to fill gaps and accelerate innovation for Azure customers."

Translated: Microsoft is getting out of the general-purpose CPaaS business and pushing communication back into products it already monetises per seat. ACS was a developer primitive — an SDK and a consumption bill. Teams Phone, Dynamics 365 Contact Center and Microsoft 365 are licensed products with a per-user price and an admin centre.

The second half of that sentence matters more than the first. Microsoft explicitly points customers at third-party CPaaS providers to "fill gaps," and its own migration recommendations table carries a partner column. A vendor that had a first-party replacement for every retiring capability would not publish a partner list. The gaps are real and Microsoft is saying so in its own documentation.

The partner names are not interchangeable, and it is worth reading that column row by row rather than as a list. Infobip appears against most retiring services and Telesign against most of them; Luware and Talkdesk appear on exactly one row — Job Router — where the Microsoft alternative is Dynamics 365 Contact Center. Which partner is relevant to you depends entirely on which primitive you are replacing.

You can see this most clearly in SMS. The migration recommendations table has a column for Microsoft alternatives, and for SMS that column contains a dash. There is no Microsoft product to move to. Infobip and Telesign are the listed options.

### The Shape of the Replacement Map

Microsoft's own table is the clearest statement of what is on offer:

| **Retiring service** | **Microsoft alternative** | **Licence required** | **Named third parties** |
| --- | --- | --- | --- |
| Email | Microsoft 365 High Volume Email (internal), Exchange Online | Microsoft 365 licence | Infobip, Telesign |
| SMS | — | — | Infobip, Telesign |
| Chat (incl. Teams interop) | Microsoft Graph Chat APIs | Teams licence | Infobip |
| WhatsApp / Advanced Messaging | Dynamics 365 Contact Center | Dynamics 365 licence | Infobip, Telesign |
| PSTN (Direct Offer) | Teams Phone Extensibility, Teams Calling Plan, Teams Direct Routing, Operator Connect | Teams and Teams Phone licences | Infobip, Telesign |
| Direct Routing | Teams Phone Extensibility, Teams Direct Routing | Teams and Teams Phone licences | Infobip, Telesign |
| ACS Rooms | Teams Meeting interoperability, Microsoft Graph APIs | Teams licence | Infobip, Telesign |
| UI Library (Web and Mobile) | — | — | — |
| Job Router | Dynamics 365 Contact Center | — | Luware, Talkdesk |
| Voice and Video Calling SDK | Teams Meeting interoperability | SDK change; applicable Teams licence | Infobip, Telesign |
| Call Automation | Teams Phone Extensibility, for documented scenarios | SDK change; Teams and Teams Phone licences, resource-account config, PSTN connectivity | — |

Two rows have a dash in both the Microsoft column and the partner column: the Web and Mobile UI Libraries. There is no replacement offered for the front end. Microsoft's position is that the library remains open source through September 30, 2028, that it will not proactively drive or accept upstream changes during that time, and that if you require ongoing evolution or dependency modernisation you should fork and maintain it independently.

**If your product ships the ACS UI Library to end users, plan on owning that code yourself or rebuilding the interface.**

## What Breaks: Retired Versus Breaking Change

The single most important thing to get right before budgeting is which bucket each of your workloads sits in.

### Fully Retired After September 30, 2028

These are permanently removed from Azure. API and SDK operations that depend on them may return errors indicating the operation is not supported:

- ACS Email
- ACS SMS
- ACS Advanced Messaging with WhatsApp
- ACS Chat
- ACS Chat for Teams Meeting Interop
- ACS Rooms
- ACS Number Management (Direct Offer)
- ACS Direct Routing
- ACS Job Router
- ACS Web UI Library SDK
- ACS Mobile UI Library SDK

Note the second entry on that list. ACS Chat for Teams Meeting Interop is retired even though Teams interoperability itself survives as a supported calling scenario. Being adjacent to Teams does not exempt a service from retirement. Microsoft says this directly about the UI Library too: Teams interoperability scenarios continue to be supported as a calling experience, but the UI Library is in retirement scope regardless.

### Breaking Change: Survives, But Not As You Use It Today

These remain available after September 30, 2028:

- ACS Voice/Video Calling SDK
- ACS Call Diagnostics
- ACS Call Automation
- ACS Call Recording
- ACS Audio Streaming
- ACS Closed Captions

The word "available" is doing a lot of work. Microsoft's framing is that after the date these services "will be supported only when used with a supported Teams-aligned service. Standalone ACS scenarios that don't integrate with Teams, including human-to-human and application-to-human communications, will no longer be supported."

There are exactly three qualifying pairings:

- Microsoft Teams Phone Extensibility (TPE)
- Microsoft Teams Meeting Interoperability
- Microsoft Teams Click-2-Call for Teams Voice Apps

> [!WARNING]
> **"Breaking change" is not the safe bucket.** If you run an application-to-human calling workload — outbound notifications, IVR, an appointment reminder bot — with no Teams identity anywhere in the flow, the breaking-change bucket is functionally a retirement for you. You must either introduce a Teams-aligned pairing with its licensing and resource-account configuration, or leave for another provider. Microsoft also states explicitly that connecting Call Automation to Cognitive Services or another AI service does not, by itself, qualify a standalone workload for support.

### The SDK Version Tell

There is a mechanical signal for which SDKs are affected. Microsoft says SDKs containing breaking changes will indicate it with a new major version number — 4.x.x instead of 3.x.x — and that if you plan to use an affected service after September 30, 2028 you must update to the latest major version.

Existing SDK versions keep working and stay supported through the two-year window. So the practical sequencing is: you have until September 30, 2028 on your current major version, and the new major version is where the Teams pairing requirements actually bite. Do not treat the SDK upgrade as a routine dependency bump scheduled for the last quarter. It is the migration.

## What "Supported" Actually Means After the Date

This is where teams get burned, so it is worth being precise. Microsoft repeats a version of the same caveat across the guide, and it amounts to: eligibility is not parity.

The exact language on Call Automation: "An eligible integration path doesn't guarantee feature parity with standalone ACS or with another Teams integration. The supported call types, participants, operations, SDKs, licenses, and policies depend on the scenario."

And on the three integration paths, the guide draws sharp boundaries:

| **Teams integration path** | **What it covers** | **What it does not establish** |
| --- | --- | --- |
| Teams Phone Extensibility | Call Automation with Teams Phone; inbound/outbound PSTN, participant and media controls, ACS Call Recording, audio streaming to a WebSocket, real-time transcription | Not every Call Automation operation or media mode; requires Teams resource-account configuration, licensing and PSTN connectivity |
| Teams Meeting interoperability | Client-side Calling SDK participation in Teams meetings | Does not establish support for Call Automation meeting control, ACS recording, server-side WebSocket streaming, or Call Automation transcription |
| Click-to-Call for Teams Voice Apps | Client-side calls into a Teams Auto Attendant or Call Queue | Not a general replacement for Call Automation workflows; does not establish server-side recording, streaming or transcription |

Read the middle row again. A team that says "we already do Teams interop, so our calling stack is fine" has established support for *joining meetings* and nothing else. If that same stack records calls server-side or streams audio to a bot, those capabilities need to be validated separately against the [Teams Phone Extensibility capability matrix](https://learn.microsoft.com/en-us/azure/communication-services/concepts/interop/tpe/teams-phone-extensibility-capabilities).

Microsoft's own instruction is to map each part of your solution to its documented integration surface, verify the supported endpoint and participant types, SDK version, permissions, licensing and feature limitations for every required operation — and if the documentation does not cover your configuration, contact Azure support before relying on it. That is a per-capability audit, not a per-product one. Budget for it.

Closed captions gives a concrete example of how thin the parity can get. Microsoft warns not to assume every eligible Teams integration supports captions, and points out that the TPE capability matrix currently lists an agent turning on Teams closed captions as unsupported. Translated captions additionally require a Teams Premium entitlement.

## The Hidden Costs Nobody Budgets For

The engineering rewrite is the visible cost. These four are the ones that show up late.

### Licences You Did Not Previously Need

ACS was consumption-billed. You paid for messages sent and minutes used. Every Microsoft-aligned destination in the migration table carries a licence requirement instead, and Microsoft states plainly that you "might incur additional service costs, licensing costs, or both."

The requirements column of that table is the shopping list: a Microsoft 365 licence for Email, a Teams licence for Chat and Rooms, Teams and Teams Phone licences for PSTN and Direct Routing, a Dynamics 365 licence for WhatsApp and Job Router. For Call Automation on TPE, Microsoft additionally names resource-account configuration and PSTN connectivity as requirements.

For a developer-platform company, this is the expensive surprise. An ACS Chat workload serving 50,000 end users cost you consumption. The Graph Chat path requires those conversations to run under Teams identity and licensing — which is a fundamentally different commercial shape, and for a consumer-facing product usually not a viable one at all. That specific mismatch is the subject of [the ACS Chat to Microsoft Graph migration guide](https://clonepartner.com/blog/blog/acs-chat-to-microsoft-graph-migration-identity-mapping-history-cutover).

### The Recording Retention Trap

Built-in ACS call recording storage is temporary. Recording files are available to download for **24 hours**. Microsoft's instruction is to retrieve and archive the files and associated metadata within that window and not to wait until September 30, 2028.

This is true today. It is not a retirement-era behaviour. Teams discover it during a retirement audit because that is the first time anyone reads the recording documentation closely, but the 24-hour window has always been the contract. Migrating to Teams Phone Extensibility does not change it: built-in recording files still have a 24-hour download window, and TPE does not make temporary storage a permanent archive or automatically migrate previously recorded files.

Recordings already saved to your own Azure Blob Storage are unaffected — the transition does not delete them or restrict access, and they follow your storage account's own permissions, retention, lifecycle policies and charges. [Bring Your Own Storage](https://learn.microsoft.com/en-us/azure/communication-services/quickstarts/call-automation/call-recording/bring-your-own-storage) is the durable fix, and [the full data export picture](https://clonepartner.com/blog/blog/azure-communication-services-data-export-before-decommission-recordings-chat-telemetry) covers how to prove an export is complete.

### Orphaned Phone Number Charges

A small operational note in Microsoft's guide with a real bill attached: remove ACS phone numbers before deleting an ACS resource. If numbers are not removed first, charges can continue on orphaned numbers, and a support ticket is required to resolve it.

This is exactly the kind of thing a decommissioning sprint gets wrong. Resource deletion feels like the last step. It is not — number release comes first, and releasing a number for a port-out requires a Microsoft support ticket of its own.

### The Porting Timeline

Number porting is the longest-lead item in any ACS exit, and it is the one with the worst rollback story. Microsoft's own comparison table says it directly about Teams Calling Plan: "Rollback can be difficult after number port completion." Verification status is managed by the receiving provider, so re-verification with an SMS aggregator may be required, and Microsoft warns that migrating ACS numbers to another provider "requires re-verification with an SMS aggregator and might cause downtime."

Short codes are worse. Provisioning involves external providers and regulatory review, so timelines vary, and Microsoft's advice is to engage your chosen provider early. The numbers, SMS and Email exit sequence gets its own treatment in [the ACS phone numbers, SMS and Email exit guide](https://clonepartner.com/blog/blog/acs-phone-numbers-sms-email-exit-guide-october-2026-cutoff).

## Your Three Migration Options

Every ACS workload resolves to one of three paths. Most estates use more than one.

### Option 1: Move to the Teams-Aligned Microsoft Path

**Best for:** Enterprise workloads whose participants are already Microsoft 365 users, guests or supported external users, and whose organisation wants those conversations under Teams governance.

This is the path Microsoft is steering you toward, and for the right workload it is genuinely the lowest-risk option. Chat moves to the Microsoft Graph Chat APIs. Calling moves to Teams Meeting interoperability. PSTN and Call Automation move to Teams Phone Extensibility, Teams Calling Plan, Teams Direct Routing or Operator Connect. Job Router and WhatsApp move to Dynamics 365 Contact Center. Rooms moves to Teams Meeting interoperability and Graph.

**What it involves:** Entra app registrations and least-privileged Graph permissions with admin consent. Teams policy review with your tenant administrators. Licence procurement. New major SDK versions for anything in the breaking-change bucket. Resource-account configuration and PSTN connectivity for TPE. A capability-by-capability validation against the TPE matrix.

**Where it fails:** Identity. Teams-aligned paths require Teams-shaped participants. If your application creates its own users, issues its own tokens, serves anonymous visitors, or ships a white-label client that must not look like Teams, this path does not fit — and Microsoft says so in its own fit checklist.

**Risk:** Governance, not code. The engineering is tractable. The delay usually comes from tenant administrators, compliance owners and security reviewers who now have a say in a system that used to be entirely yours.

### Option 2: Move to a Third-Party CPaaS

**Best for:** SMS, transactional and bulk email, WhatsApp outside Dynamics, anonymous or consumer-scale chat, and any application-to-human calling workload with no Teams identity in it.

Microsoft points at the [Microsoft Marketplace](https://marketplace.microsoft.com/) generally and names specific partners per service: Infobip and Telesign against Email, SMS, WhatsApp, PSTN, Direct Routing, Rooms and the Calling SDK; Infobip alone against Chat; Luware and Talkdesk against Job Router. Match the partner to the primitive, not to the vendor. For SMS there is no Microsoft alternative listed at all, so this is not really an option — it is the only destination.

**What it involves:** Provider selection, commercial negotiation, number porting with its support-ticket and re-verification steps, sender identity re-establishment (domain verification for email, 10DLC or short code registration for SMS), and an application rewrite against a new API surface.

**What to watch:** Microsoft has not published a migration path from 10DLC to Microsoft Teams, and states that any future updates will be communicated through the retirement document. If you have invested in 10DLC campaign registration and campaign branding, treat a third-party CPaaS as your assumed destination rather than waiting for a Microsoft route that has not been announced.

**Risk:** Deliverability and verification, more than code. Porting a number is mechanical. Rebuilding sender reputation, campaign registration and verification status with a new aggregator is not, and it is the part that causes visible customer-facing failures.

### Option 3: Redesign the Experience

**Best for:** Products where ACS was a build-vs-buy decision that has now been re-opened by the vendor.

Microsoft's own guidance uses the phrase "redesign the experience" for chat workloads that cannot move to Teams. It applies more broadly. If you built custom in-app chat, a custom meeting room, or a custom queueing layer because no platform offered it in 2022, the honest question in 2026 is whether your helpdesk, CRM or contact centre platform now ships that capability natively.

Job Router is the clearest case. Microsoft's alternative is Dynamics 365 Contact Center, with Luware and Talkdesk as partners. If you built routing on Job Router because your contact centre platform could not do it, and it now can, the retirement is a forcing function to delete code rather than port it.

The engineering here is often smaller than Options 1 and 2. The data migration is usually larger, because consolidation means moving history between systems rather than between APIs. We have written on [why separating migration from implementation reduces risk](https://clonepartner.com/blog/blog/data-migration-vs-implementation-guide), and that separation matters most on this path.

## The Three Workstreams You Cannot Defer

Underneath whichever option you pick, three pieces of work have deadlines that are earlier or harder than September 2028.

**Chat identity and history.** ACS Chat is fully retired, and Microsoft describes its named alternative — the Graph Chat APIs — as a different offering rather than an equivalent one: Graph is usually not a direct replacement where your application requires anonymous or application-defined identities, a white-label embedded client, or consumer-scale chat outside Teams. Every continuing user needs an approved Microsoft Entra identity mapping, historical import runs under a separate privileged migration workflow, and some populations have no Microsoft path at all. This is a scoping exercise, not a port.

**Data export.** Microsoft confirms chat messages, call recordings and Azure Monitor telemetry will be available for export, and that after the retirement date the supporting data and telemetry for retired and standalone services is decommissioned. Recordings are the urgent one because of the 24-hour window that applies right now.

**Numbers, SMS and Email.** The longest lead times and the worst rollback characteristics in the programme, gated by an October 2026 restriction that has already partly landed.

Each of those is covered in depth in its own post in this series. At pillar level, the only thing you need to internalise is the sequencing: numbers first because porting is slow and irreversible, recordings immediately because the window is 24 hours, chat history before you decommission, and the SDK rewrite last because it depends on decisions made in the other three.

## The Full Migration Checklist

Work through this in order. The early items are cheap and the late ones depend on them.

1. **Run the [Azure Advisor](https://learn.microsoft.com/en-us/azure/advisor/advisor-overview) Service Retirement workbook** (Azure portal > Advisor > Service Retirement) and export impacted resources to CSV. Cross-check against Cost Management and Billing for resources with usage but no active deployment.
2. **Classify every workload** as retired or breaking change against Microsoft's impacted services table. These are different projects with different budgets.
3. **Record the identity model per workload** — Microsoft 365 users, guests, external users, anonymous, or application-defined. This single attribute determines whether the Teams-aligned path is even available to you.
4. **Audit call recording retention today.** Confirm every recording either lands in your own Blob Storage or is retrieved inside the 24-hour window. Do not let this wait for the migration project.
5. **Inventory phone numbers, short codes, verified email domains and 10DLC campaigns**, with their current verification status and the provider that holds it.
6. **Price the licences** for each candidate destination — Microsoft 365, Teams, Teams Phone, Dynamics 365 — against your current ACS consumption bill. Do this before the architecture review, not after.
7. **Open porting conversations with destination providers** early. Releasing a number from ACS requires a Microsoft support ticket, and porting to Teams Phone Extensibility requires releasing it from ACS first.
8. **Stand up one pilot workload** on the new major SDK version paired with a Teams-aligned service, and validate every required capability against the TPE capability matrix rather than assuming parity.
9. **Export chat history, recordings and Azure Monitor telemetry** to storage you control, and reconcile counts against the source.
10. **Remove phone numbers before deleting any ACS resource.** Orphaned numbers keep billing and need a support ticket to clean up.
11. **Set an internal deadline of the first half of 2028**, not September. Porting schedules and tenant-side approvals are outside your control.

> [!NOTE]
> **Compliance and data note.** Microsoft confirms that all services maintain their existing compliance certifications — HIPAA, SOC 2, GDPR — through the transition, and that current SLAs and uptime guarantees remain. What changes is where the obligations live afterward. Moving chat into Teams moves retention, eDiscovery, DLP and legal hold under Microsoft Purview and tenant policy rather than your Azure resource configuration. Moving to a third-party CPaaS moves data residency, retention and export controls to that provider's terms. Have your compliance owner sign off on the destination's posture before the data moves, not after. Our [GDPR-compliant data migration blueprint](https://clonepartner.com/blog/blog/gdpr-compliant-data-migration-the-enterprise-blueprint) covers the documentation this generally requires.

## When to Bring In Help

If ACS is one primitive in one product — an SMS notification service, say, with a few hundred numbers and no history worth keeping — this is a DIY job. Pick a CPaaS partner, port the numbers with enough lead time, rewrite the send path, and you are done in a few sprints. You do not need a migration vendor for that, and you should be sceptical of anyone who tells you otherwise.

The picture changes when ACS is load-bearing across several products at once. A typical affected estate has calling in one application, chat in another, SMS notifications wired into a CRM, recordings feeding a compliance archive, and a UI Library forked into a customer-facing front end. Those five have five different destinations, five different licence implications, and one shared deadline.

Separate two decisions that teams routinely bundle: **who owns the communication runtime after migration**, and **who preserves the data and relationships underneath it**. The first is an architecture decision about Teams versus CPaaS versus redesign, and it belongs to your engineering leadership and your Microsoft account team. The second is a data problem — chat history with author attribution intact, recordings with their metadata, telemetry that has to survive an Azure Monitor decommission, and identity mappings that have to reconcile against the source.

At ClonePartner we work on the second one. Across 1,500+ migrations and 500+ integrations, the pattern we see is consistent: the runtime cutover is scoped well and the data underneath it is scoped late. Conversation history, attachments, participant mapping, recording metadata and the audit trail proving the export was complete are the items that slip, because they are invisible until someone asks for a record that is no longer there.

We are typically brought in when history has to remain searchable after the source system is gone, when chat or ticket data has to land in a different platform than the one the runtime moves to, when identity mapping between ACS users and Entra users is non-trivial, or when a compliance owner needs reconciliation evidence rather than an engineer's assurance.

If your ACS footprint is a single primitive with no history, do it yourself. If it spans products and the data has to outlive the platform, get the data workstream scoped separately and early.

> Planning your exit from Azure Communication Services before September 2028? We scope the data layer — chat history, call recordings, telemetry and identity mapping — so it survives the runtime cutover intact. Book a 30-minute call and we will map your ACS footprint against the retirement buckets together.
>
> [Talk to us](https://cal.com/clonepartner/meet?duration=30&utm_source=blog&utm_medium=button&utm_campaign=demo_bookings&utm_content=cta_click&utm_term=demo_button_click)

## Frequently asked questions

### When does Azure Communication Services retire?

Microsoft announced in September 2026 that Azure Communication Services retires as a standalone offering effective September 30, 2028. Separately, beginning October 23, 2026, new customers cannot sign up for the retiring services. Resources created before that date keep working through the two-year transition period.

### Is all of Azure Communication Services being deleted?

No. Microsoft splits the portfolio in two. Email, SMS, Chat, WhatsApp, PSTN Direct Offer, Direct Routing, Rooms, Job Router and both UI Libraries are retired outright. Voice and Video Calling, Call Automation, Call Recording, Audio Streaming, Call Diagnostics and Closed Captions survive as breaking changes.

### What does "breaking change" mean for ACS calling?

The service stays available after September 30, 2028, but only when used with a supported Teams-aligned service — Teams Phone Extensibility, Teams Meeting Interoperability, or Click-to-Call for Teams Voice Apps. Standalone scenarios that do not integrate with Teams become unsupported, and you must move to a new major SDK version.

### What replaces ACS SMS?

Microsoft does not offer a replacement. The migration recommendations table lists no Microsoft alternative for SMS at all — only third-party Marketplace partners, Infobip and Telesign. If you send SMS through ACS today, your destination is a third-party CPaaS provider, not another Microsoft service.

### Do I need to export my ACS data before the retirement date?

Yes. Microsoft states that data such as chat messages and call recordings, plus operational telemetry in Azure Monitor, will be available for export, and that after the retirement date the supporting data and telemetry for retired and standalone services is decommissioned. Built-in call recordings have a far shorter 24-hour download window.