Which to choose: Microsoft 365 Copilot or a self-hosted Onyx assistant
If your Copilot renewal is coming up, or a residency or audit requirement is forcing the question, the short answer is this: keep Microsoft 365 Copilot where your work lives inside Microsoft 365 and your licensing position is sound, and consider a self-hosted Onyx assistant when you need one search and chat layer across Microsoft and non-Microsoft sources, with the index, logs and model under your own control. Copilot fits teams that want in-app help in Word, Outlook and Teams, provided they hold an eligible license such as Microsoft 365 E3, E5 or Business Premium with the Copilot add-on. Work-based Copilot Chat grounds answers in content the user's Microsoft Entra account can reach, and that license requirement is the first thing to confirm with your Microsoft account team.
Onyx fits a different problem. It connects to SharePoint, OneDrive, Outlook and Teams alongside sources such as Google Drive, Confluence, Jira, Slack and Salesforce, and it syncs source permissions so answers draw only on documents each user can already see. You run it in your own cloud account or data center, choose the model (self-hosted through Ollama, LiteLLM or vLLM, or a proprietary API), and decide where the Postgres, index and query history live. Confirm before committing which Onyx features you need, because RBAC and some enterprise capabilities sit in the Enterprise Edition under the Onyx Enterprise License rather than the MIT-licensed Community Edition.
The decision turns on four questions. First, your licensing position: what Copilot seats cost you today and whether most of your value comes from in-app features you would lose. Second, where content, prompts and logs must legally reside, and whether a Microsoft-hosted service meets that. Third, model choice: whether you need a specific model, a self-hosted model on your own GPUs, or a managed API. Fourth, staff. Running Onyx means operating the index, database, model servers and connectors, and upgrades, so name the team that owns patching and connector health before you cut over. Many organizations run both side by side for a period, which the sibling migration guide covers.
Which option fits which scenario
This table maps common scenarios to the option that fits best and the condition that decides it. Read each row by asking which condition applies to your organization, since the right answer often depends on licensing, network location and where your documents live.
| Scenario | Better fit | Condition that drives the choice |
|---|---|---|
| In-app drafting in Word and Outlook | Microsoft 365 Copilot | Drafting inside the Office apps is the product's native strength. Confirm that your plan is eligible and that the Copilot license cost is acceptable per user. |
| Work-grounded chat over Microsoft content | Microsoft 365 Copilot | Microsoft Learn states that work-based Copilot Chat requires a Microsoft Copilot license. Without one, you get web-only chat. |
| Search across SharePoint plus Confluence or Jira | Onyx | Onyx ships connectors for SharePoint, Confluence and Jira in one index and syncs source permissions. Confirm the connector set against your sources before committing. |
| Air-gapped or disconnected networks | Onyx | Copilot depends on Microsoft cloud endpoints. Onyx documents an air-gappable deployment, but you must validate model serving and update handling inside your own network. |
| Strict restrictions on model providers | Onyx | Onyx can run self-hosted models through Ollama, LiteLLM or vLLM. Confirm which models your policy allows and whether they meet your quality needs for your tasks. |
| Small pilot with a few users | Open WebUI or AnythingLLM | Single-node tools reduce setup for a limited group. Check each license's branding and multi-user terms before expanding past a pilot. |
| Full-time operations with a platform team | Onyx | Self-hosting shifts patching, backups, upgrades and monitoring to your team. Confirm that staff and on-call coverage exist before moving production users. |
| Compliance evidence for audit trails and retention | Depends on your controls | Copilot prompts are stored in mailboxes and governed by Microsoft tools. Onyx audit and retention depend on your configuration. Confirm the evidence an assessor will request. |
How permissions and grounding differ between Copilot and Onyx
Copilot's work-based chat grounds answers in content the user's Microsoft Entra account can access, and that rule is the starting point for comparing it with Onyx. Onyx connects to 50+ applications and syncs their permissions, so an answer draws only on documents the user can already see in the source system. The two models rest on different mechanisms. Copilot inherits access from Microsoft's own identity and permission model across Microsoft 365 services. Onyx inherits access from each connector, which means its authorization is only as accurate as the permission data it pulls from every source. Before you choose, map each source you plan to index (SharePoint, OneDrive, Outlook, Teams, Confluence, Jira, Slack and others) to the permission model it uses and confirm, source by source, how Onyx mirrors it.
Three conditions decide whether that model holds in production. First, permission sync accuracy varies by connector, so review the connector documentation in the Onyx connectors directory on GitHub and test inherited groups, nested sharing and externally shared items for each source. Second, permissions go stale between sync cycles. A user removed from a group or a document unshared can still appear in answers until the next sync, so confirm the sync frequency in your deployment and decide whether that gap is acceptable for your most sensitive content. Third, identity mapping matters: Onyx needs its users to match the identities in each source, so confirm how Entra ID sign-in through OIDC or SAML maps to the account names used by each connector.
Test with real user accounts before go-live, not only with administrator accounts that see everything. Pick users from several departments and at least one restricted group, ask each one to search for documents they should not see, and record every result. Repeat the test after you revoke a permission and wait through a sync cycle to measure how long the old access persists. Keep those results as evidence for your security and compliance reviews. Copilot's own behavior should be tested the same way in your tenant, because your sharing settings and Microsoft Graph configuration determine what Copilot can reach, and Onyx cannot reproduce them automatically.
Where data lives and who controls it
Copilot and Onyx differ mainly in where processing runs, who operates it, and who holds the logs. The cards below separate what Microsoft operates from what your team deploys, and what each side can show an auditor.
Where Copilot processing runs
Microsoft 365 Copilot runs inside Microsoft's cloud and is bound to your Microsoft 365 tenant, so prompts, grounding and responses are handled by services Microsoft operates. You do not choose the compute location or the inference hosts. Check with Microsoft which data boundary and region commitments apply to your tenant and which Copilot features fall outside them, before you assume residency.
Where Onyx indexes and logs live
An Onyx deployment keeps its document index, Postgres database, Redis and model servers in infrastructure you choose, deployed with Docker, Kubernetes, Helm or Terraform. Your team decides where the connectors run, where index data sits and how long query history is kept. The practical question is who holds each volume and backup, and whether those locations match your residency rules.
Air-gapped operation with Ollama or vLLM
Onyx documents an air-gappable deployment in which the index, database and processing run within a self-contained set of services. Paired with self-hosted models served by Ollama or vLLM, prompts never leave your network. Confirm that every connector you need can sync from inside the isolated network, and plan how software, model weights and security updates reach the disconnected environment.
Entra ID versus self-managed identity
Copilot inherits sign-in and group membership from Microsoft Entra ID. Onyx supports SSO through Google OAuth, OIDC or SAML and SCIM user provisioning, so you can point it at Entra ID or at another identity provider you run. Decide which directory is the source of truth for users and groups, because permission sync depends on the identities the source applications recognize.
Enterprise Edition RBAC and audit
Onyx lists role-based access control, usage analytics and query history auditing among its enterprise features, and these sit in the Enterprise Edition rather than the MIT-licensed Community Edition. Copilot's audit and retention controls come from Microsoft Purview. Ask for a written list of which audit fields, retention settings and admin roles you get in each Onyx edition before comparing them with your current Purview setup.
Compliance evidence each side provides
Microsoft publishes its own compliance documentation for Copilot, and you configure the tenant controls that apply to your data. With Onyx, your team or DeployOpen prepares the configuration, logs and runbooks that an assessment will examine. Independent auditors issue any audit report or certification. DeployOpen prepares evidence for these reviews but does not issue audit reports, attestations or certifications.
Licensing and editions on each side
Microsoft 365 Copilot is sold as an add-on license on top of eligible Microsoft 365 plans, such as E3, E5 and Business Premium, so the assistant cost sits on top of the suite you already pay for. Microsoft 365 E7 includes it. Web-based Copilot Chat is included with eligible subscriptions at no extra cost, but work-based Copilot Chat, which grounds answers in content your Microsoft Entra account can reach, requires a Microsoft Copilot license.
- Add-on licensing: Copilot is a per-user license layered onto a base suite, so the assistant seat count and the suite seat count can differ.
- Included tier: Web Copilot Chat comes with eligible subscriptions, but it only shows internet results and does not search your tenant.
- Bundled tier: Microsoft 365 E7 includes Copilot, which changes the comparison if you are already evaluating that plan.
- Vendor-managed terms: Usage rights, product naming and plan eligibility are set by Microsoft and have changed over time, since Microsoft Learn now refers to the product as Microsoft Copilot.
Confirm with your Microsoft account team which plans and add-ons apply to your tenant and region, and get the current terms in writing before you plan a renewal.",
Onyx Community Edition is MIT licensed and covers retrieval-augmented generation, AI chat, agents and actions. Under the MIT license you can run it internally, modify it and redistribute it, subject to the license notice. Your organization pays for infrastructure, models and staff time, not for the software license itself.
- Permissive core: The MIT terms apply to the community code, which is the part that handles chat, retrieval and agents for most deployments.
- Separate ee code: Code in the ee directories is under the Onyx Enterprise License, so it is not covered by the MIT grant.
- Internal use: Running the community edition for your own staff does not require a commercial license, but you should confirm how the terms apply to any external distribution.
- Connector scope: Connector code in the repository is part of the community project, so you can review the source before you deploy it.
Read the LICENSE file in the repository and the ee directory notices together, because the boundary between the two determines which features you can run without an enterprise agreement.",
The ee directories in the Onyx repository contain premium code under the Onyx Enterprise License. Features built from that code, such as role-based access control and other enterprise capabilities, are governed by that license and not by MIT. If you use them, your right to run, modify or distribute them depends on the terms in that license.
- Different license text: The Onyx Enterprise License governs ee code, so MIT permissions do not carry over.
- Feature mapping: Confirm which enterprise features live in ee directories, since the README lists capabilities such as SCIM provisioning and RBAC without mapping each to a directory.
- Build decisions: If you fork or patch the codebase, ee files need separate review before they go into an internal image.
- Commercial terms: The license text does not set prices, so ask Onyx for the commercial terms that apply to your use.
For a regulated deployment, ask your counsel to review the ee license alongside your internal distribution plans before you build images from the repository.",
Onyx is available three ways: self-hosted open source, Onyx Cloud as a managed service, and a self-hosted Enterprise Edition with premium features such as RBAC. Onyx Cloud moves hosting and operations to the vendor, while Enterprise Edition keeps the deployment in your environment and adds commercially licensed features. The choice affects where your data sits and which license governs each feature.
- Onyx Cloud: A managed service where Onyx runs the infrastructure, so your documents and queries sit in the vendor's hosting.
- Self-hosted Enterprise Edition: You run the stack in your own infrastructure and receive premium features under a commercial agreement.
- Feature split: Premium capabilities such as RBAC are in the Enterprise Edition, so the community edition alone may not meet every access requirement.
- Quote scope: Ask whether support, upgrades and the enterprise license are separate line items and what each one covers.
Before you choose a path, confirm with Onyx which edition includes each feature you need and whether the license permits your intended internal use, since the answer depends on the agreement and not on the open-source README alone.
What each option costs to run
Copilot is a per-user license bundled with a Microsoft plan, while a self-hosted Onyx deployment is a set of components you pay for directly: compute, storage, models and operations. The cards below separate one-time work from recurring spend and name what moves each cost, so you can ask vendors and integrators for comparable quotes.
Copilot add-on licensing
Microsoft 365 Copilot is an add-on license on top of an eligible plan such as E3, E5 or Business Premium, and Microsoft 365 E7 includes it. Your recurring cost depends on how many users you license and which base plan you already pay for, so check whether some users already hold a bundle. Web-based Copilot Chat is included with eligible subscriptions, but work-based grounding in your Entra-accessible content requires the paid license. Confirm the exact per-user terms in your Microsoft agreement, not from list pricing.
Model inference on GPUs or APIs
Onyx can call model APIs such as OpenAI, Anthropic or Gemini, or self-hosted models served through Ollama, LiteLLM or vLLM. API spend is usage-based and recurs with query volume and context length, while GPU hardware is largely a capital purchase with power, cooling and hosting that recur. Model choice is the largest swing factor, because a larger model needs more GPU memory. Ask the integrator to size throughput against your peak concurrent users, not your average.
Index, database and cache hosting
Onyx's documented infrastructure includes Postgres, Vespa or OpenSearch for the index, Redis and model servers. These run as containers or Kubernetes workloads in your cloud account or data center, so you pay for compute, persistent volumes and backups. Index storage grows with source volume, including SharePoint, OneDrive, Outlook and Teams content, and with re-indexing frequency. Ask for sizing based on your document count and sync schedule.
Connector setup and permission sync
Connecting SharePoint, OneDrive, Outlook, Teams and other sources is a one-time integration effort, followed by a recurring cost to keep connectors, app registrations and credentials healthy. Permission sync is what keeps answers limited to documents each user can already see, so test it against sample users in every source. Each additional source adds build and test work. Ask the integrator to list connectors in scope, who will own the Entra app registrations, and how credential rotation is handled.
Onyx Enterprise Edition features
Community Edition is MIT licensed and covers RAG, chat, agents and actions, but code in ee directories falls under the Onyx Enterprise License. Features such as role-based access control and some enterprise administration are part of the self-hosted Enterprise Edition, which is a license cost you pay in addition to infrastructure. Confirm which controls your compliance team needs before you budget for it. Ask the vendor to show, in writing, which features sit in each edition.
Ongoing operations and uptime
Operations are the recurring cost most often underestimated. Someone must patch the stack, upgrade Onyx and its Helm chart, monitor the index, rotate credentials, test backups and respond to outages. Uptime needs drive cost: a tool used during business hours needs far less redundancy than one that staff depend on for every workflow. Ask whether support is covered by a retainer, what the upgrade cadence is, and who is on call, and whether the quote includes a tested restore.
What a move from Copilot to Onyx involves
The sequence starts with what people actually use Copilot for and ends with licenses retired at renewal, so each step produces evidence that the replacement works before any contract is cut. Most of the work is in connectors, permissions and workflow change rather than in the assistant itself.
Inventory Copilot use cases and dependencies
Survey the pilot population and the business owners to list what people ask Copilot to do, and which Microsoft content each task depends on: SharePoint sites, OneDrive folders, Outlook mail and calendars, Teams chats and channels. Record which tasks are search and question answering over company content, which are in-app drafting in Word or Outlook, and which depend on Copilot features outside Onyx's scope. The step is done when each use case has an owner, a source list and a disposition: migrate, change workflow, or keep Copilot for now.
Map permissions and content ownership
Confirm with your Microsoft 365 administrators which sites, libraries and mailboxes hold content that must stay restricted, and which groups or sensitivity labels govern it. Check how Onyx's permission sync reflects those controls for each connector you plan to enable, and identify any source where sync behaves differently from what your access model expects. The output is a written permission test plan with named test accounts for each restricted area.
Configure connectors for Microsoft sources
Deploy Onyx in your own environment and register the SharePoint, OneDrive, Outlook and Teams connectors against the scopes you approved in the previous step. Start with the sources that carry the highest share of the inventoried questions, and confirm each connector's current setup requirements in the Onyx documentation for your release. The step closes when each connector completes an initial sync and a sample of indexed items matches what the test accounts can see in the source applications.
Connect Entra ID sign-in
Configure single sign-on so users authenticate to Onyx with the same Entra ID account they use for Microsoft 365, using OIDC or SAML as your identity team prefers. Decide with the identity team how group membership maps to Onyx roles and whether user provisioning through SCIM will be used. The step is done when test users sign in, receive only the roles you assigned, and a deprovisioned account loses access as expected.
Select and host models
Choose the model path that fits your data handling rules: a self-hosted model served through Ollama, LiteLLM or vLLM, or a hosted provider that Onyx supports. Ask the model provider and your security team to confirm where prompts and responses are processed, how long they are retained, and whether they are used for training. Measure answer quality on a fixed set of questions drawn from the inventory, and record the results. The output is an approved model list with its hosting location and a benchmark record.
Run a parallel pilot with a defined group
Give a pilot group access to Onyx while they keep Copilot, and ask them to log the tasks they moved, the answers they checked against source documents, and the cases where Onyx missed content or returned content it should not. Review the Onyx query history and usage analytics with your audit team to confirm the logs answer your retention and review questions. The step is done when the pilot has run long enough to cover the use cases in the inventory and the open defects are either fixed or accepted in writing.
Enable users and redesign drafting workflows
Train pilot users and then wider groups on the new interface, and publish guidance on what Onyx answers reliably and what it does not do. In-app drafting inside Word and Outlook has no direct Onyx equivalent, so define replacement workflows: drafting in the native applications with Onyx used for research and source lookup, or approved templates stored in a connected source. The step is complete when each retained drafting use case has a documented workflow and a named owner.
Retire Copilot licenses at renewal
Before the renewal date, confirm with procurement which Copilot add-on licenses are in scope, remove assignments from users who have moved, and check whether any retained use cases still require Copilot. Export any Copilot content your records or legal hold require using the method your Microsoft administrators confirm, and document the decision. The step is done when license counts match the remaining users, the export and retention record is filed, and the renewal decision is signed off by the business owner.
Questions buyers ask before switching from Copilot
What does a migration from Copilot to Onyx cost in effort, and what drives it?
The effort depends mostly on how many sources you connect, how complex your permission model is, and how much of your Copilot use is in Word and Outlook rather than search. Cost has two parts: the one-time work of standing up the platform, connecting sources and validating permissions, and the recurring cost of inference, infrastructure and operations. Onyx itself is MIT licensed in its Community Edition, so the software line is not a per-user fee, but the Enterprise Edition features, if you need them, are licensed separately. Ask any implementation partner for a quote built from a written scope listing connectors, identity integration, models and handover, and ask them to separate one-time work from recurring operations.
How long does a pilot take, and what does it depend on?
A pilot length is not fixed. It depends on the number of sources, whether SharePoint and Teams permissions must sync correctly on day one, the identity provider integration, the choice of model (hosted API or self-hosted through Ollama, LiteLLM or vLLM), and how many users test it. Start with one or two sources and a small user group, then confirm that answers respect the permissions users already have in the source application. Agree on the pilot exit criteria in writing before it starts, so the timeline follows from the criteria rather than from a guess.
What does my team need to provide for the work?
Expect to provide named owners for identity, the source applications (SharePoint, OneDrive, Outlook, Teams and any others), and the infrastructure where Onyx will run. Your security team should define which groups may see which content and approve the model providers, and your platform team should supply the container or Kubernetes environment and storage. Someone from the business needs to test real questions with real documents. Confirm these responsibilities in the written scope so no step depends on a person nobody assigned.
Can we run the migration ourselves without an outside team?
Yes, if your team already runs containers, identity integrations and a search service. Onyx publishes Docker, Kubernetes, Helm and Terraform deployment options, so an internal team can build it. The harder parts are usually permission sync across connectors, Entra ID sign-in through OIDC or SAML, model hosting, backups and upgrades. Be honest with yourselves about on-call coverage and upgrade cadence before you decide. An outside implementation partner can take on a fixed scope, such as the connector set and hardening, while your team keeps operating the platform.
Does Onyx replace Copilot's features inside Word and Outlook?
No, not in the same way. Copilot's in-app features, such as drafting in Word or summarizing a thread in Outlook, run inside the Microsoft applications. Onyx is a separate chat and search interface over connected content, so it can answer questions from your SharePoint, OneDrive, Outlook and Teams sources, but it does not add a drafting button to Word. If in-app writing assistance is central to your users, plan for a separate tool or accept that workflow will change. Confirm this gap with your users during the pilot.
How do audit and retention compare with Microsoft Purview?
Copilot interactions are stored in users' Exchange Online mailboxes and can be searched and exported with Purview eDiscovery. With Onyx, query history auditing and usage analytics are listed among its enterprise features, and retention is set by the storage and database you operate. Purview covers the Microsoft estate broadly, while your Onyx audit trail covers queries made through Onyx. Confirm with your compliance lead which events you must retain, how long, and where the logs go, and confirm the exact audit fields in the current Onyx Enterprise Edition documentation before relying on them.
What should we confirm about Onyx Enterprise Edition and connector coverage?
Confirm three things in writing. First, which features you need, such as role-based access control, SCIM provisioning and query history auditing, and whether each is in the Enterprise Edition under the Onyx Enterprise License, since code in ee directories is under that license. Second, that every source you need has a connector in the current repository, including SharePoint, OneDrive, Outlook, Teams and any line-of-business systems, and that its permission sync behaves as you expect. Third, the current release and Helm chart version you will deploy. Check these against the Onyx GitHub repository and its license file before committing.
What to confirm before you decide
Start with licensing, because the comparison only holds for the plans you actually run. Confirm with Microsoft which Copilot license applies to your current Microsoft 365 plan, since the Microsoft Learn licensing page describes add-on eligibility by plan and states that work-based Copilot Chat needs a Copilot license while web chat does not. Then confirm Onyx's connector behavior in your own tenant. Test that a standard user sees only the SharePoint sites, OneDrive files, Teams channels and Outlook content they can already open, and that a permission change in the source application is reflected in search results after the next sync. Record which connectors you need and whether each one is in the Community Edition or requires the Enterprise Edition features such as RBAC.
Next, confirm which models your data rules allow. Onyx can use self-hosted models through Ollama, LiteLLM or vLLM, or proprietary providers such as Anthropic, OpenAI and Gemini, and the choice decides where prompts and retrieved passages are processed. Ask your legal, privacy and security teams to approve each model endpoint in writing, including any provider-side retention terms. Also confirm what your audit requirement actually is: which query history, usage analytics and user activity records you must keep, for how long, and in what format an auditor or eDiscovery reviewer will accept. Check that Onyx's query history auditing and your log storage meet that requirement, and that you can export records without relying on a vendor console. Finally, define how the air-gapped or restricted deployment will be updated. Confirm with Onyx which release and Helm chart versions you will pin, how images and chart packages are transferred into your network, and how you will test an upgrade before moving it into production. Verify the license terms that apply to the version you select, including the Onyx Enterprise License on code in ee directories, with your procurement and legal teams. Your own environment settles the rest: the GPU capacity for inference, the database and index hosting you will operate, and who on your team owns patching and monitoring.
How DeployOpen helps you evaluate and move
DeployOpen plans and implements self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For Microsoft 365 Copilot vs Onyx, we start with the permission model, data sources and model choices your organization actually needs, then deliver a tested, documented deployment you operate.
How we scope
- Written scope listing which Microsoft 365 and non-Microsoft sources Onyx will connect, such as SharePoint, OneDrive, Outlook and Teams.
- Permission mapping review confirming that synced source permissions match your current Entra ID groups and access rules.
- Decisions on model hosting, identity sign-in through OIDC or SAML, and which audit and retention records you must keep, agreed before work starts.
How we build
- Deployment with Docker, Kubernetes, Helm or Terraform inside your environment, with the Onyx edition and services set out in the scope.
- Connector configuration and a test plan that checks answers only draw on documents each sample user can already open in the source application.
- Model connection through Ollama, LiteLLM, vLLM or a proprietary provider, with hardening and network controls applied to the index, database and processing services.
How we hand over
- Documentation of architecture, connector settings, permission sync behavior, backup procedures and the license terms that apply to your edition.
- Runbooks for upgrades, reindexing and offline update handling, so your team can operate the platform without us.
- Evidence packs covering configuration, access tests and audit logging, prepared for your internal reviewers or independent auditors to assess.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer, scoped in writing alongside the original engagement.
- Periodic re-testing of permission sync and connector behavior after source application or Onyx releases change.
- A quote follows from the written scope, so confirm with us which items recur, such as support hours, and which are one-time, such as the initial build.
