---
title: "ACS Phone Numbers, SMS and Email: The October 2026 Exit"
slug: acs-phone-numbers-sms-email-exit-guide-october-2026-cutoff
date: 2026-09-24
author: Roopendra Talekar
categories: [General]
excerpt: "From October 23, 2026 new customers cannot sign up for retiring ACS services, and new resources cannot get phone numbers at all. Here is the exit sequence."
tldr: "ACS SMS, Email and PSTN are fully retired on September 30, 2028, but the squeeze starts October 23, 2026. Number porting is the longest-lead, hardest-to- reverse step — sequence it first, not last."
canonical: https://clonepartner.com/blog/acs-phone-numbers-sms-email-exit-guide-october-2026-cutoff
---

# ACS Phone Numbers, SMS and Email: The October 2026 Exit


Azure Communication Services SMS, Email and PSTN Direct Offer are all fully retired on September 30, 2028. But the practical squeeze starts much sooner: beginning **October 23, 2026**, new customers cannot sign up for the retiring ACS services.

For telephony it has already started. Microsoft states that after the September 2026 announcement, customers who do not have existing ACS phone numbers can no longer acquire new ones — and that tenants creating their first ACS resource after the announcement are not eligible to request phone numbers at all. The Phone Numbers option stays visible in the Azure portal, but acquisition is greyed out for those resources.

That combination makes this the one part of the ACS retirement where the exit sequence matters more than the engineering. Number porting is the longest-lead item, it depends on a Microsoft support ticket and a third-party carrier's schedule, and Microsoft's own guidance notes that rollback can be difficult once a port completes. This guide covers the dependencies in the order you have to resolve them: eligibility, numbers, short codes, SMS, and Email.

## The October 23, 2026 Cutoff

> [!CAUTION]
> **Two restrictions, and the harsher one has no date attached.** From **October 23, 2026**, new customers cannot sign up for the retiring ACS services. Separately, and effective from the **September 2026** announcement itself, tenants creating their first ACS resource are not eligible to request phone numbers, and customers without existing ACS phone numbers can no longer acquire new ones. Short code registration is likewise closed to new ACS resources. Your eligibility was determined by what you already owned when the announcement landed.

| **Date** | **Event** |
| --- | --- |
| **September 2026** | Announcement. Customers without existing ACS phone numbers can no longer acquire new ones; short code registration closes for new ACS resources |
| **October 23, 2026** | **New customers can no longer sign up for the retiring ACS services** |
| September 2026 – September 30, 2028 | Existing customers with existing numbers can continue acquiring more, port numbers in, and use short codes. Verified email domains keep working |
| **September 30, 2028** | **ACS SMS, Email, PSTN Direct Offer and Direct Routing retired** |
| After September 30, 2028 | Supporting data and telemetry for retired services decommissioned |

Everything in this post traces back to 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). The wider scope — what else is retired, and what merely breaks — is in [the ACS retirement pillar guide](https://clonepartner.com/blog/blog/azure-communication-services-retirement-the-2028-migration-guide).

### What the New-Customer Rule Actually Blocks

The phrase "new customers can't sign up" undersells it, because eligibility here is scoped to the ACS resource rather than the Azure account. A tenant that has run Azure for a decade is a new customer for this purpose if its first ACS resource postdates the announcement.

For that tenant, three things are unavailable:

- **Acquiring phone numbers.** The portal option remains visible but the actions are greyed out, because the new resource has zero initial phone-number usage. Microsoft's guidance is to contact support if there is a critical business need, and that options will be reviewed — not that they will be granted.
- **Porting numbers in.** Existing customers with existing ACS resources can port numbers in from external providers during the retirement period. New customers creating new ACS resources cannot initiate a port request into their resource.
- **Registering short codes.** Short code registration is no longer available for new ACS resources following the announcement.

The practical consequence is the one that catches migration teams: **you cannot build a clean new ACS resource to stage or test a telephony migration against.** Whatever rehearsal you do has to happen on the resources you already hold. Plan pilot ranges within existing resources rather than isolated environments.

If you do already hold ACS resources with numbers, you keep more freedom than you might expect. Existing customers can continue to acquire more phone numbers during the two-year window, can still port numbers in, and can keep using and porting their existing short codes. That is a genuinely useful position for staging a phased exit — use it.

## The Exit Sequence and Its Dependencies

The order below is not arbitrary. Each step gates the one after it, and the early steps are the ones with external dependencies you do not control.

1. **Establish eligibility.** Did you hold ACS resources with numbers before September 2026? Everything else branches from this.
2. **Inventory.** Numbers with types and regions, short codes with registration status, verified email domains, toll-free verifications, 10DLC campaigns and their branding.
3. **Select destination providers.** You cannot schedule anything until a destination commits to a porting window.
4. **Port a pilot range.** Small, non-critical, validated end to end on the destination before anything else moves.
5. **Rebuild sending identity in parallel.** Email domain verification, SMS sender registration, toll-free verification at the destination — all of which can run while ACS still works.
6. **Port the main ranges**, in tranches rather than all at once.
7. **Shift application traffic** to the new provider.
8. **Export delivery logs and telemetry.**
9. **Release remaining numbers, confirm billing has stopped, then delete resources.**

Step 4 before step 7 is the part teams get backwards. The instinct is to build the new integration, test it, then port the numbers so traffic flows. But porting is the irreversible step and the one with a third party's schedule attached. Porting a pilot range early tells you what the destination's real timeline and verification requirements are, while you still have months of slack.

> [!WARNING]
> **Porting is where rollback dies.** Microsoft's own comparison table for Teams Calling Plan states that rollback can be difficult after number port completion, and its SMS guidance warns that migrating ACS numbers to another provider requires re-verification with an SMS aggregator and might cause downtime. Treat a port as a one-way door: validate the destination fully on a pilot range first, and never schedule a main-range port in the same change window as an application cutover. If both fail together you cannot tell which one broke, and you cannot undo either quickly. Our notes on [rolling back a failed migration after go-live](https://clonepartner.com/blog/blog/how-to-roll-back-a-failed-migration-after-go-live) apply, with the caveat that number porting is the case where a clean rollback frequently is not available.

## Porting Numbers Out of ACS

### To a Third-Party Provider

The mechanics are split between two parties, and both have to act.

On the destination side, you follow the receiving provider's port-in instructions. Microsoft's guidance is to consult your destination communication provider's documentation on how to port numbers from external providers like ACS. Most carriers require a Letter of Authorization.

On the Microsoft side, you have to ask Microsoft to release the number. That is a support ticket — Microsoft directs you to create one to initiate a port request for it to release your existing number to an external provider — and points to the Microsoft Phone Number Service Portal at [pstnsd.powerappsportals.com](https://pstnsd.powerappsportals.com/) for number management.

Budget for the ticket. It is a queue with a human in it, and it sits on the critical path of every single number you move.

### To Teams Phone Extensibility

If your destination is Microsoft rather than a third party, the sequence has an extra constraint: **you must release the number from ACS before the port move.** Microsoft's instruction is to open a ticket with Service Desk – TNM, through the same Phone Number Service Portal, and the team enables migration of the number.

This is worth flagging because "we're staying with Microsoft, so this should be simpler" is a reasonable assumption and a wrong one. The release-then-port sequence is the same shape as a third-party port, with the same support-ticket dependency.

### Short Codes

Short codes deserve their own plan and their own timeline.

What is true: short codes can be ported out, and Microsoft confirms you contact the carrier you want to port to and that most carriers require an LOA. Existing ACS customers can continue to use their short codes during the supported retirement period and can choose to port them when planning the transition.

What is also true: short code provisioning involves external providers and regulatory review, so timelines vary, and Microsoft's explicit advice is to plan ahead and engage your chosen provider early to confirm expected timelines. New ACS resources cannot register new short codes at all.

If short codes are load-bearing for your business — one-time passcodes, alerting, anything where an alphanumeric sender is not acceptable — start that conversation with your destination provider first, ahead of every other porting conversation. It is the longest pole in an already long tent.

### Do Not Delete the Resource First

A recurring operational trap, worth repeating in every post in this series: remove ACS phone numbers before deleting an ACS resource. If phone numbers are not removed first, charges can continue on orphaned numbers, and a support ticket is required to resolve it.

Decommissioning order is: port or release the numbers, confirm billing has stopped, export your data, then delete. The [ACS data export guide](https://clonepartner.com/blog/blog/azure-communication-services-data-export-before-decommission-recordings-chat-telemetry) covers what needs to come out before that last step.

## SMS: Retired With No Microsoft Alternative

This is the bluntest row in Microsoft's entire migration recommendations table. The Microsoft-alternatives column for SMS contains a dash. There is no Microsoft product to move to. The listed options are third-party Marketplace partners — Infobip and Telesign.

There is one narrow exception, and it is scoped to Dynamics 365. In Microsoft's SMS comparison table, the Dynamics 365 Contact Center column notes that Microsoft will offer equivalent alternative SMS services before the ACS retirement date. If you are a Dynamics 365 Contact Center customer, follow the Dynamics-specific retirement guidance rather than this general path. If you are not, that sentence does not apply to you.

### What You Are Actually Replacing

ACS SMS covered a broad surface, and the replacement has to match the parts you use:

| **Capability** | **ACS SMS today** |
| --- | --- |
| Sender types | Toll-free, short code, 10DLC, mobile/long code, alphanumeric sender ID |
| Reach | 190+ regions via partner network |
| Messaging model | One-way and two-way; group and bulk supported |
| Integration | REST API, SDKs, and Event Grid for inbound and delivery events |
| Availability now | Maintenance mode; new customers blocked from number purchase |

The Event Grid row is the one that generates unplanned work. If your application consumes inbound messages and delivery reports as Event Grid events, that entire event pipeline is ACS-specific. A new provider will deliver the same information over its own webhooks with its own schema, retry semantics and signature scheme — which means the receiving half of your SMS integration gets rewritten, not just the sending half.

### Throughput Is Not Automatically Portable

Worth checking against your actual traffic profile. ACS publishes per-number SMS rate limits in its [service limits documentation](https://learn.microsoft.com/en-us/azure/communication-services/concepts/service-limits): 200 messages per minute for a toll-free number, 6,000 per minute for a short code, and 600 per minute per resource for alphanumeric sender ID.

Your destination provider will have its own numbers, its own scoping (per number, per account, per campaign) and its own approval process for raising them. Compare them against your real peak rather than your average, because the failure mode is a queue backing up during exactly the burst you built the short code for.

## Email: Be Honest That This Is a Downgrade

ACS Email is application-to-recipient email: transactional, bulk and engagement mail to internal and external recipients, sent via REST API, SDKs or SMTP, from an Azure-managed or verified custom domain, with no mailbox required.

Microsoft's named alternatives are Microsoft 365 High Volume Email and Exchange Online. Neither of them is that.

### Microsoft 365 High Volume Email

[High Volume Email](https://learn.microsoft.com/en-us/exchange/mail-flow-best-practices/high-volume-mails-m365) is designed for high-volume operational email sent from apps and devices, using a dedicated HVE account with no mailbox and no licence required. It is the closest thing on the list to ACS Email's operational profile.

The constraint is scope. Per Microsoft's own comparison, HVE's recipients are **internal send, within-tenant**. Its general availability is for internal send, on the Worldwide cloud, not GCC or sovereign clouds. It is SMTP at launch with SDK support planned. There is no tenant recipient-rate cap for internal send, but there is a limit of 50 recipients per message and up to 100 HVE accounts.

If your ACS Email traffic is internal operational mail — system notifications to staff, device alerts, internal reports — HVE is a genuine fit. If you email customers, it is not.

### Exchange Online

Microsoft's own description is the honest one: Exchange Online supports person-to-person business email from licensed user mailboxes for internal and external recipients, subject to tenant limits, and is **designed for user email rather than bulk delivery, with rate limits that vary by design**.

That is not a hedge. It is a statement that the product is built for a different job. Moving a transactional email pipeline onto Exchange Online means sending application mail from licensed mailboxes at rates the platform is designed to constrain.

> [!NOTE]
> **For external transactional and bulk email, the honest answer is a third-party provider.** Microsoft's alternatives table names Infobip and Telesign for Email, and points more broadly at the [Microsoft Marketplace](https://marketplace.microsoft.com/). Between High Volume Email's within-tenant scope and Exchange Online's person-to-person design, there is no Microsoft destination that matches ACS Email's external A2P profile. Say this out loud in your planning rather than discovering it during a pilot, and account for the compliance consequence too: delivery logs, suppression lists and bounce history are records in many regulated contexts, and they live in ACS today. Export them before the retirement date, because supporting data for retired services is decommissioned afterwards.

### Use the Overlap Window

One genuinely helpful fact: verified email domains continue to work as expected and are supported until September 30, 2028. You can also still onboard workloads to new ACS Email resources — though Microsoft notes that availability is subject to change at any time and recommends using the two-year period to migrate off rather than to onboard.

Read that as permission to run both senders in parallel. Email migration is the one workstream in this post where a gradual shift is both possible and strongly advisable, because sender reputation is built over weeks and not switched over in an afternoon. ACS's own guidance for onboarding recommends increasing volume gradually over two to four weeks while monitoring delivery status, precisely so receiving providers adapt to the IP change for your domain's traffic. That advice applies in reverse when you leave.

Quota increases remain available during the retirement period, handled case by case, if you need headroom while running dual senders.

## Verification, Sender Reputation and the 10DLC Gap

This section is the one that turns a two-week migration into a two-month one.

**Verification does not travel with the number.** Microsoft is explicit: verification status is managed by individual providers, and if you port a number outside Microsoft, the ability to retain or reuse an existing verification status depends on the policies and processes of the new provider. Confirm verification requirements directly with your chosen provider as part of the transition, because re-verification may be required.

**Toll-free verification at Microsoft is stable for now.** Microsoft states there are no known plans to change the current approach to bulk verification, and that you can continue planning on the existing process remaining in place, with updates communicated through Azure Updates. That is about ACS's process, not about what the destination will ask of you.

**There is no published 10DLC-to-Teams path.** Microsoft states plainly that ACS has not published a migration path from 10DLC to Microsoft Teams, and that any future updates will be communicated through the retirement document. If you have invested in 10DLC campaign registration and campaign branding, plan on re-registering with a third-party provider. Do not hold a slot in your roadmap for a Microsoft route that has not been announced.

Put together, the pattern is consistent: the number is portable, the trust attached to the number is not. Budget calendar time — not engineering time — for re-establishing it, and expect a period where the new sender operates under constrained throughput while it builds a reputation.

**The number moves in days. The reputation moves in weeks.**

## The Exit Checklist

1. **Establish your eligibility status** — did you hold ACS resources with phone numbers before the September 2026 announcement? Write it down; every later decision depends on it.
2. **Inventory numbers, short codes, verified email domains, toll-free verifications and 10DLC campaigns**, noting which external party holds the verification for each.
3. **Select destination providers** for voice, SMS and email. They may not be the same provider.
4. **Open the short code conversation first** — it has the longest and least predictable timeline.
5. **Port a pilot range** and validate inbound, outbound and delivery reporting end to end at the destination.
6. **Rebuild sending identity in parallel** while ACS still works: DNS verification for email, sender registration for SMS, toll-free verification at the destination.
7. **Rewrite the inbound and delivery-event pipeline** for the new provider's webhook schema, not just the send path.
8. **Compare destination rate limits against your real peak**, and start any quota-increase request early.
9. **Port main ranges in tranches**, separate from application cutover windows.
10. **Ramp email volume gradually** over weeks, monitoring delivery and failure rates.
11. **Export delivery logs, suppression lists and Azure Monitor telemetry** before the retirement date.
12. **Release every number, confirm billing has stopped, then delete the resource** — in that order.

Set your internal deadline well inside 2028. Porting schedules and regulatory reviews belong to other organisations, and the first quarter of 2028 will be crowded.

## When to Bring In Help

Most of this is genuinely DIY work, and it is worth saying so clearly. Porting a handful of numbers to a new CPaaS, swapping an SMS send path and repointing an email domain is a well-trodden path with good vendor documentation on both sides. If you have a dozen numbers, no short codes, and email that is not business-critical, engage your destination provider and run it in-house. You do not need a migration partner for a port.

The work changes character in three situations.

**When the numbers are the product.** If inbound traffic on specific numbers is how customers reach you — a support line, an appointment line, an OTP short code — the port is a customer-facing change with no clean rollback. That needs staged tranches, validated pilot ranges and a tested fallback routing plan, which is programme management more than engineering.

**When the delivery record is a compliance record.** Regulated senders frequently have to prove a specific message was delivered to a specific recipient on a specific date. That evidence lives in ACS delivery logs and Azure Monitor telemetry, both of which are decommissioned after the retirement date. Getting it out, reconciled and into a form somebody can query in three years is data work with an audit obligation, and it is the piece most likely to be skipped.

**When the destination is a platform, not a provider.** Plenty of teams built ACS SMS and Email because their CRM or helpdesk could not do it in 2023. If that platform now can, the retirement is a consolidation opportunity — and then the hard part stops being the port and starts being moving contact records, consent state, suppression lists and message history into the platform with the relationships intact.

Separate the two decisions. **Who owns the communication runtime afterwards** — which CPaaS, which platform, which Microsoft service — is an architecture and procurement decision that belongs with your engineering and vendor-management leads. **Who preserves the data and the evidence underneath it** is a different job: contact and consent state, delivery history, suppression lists, and the reconciliation that proves nothing was dropped in transit between two providers.

At ClonePartner we work on the second. Across 1,500+ migrations and 500+ integrations, the consistent pattern in messaging migrations is that consent and suppression state is the thing nobody owns — and sending to a previously suppressed recipient after a provider switch is a regulatory incident, not a bug. We are typically brought in when message history has to land in a CRM or helpdesk rather than cold storage, when consent and suppression state has to reconcile across two providers, or when delivery evidence has to survive the ACS decommission in a queryable form.

If your exit is a dozen numbers and a new API client, do it yourself and start the porting conversation this month. If the delivery record has to outlive the platform, or consent state has to move intact, scope that separately from the port.

> Planning your exit from ACS phone numbers, SMS or Email before the retirement? We handle the data layer around the port — contact and consent state, suppression lists, message history and delivery evidence that has to survive the decommission. Book a 30-minute call and we will sequence your exit 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

### What changes on October 23, 2026 for ACS?

Beginning October 23, 2026, new customers cannot sign up for the retiring Azure Communication Services. Customers with an ACS resource created before that date can continue using their existing resources and retiring services during the transition period, through to the September 30, 2028 retirement.

### Can I still get new ACS phone numbers?

Only if you are an existing customer with ACS resources that already have ACS phone numbers. Microsoft states that after the September 2026 announcement, customers without existing ACS phone numbers can no longer acquire new ones, and that tenants creating their first ACS resource after the announcement are not eligible to request phone numbers.

### How do I port an ACS phone number to another provider?

Follow your destination provider's port-in instructions, and open a Microsoft support ticket for Microsoft to release the number. Verification status is managed by individual providers, so re-verification with the destination may be required. Microsoft also warns that migrating ACS numbers to another provider requires re-verification with an SMS aggregator and might cause downtime.

### What is the Microsoft alternative to ACS SMS?

There is not one. In Microsoft's migration recommendations table, the SMS row lists no Microsoft alternative — only third-party Marketplace partners, Infobip and Telesign. The one exception is scoped to Dynamics 365 Contact Center customers, where Microsoft says it will offer equivalent alternative SMS services before the retirement date.

### Is Exchange Online a real replacement for ACS Email?

Not for bulk or transactional sending. Microsoft describes Exchange Online as designed for person-to-person business email from licensed mailboxes rather than bulk delivery, with rate limits that vary by design. High Volume Email covers high-volume operational mail but is scoped to internal, within-tenant sending. Neither matches ACS Email's external A2P profile.