How to export your data from Microsoft 365 Copilot

In an eDiscovery export, each Copilot exchange is not stored as a chat transcript. Microsoft Learn describes a prompt as a message from the user's own address to the Copilot application identity, and the response as a message from that identity back to the user. Reading the archive therefore means pairing messages by sender, recipient and timestamp rather than expecting one record per conversation. Copilot memories are stored with the IPM.Contact item class, so they match as contacts in eDiscovery searches and can appear alongside address book content. Anyone reviewing the export should expect this layout before drawing conclusions about how a conversation flowed.

For an import or parser, this structure has practical consequences. Your code must identify the Copilot application identity by its address, group the prompt and response pairs into threads, and separate memory contacts from ordinary mail. The HTML transcripts that Purview can produce for chat messages are a useful visual check, but they are not a substitute for knowing the underlying item fields. Confirm the exact field names, identity addresses and item class values in your own tenant, because these details are documented by Microsoft and may change. Also note that the eDiscovery user needs the licensing and role described in the search and export guidance before any export can run.

Before relying on this structure, run a test export. Create a small eDiscovery case against a test account that has known Copilot prompts and at least one saved memory, export it as PST and as .msg, and inspect how each prompt, response and memory appears. Record the sender, recipient and item class values for each, then check whether your parser reconstructs the same conversation pairs. Repeat the test whenever Microsoft changes the Copilot experience, because the archive layout is what your retention and migration decisions will depend on.

An export from Microsoft 365 Copilot preserves a record of what users asked and what the assistant answered, which matters for retention obligations, legal holds and internal investigations. It does not recreate the assistant. The exported items are static transcripts: they carry the prompt and response text, but they do not carry the Microsoft Graph grounding that shaped each answer, the document permissions that were checked at query time, or the model and version that produced it. A reviewer reading a PST or .msg package cannot tell which SharePoint file or Teams thread the assistant drew on, or whether that user could have opened it at the time. Plan the export as an evidence and retention task, and document that limit in the project record so no one assumes the history can be replayed.

Before you choose an import target, confirm the license terms of each candidate, because the differences affect whether you can keep the history in a shared interface. Open WebUI is licensed under the Open WebUI License, a BSD-3-Clause style license with an added clause that restricts removing or altering its branding unless specific conditions are met, such as a deployment of 50 or fewer users in a rolling 30-day period or an enterprise license. Check the Open WebUI license text and its history file against your user count before you rebrand the interface. LibreChat and AnythingLLM are MIT licensed, and Onyx Community Edition is MIT licensed, but Onyx code under its ee directories falls under a separate enterprise license. Confirm which features your team needs before assuming the community scope covers them.

Scope also differs. Chat interfaces such as Open WebUI or LibreChat can host imported conversations as reference history, but they do not index your SharePoint, OneDrive or Outlook content with permissions, which is the function Copilot performs. Onyx covers that search and connector role, so an imported transcript and a rebuilt grounding layer are separate projects with separate owners. Ask the vendor or the project maintainers to confirm connector coverage and permission sync for your sources, and agree in writing who owns the archived export, how long it is retained and who may read it.

Deciding what to keep is a legal and records question for your organization and its counsel, not a technical default. Copilot prompts and responses sit in mailboxes, so the export itself does not tell you how long anything must be retained, which records are subject to a legal hold, or whether a given conversation is a business record. Before anyone runs an eDiscovery search, confirm who owns the retention schedule for AI interaction data, whether it falls under existing email or Teams retention policies, and what happens when a hold is placed on a custodian who has used Copilot. Those answers should be written down before the export workflow is designed, because they determine the scope, the date ranges and the format of what you pull.

DeployOpen prepares exports, evidence and documented controls, and can help you show how a retention decision was carried out. It does not provide legal advice, and it does not issue compliance certifications or audit reports. Those come from your counsel for legal questions and from independent auditors and certification bodies for attestations. Ask counsel to confirm the jurisdictions, regulators and contractual obligations that apply to your Copilot data, and ask your auditor which evidence they will expect to see, such as export logs, custodian lists and records of who accessed the packages.

If you plan to move Copilot history into a self-hosted assistant, treat the migrated copy as a new system of record with its own retention settings, access logs and disposal process. Confirm that the export preserves the metadata your schedule requires, that deletions in the source tenant are reflected or deliberately excluded, and that legal holds continue to apply to the copies. Document these decisions in the same place as your export procedure so that the record of what was kept, moved and destroyed is complete.