Migrate from ChatGPT Enterprise to Onyx: what moves and what does not
Most of the work in moving a ChatGPT Enterprise use case that is mainly questions over company documents to Onyx is connecting Onyx to the sources people currently paste or upload from, rebuilding permissions and identity, and choosing the models that answer. Conversation history and GPT records are a separate and smaller concern. The team that usually carries this is a platform or IT engineering group working with the security owner for the identity systems and the business owners of each source, because the connectors need service accounts and the permission model has to match what those owners already enforce. The effort and risk rise with the number of sources, how many of them carry sensitive or inconsistent permissions, and how complete the identity provider setup already is. Before you commit, list every source your users currently draw from, including shared drives, wikis, chat channels and ticket queues, and note which ones have stale or overly broad sharing.
Onyx's connectors are the part that replaces what ChatGPT Enterprise users currently do by hand. The Onyx repository includes connectors for SharePoint, OneDrive, Outlook, Microsoft Teams, Google Drive, Gmail, Confluence, Jira, Slack, Salesforce and other sources, and Onyx syncs their permissions so answers only draw on documents the user can already see in the source application. Confirm for each source you need that the connector supports document-level permission sync in your deployed version, and test with a user who should not see a restricted folder. On the identity side, Onyx supports SSO through Google OAuth, OIDC or SAML, and SCIM user provisioning is listed among its enterprise features. Check which of these your identity provider supports and whether group membership, not only user records, flows through to Onyx. Model choice is independent of the migration itself: Onyx works with self-hosted models through Ollama, LiteLLM or vLLM as well as providers such as Anthropic, OpenAI and Gemini, so decide where inference runs before you size the stack.
Conversations and custom GPT records do not move into Onyx automatically, and this is where the migration needs the most care about what you keep. Export and retention are handled through the ChatGPT Enterprise Compliance API, which is the documented path for admin retrieval of conversations and GPTs, and the OpenAI enterprise privacy page describes the retention controls you will be retiring. Decide whether historical conversations need to be kept at all, since most document-question use does not require them, and if they do, plan a separate import rather than assuming Onyx will carry them over. Licensing also needs a check before rollout: the Community Edition is MIT licensed and covers RAG, chat, agents and actions, while code in ee directories falls under the Onyx Enterprise License. Ask the vendor which features your required controls depend on, such as RBAC, usage analytics and query history auditing, and confirm whether they sit in the Community Edition or the enterprise license before you plan the rollout.
How ChatGPT Enterprise capabilities map to Onyx
This table maps the capabilities a ChatGPT Enterprise workspace provides onto Onyx, row by row, for teams whose main use is chat grounded in company documents. Read each status as a starting point for a pilot, not a verdict: confirm exact feature parity in the Onyx docs and the Enterprise license terms before you plan around it. The main takeaway is that source connectors and permission sync are where Onyx differs most, while retention and residency move from an OpenAI setting to your own infrastructure.
| Capability | Onyx in your infrastructure | Status |
|---|---|---|
| Document grounding | RAG over indexed company sources is part of the MIT Community Edition, so answers cite the files they draw on. | Clean |
| Source connectors | Connectors exist for SharePoint, OneDrive, Google Drive, Confluence, Jira, Slack and other sources, replacing manual uploads and pastes. | Needs rework |
| Permission handling | Onyx syncs source permissions so answers draw only on documents the user can already see. Test this against your real access groups. | Needs rework |
| SAML SSO | Onyx lists Google OAuth, OIDC or SAML. Confirm which options your edition enables and whether SAML is in the Enterprise license. | Needs rework |
| SCIM provisioning | Onyx lists SCIM user provisioning among enterprise features. Confirm the license tier and the identity provider you use. | Needs rework |
| Admin retention and audit | Retention and deletion are set by your own database and logging settings, and query history auditing is listed as an enterprise feature. There is no OpenAI-style admin export path to rely on. | Gap |
| Model choice | Works with self-hosted models through Ollama, LiteLLM or vLLM, plus providers such as Anthropic, OpenAI and Gemini. | Clean |
| Data residency | Residency follows where you host the index, database and model endpoints. Choose the region yourself and document it. | Clean |
| Custom GPTs or assistants | Onyx offers agents and actions in the Community Edition. Map each custom GPT to an agent and check sharing rules by hand. | Needs rework |
Which data and integrations to move, and which to rebuild
A ChatGPT Enterprise migration to Onyx splits into three workstreams: conversation records, the company content Onyx will search, and the identity layer that decides who sees what. Conversation history and search content are separate things, so each needs its own decision. Identity has to be rebuilt in the new stack rather than carried over.
Conversation history through the Compliance API
The documented export path for ChatGPT Enterprise is the Enterprise Compliance API, which lets workspace admins retrieve conversations and GPT records for audit. Confirm with OpenAI which fields, attachments and GPT configurations the export covers and which it leaves out before you plan the cutover. Decide whether you need the archive for legal hold, for continuity of user history, or both, because the answer sets how much you import and where it is stored.
Chat history is not search content
Past conversations do not become Onyx search results on their own. Onyx answers from the documents its connectors index, so a chat transcript is only searchable if you deliberately store it as a document source. Treat exported conversations as an archive for records and reference, and decide which content users actually need Onyx to find, such as policies, runbooks and project files they currently paste into chats.
Connectors for the sources users paste from
Map the files and pages people currently upload or paste into ChatGPT to Onyx connectors. The repository includes connectors for SharePoint, OneDrive, Google Drive, Confluence, Jira, Slack and Salesforce, among others. Check each connector's supported object types and sync behavior in your version, since a connector that indexes pages may not index attachments or comments in the same way.
Permission sync decides what answers can show
Onyx syncs source permissions so answers only draw on documents the requesting user can already see in the original application. Test this with a pilot group that includes restricted sites, private channels and shared folders. Confirm how often permissions refresh and how removed access is handled, because a stale permission mapping is the most likely source of an overexposed answer after migration.
Identities, groups and SCIM rebuilt
ChatGPT Enterprise user accounts, workspace roles and any group mappings do not move into Onyx. Rebuild them through your identity provider using the SSO options Onyx supports, which include Google OAuth, OIDC and SAML, and provision users with SCIM. Map roles to Onyx RBAC, which sits in the Enterprise Edition, before you invite users, and confirm how deprovisioning removes access to conversations and connected sources.
Edition scope and license checks
Onyx Community Edition is MIT licensed and covers RAG, chat, agents and actions, while code in the ee directories falls under the Onyx Enterprise License. Confirm with the vendor which features your target design needs, such as RBAC, usage analytics or query history auditing, and whether they sit in the Enterprise Edition. Ask for that list in writing before you commit to a design that depends on a specific feature.
Migration sequence from inventory to decommission
This sequence moves a ChatGPT Enterprise workspace to a self-hosted Onyx deployment in controlled stages, so each group of users and sources is proven before the old workspace is switched off. Each step ends with a written output that the next step depends on.
Inventory prompts, uploads and sources
Before any installation, the workspace admin and a few power users list the document sources people currently paste or upload into ChatGPT, the recurring prompts that depend on them, and the teams that rely on each one. Map each source to its system of record, such as SharePoint, Google Drive, Confluence or Slack, and note who can see it there today. The output is a register of sources, owners and dependent users, with a flag for any content that lives only in uploads and has no system of record. Confirm with your compliance lead which conversation records must be retained before you start.
Pilot with limited connectors and a test identity provider
Deploy Onyx in your own infrastructure using the deployment option your platform team has chosen, and connect only two or three sources from the register to a test identity provider and a small pilot group. Confirm that a pilot user sees the same documents in Onyx that they see in the source application, and that a user without access to a restricted folder receives no answer drawn from it. Record which model provider is configured and test answers against a fixed set of questions taken from real prompts. The output is a signed-off pilot report listing connector behavior, permission test results and any gaps in the Community Edition feature set that the team must resolve or accept.
Run in parallel with ChatGPT Enterprise
Keep ChatGPT Enterprise live while the pilot group and then wider teams use Onyx for the same questions. Compare answer quality, citation accuracy and response time on the fixed question set, and log every connector sync failure or permission mismatch in an issue tracker. Agree in advance with the business owners which workflows must be proven in Onyx before cutover, and keep the workspace admin's export path open. The output is a parallel-run log showing that each in-scope workflow passed the agreed checks, with open defects assigned to owners.
Cut over SSO and SCIM provisioning
Switch Onyx from the test identity provider to your production provider using SSO through OIDC, SAML or Google OAuth, then enable SCIM provisioning so that joiners, movers and leavers are created, changed and removed automatically. Test one user from each role group and confirm that a deprovisioned account loses access to the chat interface and to indexed content. Check group-to-role mapping against the RBAC design, which is listed among the enterprise features rather than the Community Edition. The output is a tested provisioning runbook and a signed record that every role group maps to the intended permissions.
Communicate the change and move users
Tell users which questions Onyx answers, which sources it covers, what it does not cover, and the date after which ChatGPT Enterprise access ends. Provide two or three example prompts that replace their usual paste-and-upload habit and point them to a named support contact for missing sources. Remove sign-in links to ChatGPT Enterprise from internal wikis and onboarding material. The output is a sent communication, a support queue for the first weeks, and a count of active Onyx users compared with the ChatGPT Enterprise seat list.
Export records and decommission ChatGPT Enterprise
Using the Compliance API path that your workspace admin can access, export conversation and GPT records that the retention policy requires you to keep, and store them in an access-controlled location you own. Confirm the export covers the scope your compliance lead defined and document what it leaves out. Then remove users, revoke API keys and cancel the subscription only after your records are verified. OpenAI states that deleted conversations are removed from its systems within 30 days unless legally required, so note that date in your decommission log. The output is a verified archive, a decommission checklist signed by the business owner and the security lead, and a retention schedule for the exported records.
How the migration changes by starting point
When most company knowledge sits in SharePoint, OneDrive, Outlook and Microsoft Teams, the migration centers on the Microsoft connectors in the Onyx repository. Onyx syncs document permissions from these sources, so an answer should only draw on files the user can already open in Microsoft 365. Test that claim with a few accounts before you rely on it, especially for sites with broken inheritance or group-based access.
- Connectors: Configure the SharePoint, OneDrive, Outlook and Teams connectors and confirm which site collections, libraries and mailboxes are in scope.
- Identity: Sign-in can run through OIDC or SAML against Microsoft Entra ID, with SCIM provisioning to keep users and groups current.
- Permissions: Compare a sample of search results against what each test user sees directly in SharePoint.
- Model hosting: Choose between a hosted model API and self-hosted models through Ollama, LiteLLM or vLLM, based on your data handling rules.
- Copilot licensing: Your existing Microsoft Copilot licenses do not transfer to Onyx, so review which users still need them.
Confirm with Microsoft and Onyx how each connector handles your tenant configuration before the pilot starts.
Teams whose knowledge sits in Google Drive and Gmail follow a shorter connector path, since Google Workspace is one of the sources the Onyx connectors directory covers. Google accounts can also sign in through Google OAuth, which avoids a separate identity provider for many small and mid-sized organizations. Decide early whether Gmail belongs in the index, because mail carries a different privacy and retention profile than shared documents.
- Connectors: Set up Google Drive and Gmail connectors, scoping shared drives and mailboxes deliberately rather than indexing everything.
- Identity: Google OAuth covers sign-in, and SCIM or OIDC can be added if you run a central directory.
- Permissions: Verify that shared drive membership and file-level sharing appear correctly in Onyx results.
- Model hosting: Google's own models can be reached through the supported proprietary providers, or you can run open-weight models on your own GPUs.
- Retention: Decide how long indexed mail stays in the index and who can review query history.
Check which Workspace edition and admin roles you hold, since they determine what the connectors can read.
Engineering-heavy organizations usually keep specifications, runbooks and tickets in Confluence and Jira, and the migration then depends on how well those spaces and projects are structured. Onyx connects to both, so the work is less about new integrations and more about deciding which spaces and projects should be searchable. Stale pages and closed tickets can dilute answers, so plan a cleanup or exclusion list before the first sync.
- Connectors: Configure the Confluence and Jira connectors with explicit space and project scopes.
- Identity: Map Atlassian groups or your identity provider groups to Onyx roles, so restricted spaces stay restricted.
- Permissions: Test restricted spaces and confidential Jira projects with non-admin accounts.
- Index hygiene: Exclude archived spaces, personal drafts and old project boards to keep retrieval focused.
- Model hosting: Engineering teams often prefer self-hosted models for code and incident data, which Onyx can serve through Ollama or vLLM.
Confirm how permission inheritance works in your Atlassian edition and whether your sync frequency is acceptable for fast-moving tickets.
Organizations with isolated networks need every part of the stack inside their boundary, including the model weights. Onyx documents an air-gappable deployment in which the document index, database and processing run in a self-contained set of services, and it can use self-hosted models through Ollama, LiteLLM or vLLM. Connectors to cloud sources only work if those sources are reachable from your network, so an offline design usually means indexing content already copied inside the boundary.
- Deployment: Use Docker, Kubernetes, Helm or Terraform to deploy inside the isolated environment.
- Model hosting: Run open-weight models on local GPUs through Ollama or vLLM, and move model files in through an approved media process.
- Connectors: Limit sources to those that are reachable from the isolated network, or replicate content through an approved transfer path.
- Identity: Use an internal OIDC or SAML provider, since external sign-in will not resolve.
- Updates: Plan how container images, the Helm chart and model weights reach the environment for each release.
Confirm with Onyx which components need outbound access during installation and which can run fully disconnected.
What drives the cost and duration of the move
The effort of moving from ChatGPT Enterprise to Onyx depends less on the software than on how many sources, users, groups and permission rules the new assistant must respect. Each card below is a lever that moves the one-time build and the recurring run cost, and each lists what to confirm before you accept a quote.
Source count and permission complexity
Every connector you add is a piece of integration work, and each one carries its own permission model. Onyx syncs source permissions so answers only draw on documents a user can already see, which means a SharePoint site with broken inheritance or a Confluence space with restricted pages takes more time to validate than a flat shared drive. Ask the implementer to list each source, its sync scope and the permission cases they will test, such as deleted users and nested groups.
SSO and SCIM provisioning
Onyx supports SSO through Google OAuth, OIDC or SAML and lists SCIM user provisioning among its enterprise features. Identity work is one-time: configuring the identity provider, mapping attributes and testing deprovisioning. Confirm which of these your identity provider supports, whether SCIM is in the Community Edition or the enterprise license, and who owns the identity provider configuration after go-live.
Users and group structure
The number of users matters less than the number of groups and the rules that map them to sources. A few hundred users in clean groups is a different job from the same headcount spread across dozens of ad hoc teams. Before sizing the work, export group membership from your directory, count the groups that gate access to sensitive sources, and decide which of them the assistant must honor.
Model hosting and GPU needs
Onyx can call hosted providers such as OpenAI, Anthropic or Gemini, or self-hosted models served through Ollama, LiteLLM or vLLM. Hosted models shift cost into recurring API usage and data-handling terms to review, while self-hosted models add GPU hardware, capacity planning and model updates. Ask the vendor to state the model sizes and concurrency they assume, and whether inference runs in your region or account.
Deployment target and infrastructure
Onyx documents deployment with Docker, Kubernetes, Helm or Terraform, and its standard stack includes Postgres, Vespa or OpenSearch, Redis and model servers. A single-host Docker setup for a pilot costs less to build than a Kubernetes deployment with managed backups and high availability. Confirm the target, the index engine, backup scope for the index and database, and which services the implementer will monitor after handover.
Enterprise license for RBAC and auditing
The MIT Community Edition covers RAG, chat, agents and actions. Role-based access control, usage analytics and query history auditing are listed among enterprise features, and code under the ee directories is covered by the Onyx Enterprise License. Ask whether your audit and access review requirements depend on those features, and get the license terms and fees in writing before you commit the design to a feature that needs a paid agreement.
What usually goes wrong and how to prevent it
Can Onyx show documents to users who should not see them?
It can if permission sync is not verified, which is why this is the first check before any pilot. Onyx syncs source permissions so answers draw only on documents the user can already see in the source application, but that depends on each connector mapping permissions correctly and on sync running on schedule. Prevention: pick a sample of restricted documents in each source, sign in as users with and without access, and confirm the answers match what the source application shows. Repeat after any connector change, and ask your Onyx partner or Onyx itself to document how groups, nested groups and external sharing are handled for each source you connect.
Why do connectors return outdated or overly broad content?
Connectors index whatever their scope allows, so a broad site or drive selection pulls in drafts, archives and personal folders that were never meant for assistant search. Stale content also appears when sync frequency is too low or when deleted files are not removed from the index. Prevention: define an indexing scope per source before connecting it, exclude archive and personal locations, set a sync schedule that matches how often the source changes, and confirm that deletions propagate. Review the index on a set cadence with the content owners who can say what should stay visible.
Will users find their ChatGPT conversation history in Onyx?
Usually not in the same form, so plan for it before the cutover. Onyx indexes company sources and runs its own chat history, but it is not a drop-in importer for a ChatGPT Enterprise workspace. Prevention: decide which conversations matter for retention, use the export path that OpenAI documents for admins, and tell users early what carries over and what stays in the archive. Set a read-only archive period so people can look up old answers without the new assistant replacing that record.
Which Onyx features need the Enterprise license and which are in Community Edition?
Community Edition is MIT licensed and covers RAG, AI chat, agents and actions, while code in ee directories falls under the Onyx Enterprise License. Teams often assume SSO, SCIM, RBAC and audit features are all free, and that assumption breaks the rollout plan. Prevention: read the LICENSE file and the ee directories for each feature you need, map every requirement to a license tier, and confirm in writing with Onyx which features your deployment will use. Ask whether enterprise features are available as self-hosted Enterprise Edition, Onyx Cloud or both.
Do open-source models match the answer quality of ChatGPT Enterprise?
Not automatically, and quality varies by model, language, document type and retrieval setup. Onyx works with self-hosted models through Ollama, LiteLLM and vLLM as well as proprietary providers, so the answer depends on which model you pick. Prevention: build a test set from real questions your users ask, score answers against known-good sources, and compare several models with the same retrieval settings. Keep the model swappable so you can change it when results disappoint, and confirm any data handling terms with each provider you call.
How do you size the index and inference infrastructure correctly?
Sizing depends on the volume of indexed content, the number of concurrent users, how often sources sync, and whether models run on your GPUs or call an API. Onyx Standard includes Postgres, Vespa or OpenSearch for the index, Redis, model servers and object storage, while Onyx Lite drops the vector database and background workers for a lighter chat-first setup. Prevention: inventory the sources and document counts before choosing a profile, run a load test with representative queries, and ask for a sizing review that covers index growth, sync windows and GPU or API costs. Those inputs drive the recurring bill far more than the license.
Who keeps Onyx patched and upgraded after go-live?
Your team does, unless you buy a retainer, because self-hosting moves patching, upgrades and monitoring into your scope. Onyx publishes releases and a Helm chart, so each upgrade needs a plan for connector compatibility, schema changes and model server updates. Prevention: name an owner for upgrades, keep a staging environment that mirrors production, subscribe to release notes, and schedule upgrades rather than deferring them for months. DeployOpen offers ongoing support and upgrades as retainers under a written scope if you prefer to outsource that work.
How DeployOpen scopes, runs and supports the Onyx migration
DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For this migration, we agree the connector list, permission model, identity setup and model choices in writing before any build work starts, so the scope of the ChatGPT Enterprise replacement is clear to every stakeholder.
How we scope
- Inventory the sources users paste or upload from today and rank them by how often they feed chat answers
- Confirm which Onyx connectors cover each source and which sources need a different approach
- Agree in writing how document permissions sync from each application into Onyx before indexing begins
- Record which SSO, SCIM and role mappings are in scope, and which Onyx features need the Enterprise Edition
How we build
- Deploy Onyx with Docker, Kubernetes, Helm or Terraform in your own infrastructure, sized to the agreed scope
- Connect the agreed sources and test that answers only draw on documents each sample user can already see
- Configure SSO, SCIM provisioning and role-based access, then test sign-in and deprovisioning with real account types
- Wire model providers through Ollama, LiteLLM, vLLM or approved hosted APIs according to the data handling you signed off
How we hand over
- Deliver runbooks for deployment, connector maintenance, index rebuilds, backups and model rotation
- Document the permission sync design, retention settings and query history logging so auditors can trace access
- Walk your administrators through daily operation, user onboarding and troubleshooting in your environment
- Provide a list of open items, licensing decisions and any features that remain outside the agreed scope
How we support
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts
- Ongoing support, upgrades and continuous testing are available as a retainer after handover
- Upgrades to new Onyx releases can be planned, tested in a staging copy and applied on your schedule
- Ask any vendor or DeployOpen quote to separate one-time build effort from recurring retainer and infrastructure costs
