Microsoft’s wording leaves little room for a “lift and shift” interpretation: “ACS Rooms and Teams meetings through the Microsoft Graph API offer similar functionality, but exist in two different environments and don't offer a migration path.”
That sentence changes the engineering plan. A product built around ACS Rooms should not treat Teams meetings or Graph online meetings as a replacement endpoint that accepts the same room IDs, participants, roles, and schedules. The practical task is to identify the Rooms control plane your product depends on, choose a target environment, and redesign that layer against the target’s identity, authorization, meeting, and lifecycle model.
Microsoft lists Teams Meeting interoperability and Microsoft Graph APIs as possible alternatives, but it does not describe either as a Rooms conversion process. The recommendation is therefore straightforward: start a bounded redesign of the Rooms-dependent control plane before the retirement deadline, and validate every assumed mapping instead of promising automatic continuity.
What ACS Rooms gave your application
ACS Rooms was more than a container around a video call. It provided a server-side model for structured meetings: your application could create and manage rooms, control who belonged to them, assign participant roles, apply schedules, and set room-level security limits.
Microsoft’s Rooms API documentation describes the model directly. The documented control-plane operations include:
- Creating, retrieving, updating, listing, and deleting Virtual Rooms.
- Adding, updating, and removing users from a room.
- Assigning and updating predefined participant roles.
- Setting and updating a room’s schedule.
- Applying security limits, including restrictions on PSTN dial-out.
Those operations are the part of the product that needs the closest attention. They are separate from the client media experience and separate from the visual call interface. The Calling SDK and the Web and Mobile UI Library are separate dependencies with their own retirement terms.
The Rooms object model is part of your product
A Rooms-based application normally has its own records and workflows around the Microsoft resource. Microsoft’s Rooms quickstart says that, because rooms are server-side entities, developers should track and persist the roomId in their chosen storage medium. That guidance is documented in the ACS Rooms creation quickstart.
That persisted identifier may appear in more places than the API call that created it. It can be associated with a customer, a scheduled session, a participant list, an access policy, an audit record, or an application-specific workflow. The retirement guide does not say that an existing Rooms identifier can be imported into a Graph online meeting. Treat that relationship as application data that needs a deliberate migration or replacement plan.
The same principle applies to participant identity. The Rooms quickstart states that ACS Communication Services Rooms currently support a participant of type CommunicationUserIdentifier; other Communication Identity types cause a runtime error. A move into the Teams and Graph environment introduces a different identity and authorization context. Existing participant records may still be useful to your application, but their meaning and authorization in the target system must be re-established.
Roles and schedules do not carry across automatically
The four predefined participant roles in ACS Rooms are Presenter, Collaborator, Attendee, and Consumer. They are documented in the Rooms API reference. These names should not be treated as a portable permission contract.
Microsoft documents Teams and Graph meetings through a different set of APIs and permissions. The retirement guide does not provide a one-to-one table that maps each ACS Rooms role to a Teams meeting role. The safe engineering assumption is that role intent must be re-evaluated in the target environment. For example, your product may use “Presenter” as a business permission, while the target meeting system may express the relevant capability through meeting options, participant policy, tenant settings, or a different role model.
Schedules require the same treatment. ACS Rooms lets an application set or update a room’s schedule with validFrom and validUntil values. Those fields describe the validity window of the Virtual Room. They are not evidence that the same values can be transferred into a Graph meeting resource with identical behavior.
Before choosing a target, document what each schedule field means in your product. A validity window may control when participants can use a room, when your application shows it as active, or when a server-side policy applies. Those are application decisions. The target API must be tested against each one rather than selected because its terminology appears similar.
Why Teams interoperability is not a Rooms migration
ACS Rooms does not directly interoperate with Microsoft Teams. Microsoft marks Teams interoperability as unsupported in the Rooms API documentation. The retirement guide points workloads toward Teams Meeting interoperability and Teams-native meeting creation and management APIs depending on their requirements.
That recommendation identifies possible destinations. It does not establish feature parity, preserve Rooms state, or create a conversion procedure.
Microsoft’s wording matters here because it explicitly separates the two environments. The relevant systems may support overlapping meeting scenarios, but they do not expose the same operating model. A product that currently controls a Virtual Room through ACS APIs cannot assume that sending the same room record to a Teams or Graph endpoint will produce an equivalent meeting.
The broad provider-change questions are covered in the general inventory of what changes when you move video providers. For ACS Rooms, narrow that inventory to the control plane: resource identity, participant state, roles, schedule rules, authorization, and the server-side controls your product actually uses.
Graph online meetings are a different operating environment
Microsoft Graph can create or join online meetings and return meeting coordinates. Participants can join through a joinWebURL or through the create-call API, according to Microsoft’s online meetings documentation. That gives a product a way to work with online meetings, but it does not make Graph a Rooms-compatible API.
The authorization model is one visible difference. For an application to call POST /users/{userId}/onlineMeetings, Microsoft requires an application access policy granted by a tenant administrator. The API creates the meeting on behalf of a user. The requirement is described in Microsoft’s Create onlineMeeting API reference.
That changes the questions your product must answer. Which tenant authorizes the application? Which user is the meeting organizer? How are permissions granted and revoked? What happens when the organizer changes? Which part of the experience belongs to your application, and which part is governed by Teams and tenant policy?
Graph also has behavior that product teams must account for explicitly. Microsoft states that a meeting created through the online-meeting API is a standalone meeting and is not associated with an event on the user’s calendar. It therefore does not appear on that calendar unless the application uses a calendar API as well. A Rooms product that presents scheduled sessions inside its own interface cannot assume that creating a Graph meeting will reproduce the same calendar or scheduling behavior.
What the redesign should inventory
Microsoft does not publish a checklist of what a Rooms-based product must change, so bound the inventory by the Rooms capabilities your product actually uses.
Room creation and persistence
Find every place where your application creates, stores, retrieves, updates, lists, or deletes a Rooms resource. Record whether the stored roomId is exposed to customers, embedded in URLs, used in webhooks, or joined to business records. Then decide whether the target system needs a new identifier, a translated internal identifier, or an application-owned session record that sits above the target meeting.
Participant and identity handling
Document how your application creates a Communication User, adds that user to a room, removes the user, and decides whether the user can join. Compare that behavior with the identity and authorization requirements of the selected Teams or Graph design. Existing customer and participant data may remain valuable, but portability of the data does not prove portability of its permissions.
Roles and policy
List the business actions attached to Presenter, Collaborator, Attendee, and Consumer in your application. Do not migrate the labels without testing their meaning. Re-express the underlying business rules in the target environment, where the available meeting roles, policies, and administrative controls may differ.
Validity and scheduling
Separate the Rooms validity window from the customer-facing schedule. Determine whether your product uses the window to permit joining, to show availability, to enforce a session boundary, or to trigger another workflow. Then test how those behaviors will be implemented around the target meeting resource.
Server-side controls
Record each control your application applies at room level, including restrictions such as PSTN dial-out. A target environment may offer a related policy, require tenant administration, or provide no equivalent control in the same API. The target decision is incomplete until each important control has a documented implementation or an accepted product change.
What to do before the retirement date
ACS Rooms will continue receiving security, compliance, and critical reliability updates during the retirement period, but Microsoft says that no new features or enhancements will be introduced. Microsoft defines retirement as permanent removal from Azure, and the guide gives the retirement date as September 30, 2028. After that date, retired services are not supported and cannot be used. Both points are stated in the ACS retirement and breaking changes guide.
That transition window is useful for discovery and validation. It is not a reason to defer the design. Start by capturing the Rooms contract your application relies on, then select the target scenario: Teams Meeting interoperability, Graph-based meeting creation, or another architecture that satisfies the product’s requirements. For each target, test identity, permissions, participant behavior, roles, schedules, meeting creation, and server-side controls with representative workflows.
Keep the existing Rooms path available while the replacement is being validated, subject to Microsoft’s published retirement terms. Do not describe the project internally as an API endpoint swap. The evidence supports a narrower and more accurate description: the Rooms control plane is moving between different environments, so the application must preserve the product behavior through a redesigned implementation.
Bottom Line
ACS Rooms is retired outright, and Microsoft explicitly says that Rooms and Teams meetings through Graph exist in different environments without a migration path. Teams interoperability and Graph APIs may be target environments, but neither should be treated as a direct import destination for Rooms resources.
The right first move is to inventory the Rooms control plane your product owns: room identity, participant state, roles, schedules, authorization, and server-side controls. Then validate a redesigned target implementation before the September 30, 2028 retirement date.
What’s Next
Once the Rooms dependency is clear, the next decision is broader than API compatibility. Choosing an ACS replacement looks at the durability and deployment questions to test before committing to another provider.
FAQs
Does ACS Rooms have a migration path to Microsoft Teams?
No. Microsoft states that ACS Rooms and Teams meetings through the Microsoft Graph API exist in different environments and do not offer a migration path. Teams Meeting interoperability and Graph APIs are alternatives to evaluate, and Microsoft documents no conversion from Rooms to either.
What happens to ACS Rooms after September 30, 2028?
Microsoft lists ACS Rooms as retired, with permanent removal from Azure on September 30, 2028. During the retirement period, Rooms receives security, compliance, and critical reliability updates, but Microsoft says no new features or enhancements will be introduced.
Can existing ACS room IDs be imported into Graph online meetings?
Microsoft does not publish a procedure stating that ACS room IDs can be imported into Graph online meetings. Treat the existing roomId as application data and define how it relates to a new target meeting or an application-owned session record.
Are ACS Rooms roles equivalent to Teams meeting roles?
No equivalence is established by Microsoft’s retirement guidance. ACS Rooms defines Presenter, Collaborator, Attendee, and Consumer, while Teams and Graph use a different API and permission environment, so the business meaning of each role must be re-evaluated.
Can Microsoft Graph create a Teams meeting for an application user?
Microsoft Graph can create online meetings on behalf of a user, but the application needs the relevant permissions and an application access policy granted by a tenant administrator. That authorization model is part of why Graph online meetings should be designed as a different environment rather than treated as a Rooms endpoint.
Will a Graph-created meeting automatically appear on the user’s calendar?
No. Microsoft says that a meeting created through the online-meeting API is a standalone meeting and is not associated with a calendar event. If your product needs calendar visibility, it must account for calendar integration separately.
What should a team built on ACS Rooms do first?
Start by documenting the Rooms operations and policies your product actually uses: room lifecycle, persisted identifiers, participants, roles, schedules, authorization, and server-side controls. Use that inventory to test a target design and to decide which product behavior remains unchanged, which must be redesigned, and which target capabilities are unavailable.
