Which open-source option replaces Microsoft 365 Copilot for your teams
If your Copilot renewal is forcing a per-user cost question, or you need documents to stay inside your own tenant or network, Onyx is the closest fit for grounded, permission-aware answers over SharePoint and email, while Open WebUI and LibreChat fit teams that mainly want a chat-first assistant. The distinction matters because the first need is a search and retrieval problem, and the second is an interface problem. Decide which one you are actually buying before you compare licenses. Teams often start this review because of how Microsoft structures the offer. Microsoft 365 Copilot is sold as an add-on license to eligible plans such as Microsoft 365 E3, E5 and Business Premium, and Microsoft 365 E7 includes it. Microsoft Learn also states that work-based Copilot Chat, which grounds answers in content the user's Microsoft Entra account can access, requires a Microsoft Copilot license, while web-based chat only shows internet results. In practice, the grounded experience is the part that carries the license cost, so the question for your organization is how many users truly need answers over internal content and whether that requirement is uniform across the workforce.
Before you approve a replacement, confirm three things with your own environment: which plan and license each user holds today, which content sources must be searchable, and whether your identity provider and document permissions can be mirrored into a self-hosted index. Ask the vendor or your licensing partner to show exactly which entitlements change if a subset of users moves off the add-on. For the open-source side, check each connector's permission behavior in a pilot tenant, since a grounded answer is only as trustworthy as the access controls it respects.
Three open-source options and when each one fits
Each option below covers part of what Microsoft 365 Copilot does, but none replaces it one for one. Onyx is the option closest to permission-aware search over company content, while Open WebUI and LibreChat focus on chat interfaces that you can point at models and documents you control. Compare them against your connector, sign-in and model requirements before you choose.
Onyx for permission-aware search
Onyx is the card to read first if your main need is answers grounded in SharePoint, OneDrive, Outlook, Teams and email. Its repository includes connectors for these sources, and it indexes applications with their permissions and supports SSO through Google OAuth, OIDC or SAML, plus SCIM provisioning. Its Community Edition is MIT licensed, but code in the ee directories falls under the Onyx Enterprise License, so check which features your team depends on. Confirm that each connector honors source permissions in your tenant before you rely on it for sensitive content.
Open WebUI for offline chat
Open WebUI fits teams that want a self-hosted chat interface that can run entirely offline, typically with Ollama or another OpenAI-compatible API. It installs with Docker, Python pip or Kubernetes, which suits platform teams that already run those tools. Its license is a BSD-3-Clause style license with an added clause on branding, which limits removing or altering branding unless a deployment has 50 or fewer users in a rolling 30-day period, the copyright holder grants permission, or an enterprise license is bought. Have legal review that clause before rollout, and note that it does not cover document connectors in the way Onyx does.
LibreChat for multi-provider chat
LibreChat is MIT licensed and suits organizations that want one chat front end across several model providers, including Azure OpenAI, Anthropic, Google, AWS Bedrock and Ollama. Its agent framework supports Model Context Protocol (MCP), and it offers multi-user sign-in through OAuth2, LDAP and email. Choose it when login and model routing matter more than a built-in document index. Confirm how your chosen identity provider maps to its roles, and plan for document retrieval separately, since search over SharePoint and email is not its core strength.
AnythingLLM for document chat
AnythingLLM is a lighter option for chatting with uploaded documents. It is MIT licensed, runs as a Docker deployment or desktop app, supports multiple users and connects local or cloud models to ingested files. It fits small teams with a bounded document set rather than a live feed from Microsoft 365. Ask how it handles document updates and access control for each workspace before using it for shared content.
How each Copilot capability maps to open-source options
This table maps each Microsoft 365 Copilot capability to the open-source platform that covers it best, with the gaps called out in plain terms. Read the check marks as a starting point for testing, not as proof of behavior in your tenant. Connector scope and permission sync must be confirmed in your own environment before you rely on them.
| Copilot capability | Best-fit open-source option | Coverage and gaps | What to confirm |
|---|---|---|---|
| Grounded answers over SharePoint and OneDrive | Onyx | Onyx ships SharePoint and OneDrive connectors and indexes them for RAG chat. Coverage depends on the connector version you deploy. | Which sites, libraries and file types are indexed, and how often re-indexing runs |
| Email and Teams search | Onyx | Outlook, Microsoft Teams and Gmail connectors are in the Onyx connectors directory. Mailbox and chat scope is usually narrower than the native Microsoft search index. | Whether mailbox and Teams message scope matches your data policy and retention rules |
| Permission-aware answers | Onyx | Onyx indexes sources with their permissions, but the sync behavior for revoked or changed access is the item to test. Do not assume parity with Microsoft Graph-based grounding. | How permission changes propagate, and whether a removed user can still see prior answers |
| Entra ID sign-in | Onyx and LibreChat | Onyx supports SSO through OIDC or SAML and SCIM provisioning. LibreChat supports OAuth2, LDAP and email sign-in. Entra ID is reached through standard OIDC or SAML configuration. | Entra ID app registration, group mapping and SCIM behavior in your tenant |
| Multi-model choice | LibreChat and Open WebUI | LibreChat connects to OpenAI, Azure OpenAI, Anthropic, Google, AWS Bedrock and Ollama. Open WebUI works with Ollama and OpenAI-compatible APIs, including fully offline setups. | Which model providers your data terms permit and where inference runs |
| Web chat | Open WebUI | Open WebUI provides a self-hosted chat interface that runs offline. Web search grounding is a separate configuration choice, not a default. | Whether internet search is allowed and how outbound traffic is logged |
| Agents and actions | LibreChat | LibreChat includes an agent framework with Model Context Protocol support. Onyx also offers agents and actions. Microsoft 365 agents that act inside Office apps have no direct open-source equivalent. | Which tools agents may call, and who approves new MCP servers |
| Office document editing inside apps | Not applicable | No open-source option here drafts or edits content inside Word, Excel, PowerPoint or Outlook. Plan for copy-based workflows or a separate editing tool. | Whether users need in-app drafting or can work from generated text |
What you give up and the usual workarounds
Moving off Microsoft 365 Copilot removes some tight integration and vendor backing that many teams rely on daily. Each loss below comes with a workaround, and each workaround carries a cost you should size before committing to a migration path.
Native integration in Office clients
Copilot sits inside Word, Excel, Outlook and Teams, so users never leave the document they are editing. A self-hosted assistant runs in its own browser tab, so users copy text in and out. Workaround: embed the web UI in an intranet portal or pin it as a Teams or browser tab, and test whether your users accept the extra step. Confirm which Office add-in or embedding options your chosen platform supports before you promise parity.
Microsoft support and SLA terms
Microsoft 365 Copilot is backed by Microsoft's support contracts and service commitments. Open-source projects offer community support, and a commercial vendor for the platform is optional, not automatic. Workaround: buy a support subscription from the platform vendor or a managed services partner, and write the response expectations into your contract. Ask any provider to state its severity levels, response times and what it covers in writing.
Purview and sensitivity label enforcement
Microsoft Purview applies sensitivity labels, data loss prevention and retention rules to Copilot answers that draw on labeled files. A self-hosted assistant does not read those labels unless you rebuild the logic. Workaround: run separate classification and DLP tooling, and apply your label taxonomy to indexed sources at ingestion. Verify that label metadata survives the connector sync and that restricted content is excluded from answers.
Microsoft admin experience
Copilot is managed from the Microsoft 365 admin center alongside licenses, Entra ID groups and usage reports. A self-hosted stack has its own consoles for users, connectors, models and logs. Workaround: centralize identity through Entra ID or your IdP, export logs to your existing SIEM, and document the operational runbook for the new console. Ask who on your team will own upgrades, connector failures and user access reviews.
Phased transition with mixed licenses
Few organizations switch every user on the same day. Keeping Copilot for a defined group, such as executives or legal reviewers, while a pilot group moves to a self-hosted assistant is a common bridge. Workaround: define the pilot cohort, set exit criteria for each phase, and track license spend until the last Copilot seat is retired. Confirm the Copilot license terms with Microsoft before you reduce seat counts.
How Entra ID sign-in and permission-aware answers work in a self-hosted stack
Permission-aware answers depend on two things working together: the assistant must know who is asking, and it must apply the access rights of the source system when it retrieves content. In a self-hosted stack, Onyx is the platform with the most documented path for both. Onyx supports single sign-on through Google OAuth, OIDC or SAML and provisions users through SCIM, so a Microsoft Entra ID tenant can act as the identity source through either OIDC or SAML. Onyx also indexes many connected sources along with their permissions, which is the mechanism that is supposed to keep an answer from quoting a file the user cannot open. Confirm with Onyx which permission attributes each SharePoint, OneDrive and Outlook connector syncs and how group membership changes are reflected after a sync.
LibreChat documents OAuth2, LDAP and email-based multi-user authentication, so it can sign users in through an identity provider that supports OAuth2, but it does not index your SharePoint content, so it does not by itself reproduce document-level permissions. Open WebUI's enterprise identity options, including any SSO or SCIM support beyond its basic login, must be confirmed against the current documentation and your license tier before you design around them. Ask each vendor in writing which Entra ID features (group claims, conditional access handling, token lifetime and SCIM deprovisioning) are supported and tested. Treat deprovisioning as a required test case: a removed employee should lose access to both the assistant and the indexed content.
Permission sync must be tested per connector, not assumed from the platform name. For each source, create test accounts in Entra ID and SharePoint with different group memberships, restrict a sample of documents, and run the same questions as each account. Confirm that answers never surface documents the user cannot open in SharePoint, including after a permission change, a file move or a group removal, and record the sync interval that produced the result. Illustratively, if a restricted document is removed from a user's group, the test should show that the document disappears from answers after the next sync and that the time between those two events is known and acceptable to your security team. Include this test in the statement of work so the outcome is documented as evidence.
Which option fits by situation
This fit is for organizations whose main reason to look at Microsoft 365 Copilot is grounded search across company content, such as SharePoint files and mailboxes. Onyx is the candidate to evaluate first because its repository includes connectors for SharePoint, OneDrive, Outlook and Microsoft Teams, and it indexes sources with their permissions. Onyx also supports SSO through Google OAuth, OIDC or SAML and SCIM provisioning, which matter when access must follow Entra ID group membership.
- First test: Connect one SharePoint site and one mailbox with a test account, then confirm that a user without access to a document cannot retrieve it in an answer.
- Identity sync: Verify how group membership and permission changes propagate to the index, and how quickly removed access takes effect.
- Operating model: You run the Onyx services, including the document index, database and connector jobs, inside your own tenant or data center.
- Limit: Confirm which Microsoft connectors and content types are in the Community Edition versus the enterprise code under the Onyx Enterprise License.
Before committing, ask for a written list of the connectors, permission behaviors and SSO features that your edition includes.
This fit is for chat-first teams that want a familiar assistant interface and need models to run on their own hardware, including without internet access. Open WebUI works with Ollama and OpenAI-compatible APIs and can run entirely offline, so the model and the chat history stay on infrastructure you control. It installs with Docker, Python pip or on Kubernetes, which gives platform teams several entry points.
- First test: Install Open WebUI with Docker on a test host, pull a local model through Ollama, and confirm that chat works with the outbound network blocked.
- Hardware sizing: Measure response speed on your actual GPUs or CPUs before choosing a model size, since local inference is the main performance variable.
- Document grounding: Test whether the document features meet your needs, because Open WebUI is primarily a chat interface rather than a permission-aware search index.
- License: Read the Open WebUI License, which restricts removing or altering branding for deployments above 50 users in a rolling 30-day period unless an enterprise license is bought or the copyright holder grants permission.
Confirm the license terms against your user count and branding requirements before rollout.
This fit is for teams that want one interface across several model providers and need agents that call external tools. LibreChat is MIT licensed and supports OpenAI, Azure OpenAI, Google, Vertex AI, Anthropic, AWS Bedrock, Ollama and other providers. Its agent framework includes Model Context Protocol (MCP) support, so tools and data sources can be attached through a standard interface. Multi-user authentication covers OAuth2, LDAP and email.
- First test: Configure two providers, then confirm that each user sees only the models and agents assigned to their role.
- MCP integration: Connect one MCP server to a non-production system and review what data the agent can read and write.
- Document retrieval: Verify how file uploads and retrieval are handled, since LibreChat does not replace a permission-synced enterprise search index on its own.
- Operating model: Plan for Docker-based hosting, backups of its databases, and upgrades of the provider integrations you depend on.
Ask your provider contracts for data processing terms, because the model traffic leaves your environment when you choose a cloud model.
This fit is for small teams that want to chat with a defined set of documents and prefer a lightweight setup. AnythingLLM is MIT licensed and runs either as a Docker deployment or as a desktop app for macOS, Windows and Linux. It supports multiple users, connects local or cloud LLMs to ingested documents, and includes built-in agents and vector databases. For a single team working from a shared folder of files, the setup can stay small.
- First test: Install the desktop app on one machine, ingest a representative folder, and confirm that answers cite the correct documents.
- Multi-user mode: If several people need access, run the Docker deployment and test user roles before onboarding anyone.
- Source coverage: Check which file types and connectors you need, because AnythingLLM is built around ingested documents rather than broad enterprise connectors.
- Limit: Desktop installs do not provide central administration, so plan how updates, backups and access revocation will be handled for each machine.
Confirm with the project which current features support the access controls your team requires before storing sensitive files in it.
How to move users off Copilot in phases
This sequence moves Copilot users to a self-hosted assistant group by group, so each cohort's sources, permissions and prompts are proven before its license is removed. The output is a dated cutover record per group and a license list that Microsoft admins can act on.
Inventory Copilot users, use cases and sources
The IT owner, with business leads from each department, lists who holds a Copilot license, which tasks they use it for (drafting, meeting summaries, searching mail or files) and which Microsoft 365 sources those tasks touch, such as SharePoint sites, OneDrive folders, Outlook mailboxes and Teams channels. Ask Microsoft admins for the license assignment report and confirm which groups hold the add-on. The step is done when every user group maps to a use case and a source list.
Set up Entra ID sign-in
The identity team registers the self-hosted platform as an application in Microsoft Entra ID and configures OIDC or SAML sign-in, with group claims available for role mapping. Confirm with Microsoft admins which tenant, redirect addresses and group attributes they will allow, and whether conditional access policies apply to the new app. The step is done when a test user from each pilot group signs in and the platform receives their group memberships.
Scope connectors and test permissions in a pilot
The platform engineering team connects only the SharePoint sites, OneDrive folders, mailboxes and Teams channels from the inventory, using the connector configuration in Onyx or the equivalent chosen platform. A small pilot group then runs test queries that include documents they should not see, to confirm that answers respect source permissions after sync. Record each failure as a defect with the connector and permission scope involved. The step is done when the pilot shows no answers from restricted content for any test user.
Confirm Copilot history export expectations
Before pilot users stop using Copilot, the compliance lead asks Microsoft admins whether Copilot conversation history can be exported, in what format and under which retention settings. Do not assume an export path exists. Record the answer, what cannot be exported and who approves any gap. The step is done when the compliance lead holds a written answer from Microsoft admins and has agreed how users will keep any needed records.
Run the platform in parallel with Copilot
Pilot users and then wider groups use the self-hosted assistant alongside Copilot for the same tasks, and business leads compare answer quality, source citations and missing content. The platform team tracks which models are used and where answers fail, and adds sources or fixes permissions as needed. The step is done when each use case in the inventory has an agreed result on the new platform, with open gaps logged.
Cut over each group and retire its prompts
Each department moves to the self-hosted platform in turn, with users told which tool to use and where prior Copilot workflows are documented. Support contacts handle questions for a set period agreed in advance by the business owner. The platform team confirms sign-in, connector sync and permissions for each group before the next one moves. The step is done when the group's leads sign off and no active Copilot usage is reported for it.
Decommission Copilot license assignments
Once a group has cut over, the Microsoft admin removes its Copilot license assignments, and the IT owner updates the inventory to show the change date and remaining users. Confirm with Microsoft admins how removal affects Copilot Chat access and any other licensed features that the business still needs. Keep the cutover records and export confirmations with the compliance file. The step is done when the license report shows no assignments for migrated groups.
Questions buyers ask before replacing Microsoft 365 Copilot
Can Onyx fully replace Microsoft 365 Copilot?
For search and grounded chat over company content, Onyx covers much of the same job, but it is not a like-for-like swap. Onyx's Community Edition is MIT licensed and includes RAG, AI chat, agents and actions, while code in the ee directories falls under the Onyx Enterprise License, so confirm which features you need sit in which edition. Copilot is also tied to Microsoft 365 apps such as Word, Excel and PowerPoint, which Onyx does not replace. Map your daily Copilot use cases against Onyx's connectors and a test index before deciding whether the overlap is enough.
How does Onyx enforce document permissions in answers?
Onyx indexes more than 50 applications along with their permissions, so answers should reflect what each user could already open in the source system. The connectors directory in the Onyx repository includes SharePoint, OneDrive, Outlook, Teams and other sources. Permission behavior varies by connector and by how often permissions sync, so test with a user who has restricted access and confirm that a document they cannot see never appears in a citation. Ask the team running the deployment to document the sync interval and how removed access is handled.
Does Entra ID sign-in work with a self-hosted assistant?
Onyx supports SSO through Google OAuth, OIDC or SAML, and SCIM provisioning, so an Entra ID tenant can be connected through its OIDC or SAML endpoints. LibreChat offers OAuth2, LDAP and email authentication, and Open WebUI can be configured for single sign-on as well. Confirm the exact configuration for your tenant, including group claims used for access control, and check that deprovisioning removes access promptly. Your identity team should own the app registration and the claim mapping.
What does the internal team need to run it?
The internal team needs skills in container platforms, identity federation, database operations and model hosting. Onyx can be deployed with Docker, Kubernetes, Helm or Terraform, and Open WebUI installs with Docker, pip or Kubernetes, so the platform choice shapes the skill set. Plan for ownership of upgrades, backups, monitoring, connector credentials and model endpoints. Vendor-hosted Copilot shifts those tasks to Microsoft, while Glean's Customer Hosted model still has Glean manage upgrades, patching and monitoring. Decide early who is on call for the assistant.
Can we deploy it without outside help?
Your team can deploy a proof of concept on its own if it has container and identity experience, since the open-source projects publish install paths. Production use usually needs more: connector hardening, permission testing, backup and restore, upgrade planning and evidence for audits. Those tasks are where an implementation partner adds value. DeployOpen plans, implements, integrates, hardens, backs up, upgrades and documents self-hosted platforms in your own infrastructure, under a fixed-scope written agreement, with ongoing support available as a retainer. Ask any partner for a written scope before work starts.
How does the cost compare over several years?
The comparison depends on whether you count licenses, infrastructure and labor separately. Copilot is an add-on license to eligible plans such as Microsoft 365 E3, E5 and Business Premium, and Microsoft 365 E7 includes it, so per-user fees recur for as long as you keep the license. Open-source software has no license fee, but you pay for compute, storage, model inference or API usage, staff time and support. Build a five-year model with one-time setup and recurring run costs, and request quotes that itemize each component. Confirm current Microsoft pricing directly with Microsoft, since this page does not supply figures.
What does the Open WebUI license mean for branding?
Open WebUI uses the Open WebUI License, which is BSD-3-Clause style with an added clause on branding. You may not remove or alter Open WebUI branding unless the deployment has 50 or fewer users in a rolling 30-day period, the copyright holder grants permission, or you buy an enterprise license. Code committed before a specific commit remains under the earlier BSD-3-Clause terms, as recorded in the license history file. Have legal counsel review the Open WebUI LICENSE against your user count and white-labeling plans.
How is data residency handled in a self-hosted setup?
In a self-hosted deployment, you choose where data is stored because the platform runs in your own cloud account, data center or air-gapped network. Onyx documents an air-gappable deployment in which the document index, database and processing stay within a self-contained set of services. Model choice matters too: with Ollama, LiteLLM or vLLM you can keep inference local, but cloud model APIs send prompts to the provider. For contrast, OpenAI offers regional data residency for ChatGPT Enterprise, but only as an OpenAI-hosted service. Document where each component runs and which model endpoints receive data.
What a DeployOpen engagement covers for this migration
DeployOpen plans, implements, integrates, hardens, backs up and documents self-hosted platforms inside the client's own cloud accounts, data centers or air-gapped networks. For a move away from Microsoft 365 Copilot, that means the work covers the chosen assistant (Onyx, Open WebUI or LibreChat), the connectors to SharePoint, OneDrive, Outlook or Teams where they apply, the sign-in path through Entra ID, and the operational pieces around them such as backups, upgrades and documentation. Most engagements are fixed-scope, so the list of connectors, identity integrations, models and user groups is agreed in writing before any work starts. Readers should ask for that written scope to name each permission model they must preserve, since permission-aware answers are the requirement most often underestimated.
Scope also determines what the quote reflects. Before requesting one, confirm which source systems must be indexed, whether permissions from SharePoint and email must be synchronized, which identity provider and group structure must be honored, where the model runs (a hosted API or a self-hosted model), and who will operate the platform afterward. Each of these drives effort in a different way. Licensing terms also need checking separately, because the Onyx Enterprise License governs code in its ee directories and the Open WebUI License carries branding conditions that depend on user count. DeployOpen does not issue audit reports, attestations or certifications. Where a compliance assessment is involved, DeployOpen prepares systems, controls and evidence, and an independent auditor or certification body performs the assessment.
Ongoing work is available as a retainer for support, upgrades and continuous testing. This matters because a self-hosted assistant shifts patching, monitoring, index maintenance and model changes to the client's team or to a support agreement. Ask any implementation partner to state in writing who handles security updates, connector failures, reindexing after permission changes and restore testing for backups, and what happens to those responsibilities at the end of the initial scope. Those answers belong in the handover documentation, and they decide whether the migration reduces the operational load that prompted the review in the first place.
How DeployOpen scopes, migrates, hands over and supports the replacement
DeployOpen plans and implements self-hosted open-source assistants such as Onyx, Open WebUI and LibreChat inside your own cloud accounts, data centers or air-gapped networks. Each engagement starts with a written, fixed scope that covers connectors, identity, permissions and the documentation your team needs to run the system after handover.
How we scope
- Inventory which SharePoint, OneDrive, Outlook and Teams sources the assistant must index, and which ones stay out of scope.
- Confirm with your Microsoft Entra administrators how sign-in, group membership and document permissions should map into the assistant.
- Agree in writing on deliverables, timelines and acceptance criteria before any build work starts, since engagements are fixed-scope.
How we build
- Deploy the chosen platform with Docker, Kubernetes, Helm or Terraform in the hosting environment you select.
- Configure connectors and test that answers respect the source permissions of sample users, with results recorded in writing.
- Integrate your chosen model provider, whether a self-hosted model through Ollama, LiteLLM or vLLM or a hosted API, and document the data path.
How we hand over
- Deliver architecture, configuration, access and runbook documentation so your own platform or security team can operate the stack.
- Walk your administrators through user provisioning, connector maintenance, backups and upgrade steps during handover.
- Prepare control evidence and records for your compliance assessments, while noting that independent auditors issue any formal reports.
How we support
- Ongoing support, upgrades and continuous security testing are available as a retainer after handover.
- Ask us to confirm the license terms that apply to your user count and branding before rollout, including the Open WebUI license conditions.
- Agree on response expectations and upgrade cadence in the retainer scope so both teams know who patches and monitors what.
