Migrate from Gemini Enterprise to Onyx

How to migrate from Gemini Enterprise to Onyx without losing permissions

The move from Gemini Enterprise to Onyx is mostly a rebuild of three things: the connectors that feed the index, the permission sync that decides who sees what, and the model layer that generates answers. Conversations and agents do not carry over as working objects, so plan to recreate the agents you depend on and to re-verify every source. Platform engineering usually leads the work, with security and IT owning the permission model and the cutover, and an implementation partner often handling connector setup and hardening. Start by inventorying every connected source in Gemini Enterprise, the groups that grant access to each one, and the users who rely on specific agents, because those three lists define most of the effort. The permission check matters more than the connector count. Onyx connects to 50+ applications and syncs their permissions, so an answer should only draw on documents the user can already see in the source system. Before go-live, test that claim with a set of named accounts: pick documents restricted to a single group in Google Drive, SharePoint, Slack and Confluence, ask questions that should surface them for one user and not another, and confirm that removing a user from a group removes access after the next sync. Confirm the sync frequency and how deletions and group changes propagate for each connector with the Onyx documentation and your own tests, not from memory of the Gemini setup. Licensing shapes the rollout. Onyx Community Edition is MIT licensed and covers RAG, AI chat, agents and actions, while code in ee directories falls under the Onyx Enterprise License. Ask whether the features your SSO, SCIM provisioning, role-based access control and query auditing requirements depend on sit in the community code or the enterprise code, because that answer determines whether you need a commercial agreement before production. Keep the model choice separate: Onyx can call Anthropic, OpenAI or Gemini APIs or self-hosted models through Ollama, LiteLLM or vLLM, and each choice changes where prompts and retrieved content travel.

Which Gemini Enterprise capabilities map to Onyx, and which need rework

This table maps the main Gemini Enterprise capabilities to their Onyx equivalents and marks each as clean, needs rework or gap. Use it to scope the migration work, then confirm the items marked for checking against your own Gemini Enterprise configuration and your source applications. Most rows depend on connector coverage and permission sync, which you should test before committing to a cutover date.

Capability	Onyx equivalent	Status and what to confirm
Connector-based search over company content	Connectors for SharePoint, OneDrive, Outlook, Teams, Google Drive, Gmail, Confluence, Jira, Slack and Salesforce among 50+ applications	Needs rework: list every Gemini Enterprise data source in use and confirm each has an Onyx connector and the scope (sites, drives, channels) you need
Permission-aware answers	Onyx syncs source permissions so answers draw only on documents the user can already see	Needs rework: test with sample users in each group, because permission behavior differs by source and must be verified before rollout
Chat with citations over indexed content	Onyx AI chat with RAG over the document index	Clean: core chat and retrieval are covered; confirm answer quality on your own document types during a pilot
Agents and actions	Onyx agents and actions in the Community Edition	Needs rework: Gemini Enterprise agents must be rebuilt as Onyx agents with their own prompts, tools and sources; confirm which actions each team relies on
SSO sign-in	Google OAuth, OIDC or SAML login	Clean for most identity providers: confirm your identity provider and whether SAML or OIDC is the supported path in your edition
User provisioning and deprovisioning	SCIM user provisioning, listed as an Enterprise feature	Gap in Community Edition: confirm whether SCIM is required and budget for the Enterprise license if it is
Role-based access control and admin controls	RBAC listed as an Enterprise feature	Gap in Community Edition: confirm which admin roles you need and whether RBAC must be in place before go-live
Admin audit and usage visibility	Usage analytics and query history auditing, listed as Enterprise features	Needs rework: confirm the export formats and retention you need for assessors, since Gemini Enterprise export paths must be checked in your own tenant
Model choice	Self-hosted models through Ollama, LiteLLM or vLLM, plus providers such as OpenAI, Anthropic and Gemini	Clean in principle: model choice is wider in Onyx, but each model needs hosting capacity or an API agreement that you confirm with the provider

What data, identities and integrations move, and what you rebuild

Moving from Gemini Enterprise to Onyx is less a file transfer than a set of separate decisions. Indexed content is rebuilt from source systems, identities come through your identity provider, and chat history and agent definitions move only where a documented export path exists. Each group needs its own check before users rely on answers.

Indexed content is reindexed, not copied

Onyx builds its own index by connecting to each source system, so the work starts with the sources, not with Gemini Enterprise. Plan a reindex for every connector, including scope filters, excluded sites and folders, and the first full sync time on your data volumes. Treat the Gemini Enterprise index as a reference for what users searched, not as an export. Confirm with your Google Workspace and Microsoft 365 administrators which content is in scope before connecting anything.

Permission sync validated per source

Onyx syncs source permissions so answers only draw on documents a user can already see in the source application. Test this for each connector before rollout. Pick sample users in each group, ask questions whose answers sit in restricted files, and compare results with the source application. Repeat after group changes, because permission sync is only as current as its last run.

Connectors for your content sources

The Onyx repository includes connectors for SharePoint, OneDrive, Outlook, Microsoft Teams, Google Drive, Gmail, Confluence, Jira, Slack and Salesforce, among others. Map every Gemini Enterprise data connector to an Onyx connector and note any gap. Confirm each connector's authentication method, required service account or app registration, and supported content types, since connector coverage is not the same as feature parity.

Identities and groups through SSO and SCIM

Users sign in to Onyx through Google OAuth, OIDC or SAML, and SCIM provisioning keeps accounts and group membership aligned with your identity provider. Onyx lists role-based access control among its enterprise features, so confirm which features your chosen edition includes before designing roles. Rebuild group-to-role mappings from your current Gemini Enterprise access model, and test deprovisioning, since a removed user should lose access to both chat and indexed content.

Chat history and agent definitions

Gemini Enterprise chat history and agent configurations do not carry over automatically, and this guide does not assume an export path exists. Ask Google which documented methods let you retrieve conversation data, retention settings and agent definitions, and what format they arrive in. Where no export path is documented, plan to recreate the few agents that matter, with their instructions, sources and actions, in Onyx, and decide with legal whether old chats must be retained elsewhere.

Rebuilt agents, actions and model settings

Agents in Onyx are defined in its own configuration, so each agent needs its instructions, knowledge sources and any actions rewritten and tested. Model access is separate: Onyx works with self-hosted models through Ollama, LiteLLM or vLLM and with providers such as Anthropic, OpenAI and Gemini. Record which model each agent uses, since answers and data flows change with that choice.

The migration sequence from inventory to decommission

This sequence moves company search and chat from Gemini Enterprise to Onyx in controlled stages, so each step produces evidence that the next one depends on. Permissions, models and users are checked before any group loses access to the old service. The end state is a documented decommission with records you can hand to auditors.

Inventory sources, users and agents
Your platform or IT team lists every data source connected to Gemini Enterprise, the groups that use it, and each custom agent with its instructions, actions and owner. Record which sources need an Onyx connector, which need a different path, and which are no longer needed. Confirm each source and connector against the Onyx connectors directory before scope is agreed. The step is done when the inventory is signed off by the business owners and the security team, and each agent has a named owner and a keep, rebuild or retire decision.
Run a bounded pilot with one business group
Choose one business group with a manageable set of connectors, such as a shared drive and one chat workspace, and deploy Onyx for that group only. Use a test identity provider or a limited set of accounts to confirm that SSO, the sync of source permissions and the answers match what each user can see in the source application. Ask the pilot users to test documents they should not be able to reach, and log every failure. The step closes when the pilot group has a written list of defects, each with an owner and a retest result.
Select and deploy the models and Onyx edition
Decide between Onyx Standard, which includes the vector and keyword index, background sync workers, inference servers, object storage and Redis, and Onyx Lite, which has no vector database or background workers and fits a narrower chat and agent scope. Then choose the model path: self-hosted models served through Ollama, LiteLLM or vLLM, or an API provider such as OpenAI, Anthropic or Gemini, or a mix. If you run vLLM, place its nodes on an isolated network and expose only the user-facing endpoints behind a reverse proxy. The step is done when model latency and answer quality are measured against a fixed set of test questions and the data path for each model is documented.
Run a parallel period with permission checks
Keep Gemini Enterprise and Onyx running side by side for the pilot group and widen access gradually. Each week, sample a set of questions and compare the sources and answers from both systems, and confirm that Onyx returns no document the user cannot open in the source application. Record permission sync failures and any gaps in connector coverage. Ask an independent reviewer or your internal audit function to examine the permission test results. The step is complete when permission sync shows no unexplained exceptions and the business owners accept the answer quality for their group.
Cut over groups in phases
Move one group at a time from Gemini Enterprise to Onyx, starting with the groups that have the lowest risk and the fewest custom agents. For each group, update the access links and internal guidance, confirm that users can sign in through SSO and SCIM provisioning, and keep a rollback path for the duration of the phase. Track support tickets and query history for the cutover group. A phase is closed only when the group has used Onyx for its normal work, its open issues are resolved, and the owner has signed the cutover record.
Decommission and retain evidence
After the final group has cut over, disable Gemini Enterprise connectors and user access, and confirm with Google Cloud administration that the service and associated data stores are removed according to your retention policy. Export the inventory, permission test results, model documentation, cutover records and access logs, and store them in your evidence repository with retention set by your compliance team. DeployOpen can help prepare these records for an assessment, but independent auditors issue any assurance report. The step closes when the decommission checklist is signed and the evidence package is filed.

How to run Gemini Enterprise and Onyx in parallel while users switch

Run the two systems side by side with a pilot group routed to Onyx while everyone else stays on Gemini Enterprise. Pick pilot users from teams whose sources you have already connected in Onyx, such as one Google Drive shared drive or one SharePoint site, so the comparison is fair. Keep the pilot list in a file under change control, and make sure pilot users know which assistant holds their data and which one to report problems to. Give each side the same sources only where you intend to, because both platforms index content separately. Onyx pulls its own copy through its connectors, and Gemini Enterprise maintains its own index through its connectors, so the two can disagree for a while.

Build a fixed set of test questions drawn from real work, and ask both systems the same questions with the same test accounts. Record the answer, the cited documents and whether each side returned anything the test user should not see. Permission outcomes matter more than answer quality: Onyx syncs source permissions, so check that a user who lacks access to a restricted folder in Drive or SharePoint gets no citation from it. Expect sync lag and duplicate content to produce confusing results, such as an answer citing a file that was moved or deleted in the source. Log these cases with timestamps so you can tell lag from a real permission defect. Confirm with your Onyx deployment team how sync frequency is set for each connector before you judge freshness.

Set the cutover criterion before the pilot starts, and write it down with named owners. A practical criterion covers three areas: zero confirmed permission leaks across the test set, agreed coverage of the sources the business needs, and sign-off from the security and compliance owners on audit logging and query history. Also decide what happens to agents and saved workflows that exist only in Gemini Enterprise, since they must be rebuilt before users can leave. Keep Gemini Enterprise read-only for the agreed retirement window, then remove access in stages. Ask your implementation partner to put the criterion, the test set and the rollback steps in the written scope so that the decision is recorded, not made in a meeting.

Choosing self-hosted or API models for the new assistant

Running open-weight models on vLLM keeps prompts, retrieved passages and generated answers inside infrastructure you control. vLLM is licensed under Apache-2.0, has no paid edition, and exposes OpenAI-compatible endpoints such as /v1/chat/completions, so Onyx can point at it as a model server. Your main costs are accelerator capacity, the surrounding infrastructure and the staff who operate it. vLLM runs on NVIDIA CUDA, AMD ROCm and Intel XPU GPUs, and also on several CPU architectures, so hardware choice drives both speed and cost.

Security boundary: The --api-key option does not cover every endpoint, so place a reverse proxy in front that allowlists only the routes users need.
Multi-node risk: Communication between nodes is insecure by default, so isolate cluster traffic on a private network.
Observability: vLLM exposes Prometheus metrics at /metrics, which you should keep off public routes.
Release cadence: Minor releases arrive about every two weeks, so plan a test and upgrade cycle.
Scaling: Tensor parallelism works within a node and pipeline parallelism across nodes.

Confirm with your platform team which GPU models and memory sizes your target models need, and ask your security team to review the proxy and network design before any production use.

What usually goes wrong in this migration and how to prevent it

Most failed migrations from Gemini Enterprise to Onyx fail on access, coverage or expectations rather than on software. The cards below cover the risks we see most often, each with a prevention step you can check before users switch.

Permission sync gaps expose documents

Onyx only returns documents a user can already see in the source application, but that depends on permission sync running correctly for every connector and group. A misconfigured connector, a stale group membership or a shared drive with inherited rules can surface content to the wrong people. Before any pilot, test with accounts at several access levels and confirm that restricted documents never appear in answers, then repeat the test after each sync cycle.

Connectors miss a source the team needs

Gemini Enterprise users often rely on a source that is easy to forget, such as a legacy wiki, a Jira project or a Teams channel with shared files. The Onyx connectors directory covers many common sources, but each one must be configured, scoped and tested against your tenant. Build an inventory from the users' most-searched sources and map each one to a connector before cutover, and record any gap as a named risk with an owner.

Agent rebuilds take longer than planned

Agents in Gemini Enterprise are tied to its connectors, prompts and data scopes, so each one has to be recreated and re-tested in Onyx rather than copied. Teams often count the prompt text and forget the tool wiring, source scoping, owner approvals and test cases. Inventory every agent, mark which ones depend on actions or external tools, and budget review time for the agents that touch regulated data.

GPU capacity or model quality falls short

Self-hosted answers depend on the model you serve. vLLM runs on NVIDIA CUDA, AMD ROCm and Intel XPU GPUs, among other hardware, but capacity planning for your concurrency and context length is your job, and a smaller open model may answer differently from the Gemini model users know. Run a fixed set of real questions through candidate models on your hardware, measure latency under peak load, and decide whether a proprietary API model is a better fit for specific agents.

vLLM endpoints exposed without an allowlist

The vLLM security docs state that the --api-key option does not protect every endpoint, including /metrics, /health and /invocations, and they recommend a reverse proxy that allowlists only the endpoints meant for users. Node-to-node traffic in multi-node deployments is also insecure by default and must sit on an isolated network. Place vLLM behind a proxy that passes only the required /v1 paths, keep the server off public networks, and test the allowlist from outside the cluster.

Users distrust answers during parallel running

When people run Gemini Enterprise and Onyx side by side, they compare answers, and any gap in citations or permissions makes them stop using the new tool. Trust usually falls because of stale indexes, missing sources or answers without visible references rather than because of model quality alone. Define a parallel period with agreed test questions, track answer disagreements and reasons, and require source links on every answer before you ask teams to move their daily work.

What drives cost and duration, and how to keep each down

This table lists the factors that change the effort and spend of moving company search from Gemini Enterprise to Onyx, with the reason each matters and how to reduce it. Read the one-time and recurring notes first, then use the quote column to decide what to request in writing from any implementation partner.

Driver	Why it changes cost or effort	How to keep it down
Number and type of sources	Each connector needs setup, credentials, field mapping and testing. Chat-based sources such as Slack and ticketing systems often carry more noise and sync volume than file stores. Confirm each source's connector status against the Onyx connectors directory before you commit.	Start with the sources that hold most of the content users actually search. Retire stale or duplicate repositories before indexing, and phase the rest in waves.
Permission complexity	Onyx syncs source permissions so answers only draw on documents a user can already see. Nested SharePoint groups, shared drives with inherited rules and external sharing make validation slower and more important to test.	Map existing Gemini Enterprise access rules first. Clean up broken group memberships and overshared folders at the source, then test with sample accounts from each department.
Number of agents and actions	Each agent needs its own instructions, source scope, tool access and test cases. Actions that write to other systems add review and approval work beyond the search rebuild.	Inventory the agents users rely on and rebuild only those in use. Keep actions read-only at first and add write access after a security review.
Model hosting choice (GPU capacity versus API spend)	Self-hosted models through vLLM or Ollama cost GPU or accelerator capacity, plus the staff to run it. API models shift the cost to recurring per-usage spend with the model provider. Recurring cost depends on query volume and document size, so ask for an estimate based on your own usage data.	Benchmark answer quality on your documents with both options before buying hardware. A gateway such as LiteLLM can route between hosted and self-hosted models, and per-team budgets can cap API spend.
Onyx edition and support needs	Onyx Community Edition is MIT licensed, while code under ee directories uses the Onyx Enterprise License. Features such as RBAC and certain enterprise options may require the Enterprise Edition, and Onyx Standard and Onyx Lite have different infrastructure footprints. Support, upgrades and patching are your responsibility unless you buy them separately.	Decide which features are required before selecting an edition. Confirm license terms in writing with Onyx. Price support and upgrade work as a separate line item, and ask for a fixed scope.
Staff time for operations	Someone must run Postgres, the search index, Redis, model servers and connectors, plus monitor, patch and upgrade them. Initial setup is one-time effort. Ongoing upkeep is recurring and grows with the number of sources and users.	Standardize on Docker or Helm deployment, document runbooks, and assign named owners for connectors and models. Ask any partner which tasks they would hand over to your team.
Security review and evidence	Security teams will review data flows, identity integration (SSO through Google OAuth, OIDC or SAML and SCIM provisioning), logs, model endpoints and secrets. Exposed model endpoints need an allowlisting reverse proxy and secret management. Review time is one-time per release but recurs with each major change.	Prepare an architecture diagram, data location summary and access matrix before the review starts. Ask any partner which evidence they will produce and which controls remain with your auditors.
Parallel running and user switch	Running Gemini Enterprise and Onyx side by side means two sets of licenses, connectors and access reviews until cutover. The overlap period is a recurring cost until the old service is retired.	Set a cutover date tied to source coverage and answer quality checks. Confirm contract end dates and notice periods for Gemini Enterprise before the overlap begins.

Questions buyers ask before moving from Gemini Enterprise to Onyx

How much effort and time does a move from Gemini Enterprise to Onyx take?

The effort depends mainly on how many sources you reconnect, how much permission structure you need to preserve, and how many agents you rebuild. No duration is set by the supplied research, so treat any number you hear as a starting point to test against your own inventory. Start by listing each connected source, its owners, its size and its sharing model, because a source with complex group-based access takes longer to validate than a single shared drive. Then count the Gemini Enterprise agents and decide which ones are worth rebuilding. Ask any implementation partner for a written scope that breaks the work into connectors, permission checks, model setup, agent rebuilds and user cutover, with each item tied to a deliverable.

Can our internal team run this migration without outside help?

A capable platform team can run a pilot alone if it already operates Docker or Kubernetes, manages identity providers and has someone who owns the search index. Onyx is deployable with Docker, Kubernetes, Helm or Terraform, so the deployment skills are familiar to many teams. The harder parts are usually permission validation across several sources, model hosting, and the change work with business users. If any of these are new to your team, consider a fixed-scope engagement for those parts only. Ask for a written scope that names which tasks your staff keep and which ones the partner takes on.

What skills and staff time does a self-hosted Onyx deployment require?

Plan for four skill areas: container or Kubernetes operations, identity administration, data and search engineering, and model operations. Onyx documents Postgres, Vespa or OpenSearch for the index, Redis and model servers, so someone must patch, back up and monitor those services. Identity work covers SSO through Google OAuth, OIDC or SAML and SCIM provisioning. If you use self-hosted models, you also need people who can run vLLM or a gateway such as LiteLLM. Staff time recurs after launch for upgrades, which Onyx publishes as new releases such as v4.9.2 on October 15, 2026. Confirm your staffing model against the current Onyx deployment documentation before you commit.

Can we export our Gemini Enterprise conversations and agents?

The supplied research does not document a Gemini Enterprise export path for conversations or agent definitions, so confirm this with Google Cloud before you plan around it. Ask specifically whether agent configurations can be exported in a readable form, whether chat history is available through an API or audit feature, and how retention settings affect what remains. Onyx can import your business content through connectors, but rebuilding agents in Onyx is a manual design task in most cases. Keep a written inventory of each agent's purpose, sources, instructions and users so the rebuild is traceable.

How does Onyx validate permissions for documents from each source?

Onyx connects to 50+ applications and syncs their permissions, so answers draw only on documents the user can already see in the source application. Verify this for each connector you enable, not just in general. Pick a set of test users with known access, then check that restricted files from SharePoint, Google Drive or Slack never appear in their answers, and that revoking access in the source removes the content after the next sync. Also test the edge cases your organization cares about, such as shared links, external guests and deleted users. Record the results as evidence for your security and compliance reviews.

What changes between Onyx Community Edition and the Enterprise Edition?

Onyx Community Edition is MIT licensed and covers RAG, AI chat, agents and actions, while code in ee directories falls under the Onyx Enterprise License. Onyx lists SSO, SCIM provisioning, role-based access control, usage analytics and query history auditing among its enterprise features, and the Enterprise Edition includes premium features such as RBAC. Check which of these you need on day one, because they decide whether you run the community code or the licensed edition. Read the license files directly and confirm with Onyx which features sit in each edition before you budget for licenses or support.

How should we run a pilot while users keep working in Gemini Enterprise?

Run both systems in parallel with a small group of users who have a clear business need. Choose two or three sources, a limited set of test users and a short list of questions with known answers. Measure answer accuracy, permission correctness and response behavior against the Gemini Enterprise results, and record every gap. Expand the source list only after permission tests pass. Plan the cutover by agreeing with users and owners on what moves, when access to the old tool closes and what happens to data in it. Keep the pilot scope and exit criteria in writing so the decision to expand rests on evidence.

What DeployOpen takes on in a Gemini Enterprise to Onyx migration

DeployOpen scopes a Gemini Enterprise to Onyx migration in writing before any work starts, as a fixed-scope engagement with agreed deliverables and timelines. The first phase is an inventory: every data source Gemini Enterprise searches today, the Google Drive shared drives, SharePoint and OneDrive sites, Slack workspaces, Confluence spaces and Jira projects in use, the agents and actions people rely on, and the identity setup behind them. Each item is mapped to an Onyx connector from the connectors directory, or flagged as a gap that needs a custom connector, an export or a decision to drop it. The written scope should also name who signs off on that inventory, since the sign-off defines what counts as migrated.

The highest-risk work is permission testing. Onyx syncs source permissions so answers only draw on documents a user can already see in the source application, but that behavior has to be verified in your tenant, not assumed. DeployOpen's test plan typically covers sample users across departments, documents with inherited, group-based and externally shared access, and deleted or re-permissioned files, comparing what each test account can retrieve in Onyx with what it can open in the source system. For identity, the scope should confirm whether SSO runs through Google OAuth, OIDC or SAML and whether SCIM provisioning is required, because the account model decides how permission sync maps to people.

Model deployment, the parallel run and cutover form the remaining phases. Model choice (self-hosted through Ollama, LiteLLM or vLLM, or a proprietary API) is a decision to record in the scope, along with the GPU capacity, gateway and key management it implies. A parallel run keeps Gemini Enterprise and Onyx live side by side for a defined pilot group, with query logs and feedback compared before users switch. Cutover and evidence work produces the access review records, configuration baselines, backup and restore tests and change logs that your compliance team and independent auditors will request. DeployOpen prepares that evidence but does not issue audit reports or certifications. Ongoing support, upgrades and continuous testing are available as separate retainers, and ownership of each after handover should be written into the agreement.

How DeployOpen scopes, runs and supports the migration

DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted Onyx inside your own cloud accounts, data centers or air-gapped networks. Each migration starts from a written scope that sets out which sources, models and users are covered before any build work begins.

How we scope

Inventory every Gemini Enterprise connector, data source and permission boundary your users rely on today.
Confirm which Google Drive, SharePoint, Slack and other sources move to Onyx and in what order.
Agree in writing whether models run self-hosted through vLLM or LiteLLM, or through external APIs.

How we build

Deploy Onyx with Docker, Kubernetes, Helm or Terraform in the environment you choose.
Configure connectors and confirm that Onyx permission sync limits answers to documents each user can already see.
Set up SSO and SCIM provisioning, then test permission behavior with representative user accounts.

How we hand over

Document the architecture, connector configuration, permission mapping and model routing decisions.
Provide runbooks for upgrades, backups and connector troubleshooting for your operations team.
Run a parallel period with both systems so users can switch at a pace your business approves.

How we support

Offer ongoing support, upgrades and continuous testing as a retainer after handover.
Plan Onyx version upgrades and Helm chart changes against your change control process.
Keep the written scope current if you add sources, agents or models after go-live.