Your replacement decision changed the moment Microsoft announced that standalone Azure Communication Services will retire. The relevant question is no longer which API has the most attractive feature list. It is whether the next platform gives you enough roadmap clarity, portability, and deployment control to survive the next strategic change.
Microsoft announced the standalone ACS retirement on September 23, 2026, with the retirement taking effect on September 30, 2028, according to its retirement and breaking-changes guide. The guide separates services that will be permanently removed from services that remain available only in supported Teams-aligned scenarios. It also says that, after the retirement date, standalone ACS scenarios that do not integrate with Teams will no longer be supported.
That changes how you should evaluate an ACS alternative. The recommendation is to choose the platform that leaves your product with the clearest exit route, even when that means accepting fewer ready-made features today. Test every candidate against four questions: who controls the roadmap, how much notice the contract provides, what can move if the vendor changes direction, and which parts of the media system you can operate under your own control.
Start with the failure that brought you here
A provider exit is not only a migration exercise. It is a test of the assumptions you made when the product was first launched.
ACS gave many teams a convenient foundation for adding communications to an application. The difficult discovery comes later: the application may depend on the provider's room model, identity model, calling primitives, user interface, recording workflow, number management, or service-specific policy. When the provider retires the standalone product, those dependencies become part of the replacement decision.
Before reviewing vendors, write down the parts of the current product that users actually experience:
- How users join, authenticate, and receive permission to enter a call.
- How rooms, meetings, participants, tracks, devices, and call state are represented.
- How the product handles camera and microphone permissions, device changes, reconnection, active speaker state, and accessibility.
- Where media travels and where TURN, recording, processing, and storage run.
- Which functions are essential to the product and which were merely convenient additions from the original platform.
The inventory tells you what the replacement must preserve. It also exposes the components that should belong to your own application rather than being hidden inside another provider's product model. The switching-cost analysis is useful for working through that inventory before you compare platforms.
Roadmap durability comes before feature breadth
A platform can have a strong feature set and still be a poor foundation for a product that must remain stable for years. The ACS retirement demonstrates why: the service can remain available during a transition period while the original standalone operating model loses its long-term support boundary.
Microsoft describes the ACS transition as a two-year retirement period after the September 2026 announcement. During that period, existing ACS resources and current workloads remain supported under the stated terms, while Microsoft's focus is existing functionality and critical security and stability updates. The guide says Microsoft cannot commit to new feature development for services affected by the retirement.
Ask each candidate to explain four things in writing:
- Which product and APIs are strategic for the provider.
- Which capabilities are in maintenance mode, preview, or subject to a separate product direction.
- How the provider announces breaking changes, product withdrawals, and ownership changes.
- What happens to your application if a capability is retired without a feature-equivalent successor.
Do not treat a public roadmap as a guarantee. Treat it as evidence to compare with the contract, service terms, release history, and the provider's behaviour when products change direction. The key distinction is whether the platform's future is aligned with your product's future, rather than whether its current checklist is long.
Read the notice terms as an engineering requirement
Notice gives you time, but notice alone does not give you continuity.
Microsoft's Azure infrastructure lifecycle FAQ says the typical notice period for Azure infrastructure retirement is at least 12 months. It also explains that, after retirement, features may be removed, disabled, automatically migrated, or require manual action, and that service-level agreements may no longer apply. Microsoft describes that period as typical rather than a guaranteed minimum for every Azure service.
Other major cloud terms use their own conditions. The AWS Customer Agreement says AWS may provide at least 12 months' prior notice before discontinuing a material functionality of a generally available service that the customer is using, subject to stated exceptions. The Google Cloud Platform Terms of Service describes at least 12 months' notice before discontinuing a service or associated material functionality, unless an exception applies or a materially similar replacement is provided.
These provisions are useful reference points, but they do not promise feature parity or a migration that preserves your architecture. When you evaluate a replacement, ask the provider to identify the notice period, the exceptions, the treatment of data and recordings, the support available during the transition, and what happens to your application after the end date. Have legal and engineering review the same language. A notice clause that looks acceptable to procurement may still leave engineering with a rewrite.
Measure portability at the boundaries that matter
Portability is often discussed as though moving a video product means changing one SDK import. In practice, the difficult boundaries are the ones that connect the provider to the rest of your product.
Evaluate portability across these surfaces:
| Boundary | What to examine |
|---|---|
| Application model | Whether rooms, meetings, participants, permissions, tracks, and tokens map to concepts your application can own. |
| Client experience | Whether your interface controls device selection, layout, active speaker behaviour, call state, reconnection, and accessibility. |
| Media operations | Where the media path, TURN, recording, processing, and storage run, and how those functions can be moved or retained. |
| Data and records | How recordings, metadata, transcripts, audit information, and user relationships are exported and reconstructed. |
| Operations | Which monitoring, incident response, scaling, and deployment responsibilities remain with your team. |
Then run a small exit exercise before signing. Model how you would create a room, issue access, establish a call, record it, retrieve the result, and close the session on a second platform. You are testing the seams between your product and the provider. A candidate that leaves those seams in your code gives you more control when the provider changes its terms.
This is also where the choice between an embedded interface, a UI kit, and a headless SDK matters. The video embed options guide explains why a faster initial integration can leave more product behaviour inside the provider's layer.
Deployment control reduces dependence, within limits
Deployment control is valuable when it covers the parts of the system that affect data location, network policy, operational continuity, and replacement work. It does not automatically give you independence from the vendor.
Ask whether you can control the media path, TURN, recording, processing, and storage. Ask which components require the vendor's service, credentials, support, or proprietary control plane. Ask for the answer in deployment documentation and contract terms rather than relying on a sales description.
A customer-controlled deployment can reduce the amount of infrastructure that must move during a provider change. It cannot establish source-code escrow, perpetual licence rights, independent support, or a guarantee that the complete system will continue operating if the vendor stops providing service. Those protections require explicit contractual and operational arrangements.
The right criterion is therefore narrower and more useful: choose a platform that gives you meaningful control over the system boundaries you care about, then verify what that control permits in practice.
Build, buy, or deploy the replacement
There are three practical paths after an exit. Each places a different amount of responsibility in your organisation. The architectures themselves are compared in depth in the technical decision guide and the white-label decision guide; the notes below cover how each path looks after a provider exit.
Build on open source
Building on an open-source media stack can give your team greater control over the media layer and the ability to shape the product around your own abstractions. It also makes your team responsible for integration, upgrades, security response, deployment, observability, capacity planning, and the surrounding product experience.
This path fits an organisation that wants to own the engineering and operations of the communication system as a long-term capability. It is a poor fit when the team wants a finished service and has no capacity to operate the underlying components.
Buy a cloud video API
A cloud API can shorten the first release and place more of the infrastructure operation with the provider. The trade-off is that your application becomes dependent on the provider's APIs, service terms, pricing model, roadmap, and export capabilities.
This path fits a product whose requirements align closely with a stable, documented service and whose team has verified the exit terms. It is a weak choice when the provider's abstraction becomes the product's domain model or when a future provider change would require rewriting the client and backend together.
Deploy a commercial platform
A commercial platform can occupy the middle ground: embeddable SDKs and product components, combined with greater control over deployment and the boundary between your application and the media system. The evaluation must still distinguish a platform that is merely hosted from one that gives you meaningful control over the media path, TURN, and recording.
Samvyo is one option in this category. Its documented model is based on SFU architecture and provides embeddable SDKs, OEM and white-label depth, and a managed-service option. It describes customer-controlled deployment for the media path, TURN, and recording, including on-premise or managed-cloud arrangements, as set out in its deployment-model overview.
That description does not establish an ACS migration path, Teams interoperability, source-code escrow, perpetual licences, or a guarantee that the complete platform will operate without vendor support. Samvyo also states that it is not the fit when a buyer's needs are already met by a certified SaaS provider's standard terms, or when the buyer needs to operate and modify every layer itself. Those limits belong in the evaluation rather than being hidden behind the deployment model.
Choose the path whose responsibilities match your organisation. The safest selection is the one you can explain in an exit plan before you sign, including what your team would own if the provider changed direction.
Bottom Line
Choose an ACS replacement for its durability and exit structure before you choose it for its feature list. The provider should give you clear notice terms, a roadmap you can assess, portable application boundaries, and deployment control over the media functions that matter to your product.
A commercial platform can reduce provider dependence when its deployment model and contract give you real control, but that control has limits. Verify those limits before committing, and keep the application boundary yours from the first release.
What's Next
The companion guide, Azure Communication Services Is Retiring: What Actually Goes, What Survives, and What It Costs You, maps the ACS services that retire, the capabilities that remain in Teams-aligned scenarios, and the dates that shape the decision.
Read it before turning this selection framework into a migration plan, because the right replacement depends on which part of ACS your product actually uses.
To make the next exit cheaper whichever platform you choose, The Seam shows how to put video behind your own interface so the provider can be swapped later.
FAQs
What should I look for in an ACS alternative?
Look for roadmap durability, clear retirement and breaking-change terms, portable application boundaries, and control over the media path, TURN, and recording. Evaluate those criteria against the specific dependencies in your product rather than comparing feature lists alone.
When does Azure Communication Services retire?
Microsoft's retirement and breaking-changes guide states that the standalone Azure Communication Services offering retires on September 30, 2028. Microsoft also describes an onboarding restriction beginning October 23, 2026 for retiring services, with specific treatment for existing resources and Teams-aligned services.
Does a longer retirement notice make a video platform durable?
No. Notice gives your team time to respond, but it does not guarantee a replacement, feature parity, or continued support for the original architecture. Review the notice clause together with export capability, contractual rights, deployment control, and the provider's product direction.
Should a company build its own video infrastructure after the ACS retirement?
Build on open source when your organisation is prepared to own the media stack, deployment, upgrades, monitoring, and security response as a long-term engineering capability. Buy or deploy a commercial platform when those responsibilities would distract from the product, while checking exactly which parts remain under your control.
Can Samvyo replace Azure Communication Services directly?
Do not assume a direct ACS replacement or Teams interoperability from Samvyo's documented deployment model. Samvyo describes a platform based on SFU architecture with embeddable SDKs, OEM and white-label depth, and customer-controlled options for the media path, TURN, and recording; the buyer must separately validate product fit, migration work, and contractual continuity.
What does deployment control protect against?
Deployment control can reduce the amount of media infrastructure that must move when a provider changes direction, especially when the media path, TURN, recording, processing, and storage are under customer control. It does not by itself provide source-code escrow, perpetual licences, independent support, or a guarantee that every component will keep operating without the vendor.
How can I test a video platform's portability before signing?
Run an exit exercise using a representative workflow: create a room, authenticate a participant, establish a call, handle a device or network change, record the session, retrieve the result, and close the session. Document which data, application code, infrastructure, credentials, and provider services the workflow depends on, then ask the candidate to explain how each dependency would move.
