ACS Data Export: Recordings, Chat and Telemetry Before 2028

Most of the Azure Communication Services retirement is a 2028 problem. One part of it is a 24-hour problem, and it is running right now.

ACS built-in call recording storage is temporary. Recording files are available to download for 24 hours. Microsoft's own instruction is to retrieve and archive the recording files and their associated metadata within that window and not to wait until September 30, 2028. This is not a retirement behaviour — it has always been how built-in recording storage works. The retirement is just the first time most teams read that page.

Everything else on the ACS data estate is on the longer clock: chat messages, call recordings, and operational telemetry in Azure Monitor will be available for export, and after the retirement date the supporting data and telemetry for retired and standalone services is decommissioned. That gives you until September 30, 2028 to get it out. This post is the retention and export audit: what data you have, where it physically lives, what window applies to each type, and how to prove the export is actually complete.

The Windows You Are Working Against

Data type	Where it lives	Window
Call recordings (built-in storage)	ACS temporary storage	24 hours from availability — today, not 2028
Call recordings (Bring Your Own Storage)	Your Azure Blob Storage account	Your storage account's own retention and lifecycle rules; unaffected by the retirement
Chat messages and threads	ACS, per the retention policy set at thread creation	Indefinite, or automatic deletion between 30 and 90 days, depending on the policy that thread was created with
Chat history overall	ACS	Maintained per your storage policies until September 30, 2028
Operational telemetry	Azure Monitor	Available for export until the retirement date; decommissioned after
Supporting data for retired services	ACS	Decommissioned after September 30, 2028
Phone numbers	ACS resource	Must be released before the resource is deleted, or charges continue

Two of those rows have windows measured in hours and days rather than years, and both of them are the rows people discover last.

The authoritative source is Microsoft's retirement and breaking changes guide for Azure Communication Services. The wider scope of what is retired versus what merely breaks is covered in the ACS retirement pillar guide.

Why Recordings Are the Emergency

There is a specific reason call recording sits above everything else in priority order, and it is not just the short window.

There is no replacement. Microsoft states that currently, neither Microsoft nor third-party providers in the Microsoft Marketplace offer a similar standalone solution for ACS call recording, and advises monitoring the Marketplace for something that might appear in future. The same sentence appears for ACS Audio Streaming and for ACS closed captions.

So for recording, the situation is: a capability with no announced successor, whose default storage is temporary, whose window is 24 hours, attached to a service that stops being supported standalone in 2028. If your business has a regulatory obligation to retain call recordings — financial services, healthcare, any consented-recording regime — this is the single highest-risk item in the entire ACS estate.

After September 30, 2028, ACS call recording remains supported only where it is documented for an eligible Teams call scenario, including supported Teams Phone Extensibility configurations. Microsoft is careful to add that an eligible integration alone does not establish recording support. Teams Meeting interoperability, for instance, explicitly does not by itself establish support for ACS recording — you have to validate it for your configuration.

Assume recording is a capability you will be rebuilding, not migrating.

Call Recordings: Temporary Storage, BYOS, and What TPE Does Not Fix

The Three States Your Recordings Can Be In

State 1: Built-in temporary storage, retrieved inside the window. Your application receives an Event Grid notification when a recording is available, downloads it and the associated metadata, and writes both somewhere durable. This works, but it is a job with a hard SLA that most teams never treat like one.

State 2: Built-in temporary storage, not reliably retrieved. The recording exists for 24 hours and then it does not. Recordings created during a deployment freeze, a failed webhook delivery, a long weekend or an unnoticed exception are simply absent from the archive. Nobody notices until somebody asks for a specific call.

State 3: Bring Your Own Storage. Recordings are written to an Azure Blob Storage account you control. Microsoft confirms that the ACS transition does not delete these or restrict your access to them — they remain subject to your storage account's own permissions, retention and lifecycle policies, subscription status and charges. Access to stored files is separate from eligibility to create new recordings with ACS after the transition.

State 3 is the durable answer, and it is configuration rather than an engineering project. The Bring Your Own Storage quickstart covers the setup and the export notifications. The underlying mechanics, including Event Grid notifications for recording availability, are documented in the call recording concept guide.

Teams Phone Extensibility Does Not Solve This

Worth stating plainly because it is a common assumption. For supported TPE calls you can use ACS call recording with built-in temporary storage or your own Azure Blob Storage. Built-in recording files still have a 24-hour download window. Microsoft states that using TPE does not make temporary storage a permanent archive and does not automatically migrate previously recorded files.

Two consequences follow. First, migrating to TPE does not retroactively rescue anything you have already lost. Second, if you migrate to TPE without switching to your own storage, you have carried the retention gap forward into the new architecture.

The Metadata Is Half the Record

Microsoft's phrasing is "the recording files and associated metadata." That second half is what makes a recording usable as evidence later: which call it belongs to, which participants were on it, when it started and stopped, which chunk it is in a multi-part recording, and the format and channel configuration.

An archive of audio files with no metadata is a directory of unattributable blobs. Whatever retrieval job you build, it needs to persist the notification payload alongside the file and keep the association durable. This is exactly the detail that gets dropped when a retrieval job is written quickly against a 24-hour deadline.

Chat History: Your Retention Policy May Already Be Deleting

Before planning a chat export, find out what you actually still have.

ACS stores chat messages according to the retention policy set when the chat thread was created. Per Microsoft's service limits documentation, you can choose indefinite message retention, automatic deletion between 30 and 90 days, or no retention policy at all. Critically, threads created before a policy change are not affected unless you specifically change the policy for that thread.

That produces a common and unpleasant discovery: an estate where different cohorts of threads have different retention, set years apart by different engineers, with no central record of which is which. The 2028 date is irrelevant to a thread whose 30-day policy deleted its messages last month.

Two Documented Ways to Archive Chat

Microsoft documents two patterns in its archive chat threads guide, and the choice depends on volume.

Batch, for high volume. A backend application runs a job against threads that are no longer active: list the messages in the thread, write them out in your chosen format such as JSON or CSV, and copy the result into Blob Storage. This is the right pattern for a bulk export ahead of decommissioning, because it is restartable and you control the pace.

Real-time, for lower volume. Subscribe to Event Grid chat events through webhooks — message received, message edited and message deleted are the recommended set — and archive as conversations happen. This has the advantage of capturing edits and deletions as events rather than inferring them from a later snapshot, which matters if your compliance regime cares about message mutation. Event Grid is a paid service, so the cost scales with message volume.

For a decommissioning export specifically, most teams want both: real-time capture going forward so nothing new is lost, and a batch backfill for everything already in the system.

Plan Around the Rate Limits

A bulk chat export is a read-heavy job against a rate-limited API, so the export duration is a function of published limits rather than your infrastructure. From the service limits documentation: ListMessages returns a maximum page size of 200, and listing chat messages is capped per chat thread at 250 requests per 10 seconds and 400 per minute, with a lower per-user-per-thread ceiling. Threads hold up to 250 participants and individual messages up to 28 KB.

Do the arithmetic before you commit to a window. A million-message estate at 200 messages per page is 5,000 page requests, which is trivially fast in aggregate — but the limits are scoped per thread, so an export of a few very long threads behaves completely differently from an export of many short ones. Model your actual thread-length distribution. When throttling does hit, you receive HTTP 429, and the documented guidance is to reduce operations per request, reduce call frequency, and avoid immediate retries because every request accrues against your usage limits.

If the export has to run without taking the chat service offline, the zero-downtime migration patterns apply here directly — a real-time event subscription plus a throttled backfill is exactly that shape.

Telemetry: What "Decommissioned" Means

Microsoft's statement is that data such as chat messages and call recordings, and operational telemetry such as data in Azure Monitor, will be available for export, and that after the retirement date the supporting data and telemetry for retired and standalone services will be decommissioned.

Telemetry is the category teams skip, because it feels like operational exhaust rather than records. It is worth asking what your telemetry actually proves:

• Call quality and diagnostics data — the evidence base for any dispute about whether a call connected, how it performed, and why it failed
• Email delivery logs and insights — bounce, suppression and delivery outcomes, which is what you produce when someone claims they never received a notice
• SMS delivery reports — the same, for regulated notifications where delivery is the obligation
• Access and operational logs — who did what to the resource and when

If any of that is referenced in a retention schedule, a customer contract or a regulatory requirement, it needs to leave Azure Monitor with everything else. The route is ordinary Azure diagnostic settings: send logs and metrics to a storage account, a Log Analytics workspace or an Event Hub that you own and that is not part of the ACS resource being decommissioned.

Telemetry retention is configured in the destination, not the source — so exporting it is only half the job. Confirm the destination's retention actually matches your obligation.

Delete the Resource Last: The Orphaned Number Trap

A short section for an expensive mistake.

Microsoft's guidance is direct: 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.

Resource deletion feels like the final tidy-up at the end of a decommissioning sprint. It is not. The correct sequence is:

1. Export all data from the resource
2. Reconcile the export against source counts
3. Obtain records and compliance sign-off on the archive
4. Release or port every phone number attached to the resource
5. Confirm the numbers are gone and billing has stopped
6. Then delete the resource

Getting steps 4 and 6 the wrong way round produces a bill for numbers you no longer control and a support ticket to unwind it. Getting steps 1 to 3 wrong produces something worse, because deletion is not reversible. The porting mechanics themselves — support tickets, release requirements, re-verification with the destination provider — are covered in the ACS phone numbers, SMS and Email exit guide.

How to Prove an Export Is Complete

This is the section that separates a migration that survives an audit from one that merely finished. An export with no reconciliation is an assertion.

Capture the Baseline First

Before extraction begins, record from the source:

• Thread count, participant count and message count
• Message counts by thread and by day
• Oldest and newest message timestamps
• Counts of edited, deleted, HTML, attachment and metadata-bearing messages
• Recording count, total bytes, and count of recordings with complete metadata
• Threads that returned errors or were inaccessible

These numbers are worthless if you capture them after the export, because then they are derived from the same run you are trying to verify. Capture them independently, first.

Reconcile Against the Baseline

After extraction, produce a report that answers four questions:

1. Does every source record have a final status? Exported, archived, excluded or failed. Not "most of them."
2. Do counts match, accounting for approved exclusions? A variance is acceptable if it is explained and approved. An unexplained variance is a failed export.
3. Are the excluded items documented with an approver? "We could not export these 340 messages because their author no longer exists, approved by the records owner on this date" is a defensible position. Silence is not.
4. Does retrieval actually work? Pull ten random records out of the archive and open them. Sampling the archive is the only test that catches a technically complete export of unreadable files.

Keep the Ledger

Keep the per-record ledger — source identifier, destination location, status, timestamp, error if any — for as long as you keep the data. It is the artefact that answers "prove this conversation was preserved" in three years, when everyone who ran the migration has moved on and the source system no longer exists.

The Export Checklist

In priority order, not chronological order.

1. Today: audit recording storage. For every recording workload, determine whether files land in built-in temporary storage or in a Blob Storage account you own. This is a same-week task.
2. Configure Bring Your Own Storage wherever recordings are business-critical, or verify your retrieval job runs reliably inside 24 hours — including weekends, deployment freezes and holiday periods.
3. Confirm recording metadata is persisted alongside the files, not just the audio.
4. Audit per-thread chat retention policies. Find out what you still have before planning to export it.
5. Build the data register: data type, physical location, owner, window, legal retention requirement, current export status.
6. Stand up real-time chat archiving via Event Grid so nothing new is lost while you plan the backfill.
7. Capture the source baseline counts before any bulk extraction.
8. Run the batch chat export against the published rate limits, with restartable checkpoints and a per-message ledger.
9. Export Azure Monitor telemetry to a destination you own, and verify retention at that destination.
10. Reconcile, sample and get written sign-off from records and compliance owners.
11. Release every phone number before deleting the resource.
12. Then, and only then, decommission.

Items 1 to 3 have no dependency on any other decision in the ACS migration. They do not require knowing whether you are going to Teams or to a third-party CPaaS. Do them now, independently of the rest of the programme.

When to Bring In Help

Be honest about which of these you are.

This is a DIY job if your ACS estate is one resource, recordings already go to your own Blob Storage, chat history is either short-lived by design or small enough to export in an afternoon, and no regulator is going to ask you to produce a specific record from 2025. Configure BYOS, run a batch export, reconcile the counts, release the numbers, delete the resource. A competent engineer does this in a sprint and does not need help.

It stops being a DIY job at three specific thresholds, and they are not about volume.

Threshold one: when the export has to be provable, not just done. There is a large difference between "we exported the chat history" and "we can demonstrate that every one of 4.2 million messages reached a known final state, that the 1,847 exclusions were approved by name and date, and that a retrieval from the archive works today." The first is a script. The second is a controlled migration with a reconciliation artefact, and it is what a regulator, an auditor or an acquirer's diligence team actually asks for. Teams underestimate this because the script runs fine — the gap only appears when someone asks for evidence, by which time the source is gone.

Threshold two: when the archive is not the destination. Exporting to blobs is straightforward. Landing the same data in a helpdesk, a CRM, a contact centre platform or a compliance archive with its relationships intact is a different problem: conversations have to keep their participants, recordings have to stay attached to the interactions they belong to, timestamps have to survive, and identity has to reconcile across two systems that model users differently. That is a mapping and transformation problem with an audit trail attached, and it is where most of the real effort lives.

Threshold three: when the deadlines are not aligned. The recording window is 24 hours. Chat retention may be 30 days. The retirement is September 2028. Number porting is measured in weeks and is irreversible. Running those four clocks concurrently, with a resource that cannot be deleted until all of them have resolved, is a sequencing problem — and sequencing errors in decommissioning are the expensive kind, because the recovery option is usually "there isn't one."

Separate the two decisions cleanly. Who owns the communication runtime afterwards — Teams Phone Extensibility, a third-party CPaaS, a native platform capability — is an architecture decision for your engineering leadership and your Microsoft account team. Who preserves the data and proves it survived is a different job with a different deliverable: not a working system, but a defensible record.

At ClonePartner we work on the second one. Across 1,500+ migrations and 500+ integrations, the consistent pattern is that runtime cutover gets a project plan and the data underneath it gets a script written in the last fortnight. Recordings without metadata, chat history with the author attribution stripped, telemetry nobody exported, and an archive nobody has ever successfully read from — these are not exotic failure modes, they are the normal ones.

We are typically brought in when the retention obligation is real and specific, when history has to land in a live platform rather than cold storage, when the reconciliation has to stand up to an auditor rather than a standup, or when the sequencing across recordings, chat, numbers and resource deletion needs someone to own it end to end.

If your recordings already go to your own storage and your chat history is disposable, do this in-house and do it this month. If someone will one day ask you to produce a specific call recording or a specific conversation from 2026 and the answer has to be yes, get the data workstream scoped and staffed separately from the runtime migration — and start it before the 24-hour window claims another day of recordings.