Amazon Q Business alternative after the new-customer closure
If you already run an Amazon Q Business application, the decision in front of you is no longer about adding seats or new connectors. AWS now limits Q Business to fixes and points customers to Amazon Quick, so the real question is whether your next renewal or roadmap cycle should stay with a vendor path or move the index, identity and model choice into infrastructure you control. Amazon Quick is the vendor path. Self-hosted Onyx is the path that keeps the index, identity and model choice in your own infrastructure. The Amazon Quick route is a migration inside AWS's product line, and that is where the risk sits. The index bridge is reported to drop Q Apps, Actions and guardrails, and it can flatten the document permissions you built in Q Business. Before you plan around either point, ask AWS to confirm in writing, for your own tenant and your own data sources, which Q Apps, Actions, guardrails and per-document access rules carry over and which do not. Keep a copy of the answer with your renewal file.
The self-hosted route moves the work to your side. Onyx connects to the sources your users already search and syncs their permissions, so answers only draw on documents each user can already see in the source application. Identity runs through Google OAuth, OIDC or SAML with SCIM provisioning, and you choose the model, whether self-hosted through Ollama, LiteLLM or vLLM or a proprietary provider. Your team takes on the index, database, upgrades, backups and monitoring, so start by listing every Q Business data source, plugin and guardrail you rely on and mark which ones you must reproduce before any cutover date is set. A practical first step is to run a short parallel test with a representative group of users and a copy of your highest-value sources, then compare answers and permission behavior against Q Business. Confirm with your AWS account team how long your current subscription term runs and what notice applies, so the exit date is set by the contract rather than by a guess.
What a move away from Q Business must preserve
A move from Amazon Q Business, whether to Amazon Quick or to a self-hosted assistant, has to keep six things intact. Each card names one requirement, why it matters for your data, and a pilot check you can run before cutover.
Permission-aware retrieval
Answers must only draw on documents the user can already see in the source system. Onyx syncs source permissions from its connectors, so an answer should never cite a file that the asking user cannot open in SharePoint, Confluence or Google Drive. In a pilot, pick two users with different access, ask the same question to both, and check that each answer cites only documents that user can open at the source. Also test a document whose permissions change, and confirm the index reflects the change within your required window.
Connectors to your sources
The assistant is only as useful as the systems it can read. List every source your team uses today, including the S3 buckets, SharePoint sites, Confluence spaces and Salesforce objects behind your Q Business data sources, and check each against the connector list before you commit. Where a connector is missing or limited, decide whether to build one, accept a manual upload, or keep that source out of scope. Run a pilot sync on one large and one restricted source and time the first full index.
Sign-in and user provisioning
Staff should sign in through your existing identity provider, and joiners, movers and leavers should flow in automatically. Onyx supports SSO through Google OAuth, OIDC or SAML and SCIM user provisioning. Confirm which of these your identity provider supports, and test that a deprovisioned user loses access to both chat and indexed content. A pilot should include a user removed from a group in the identity provider and a check that their sessions stop working.
Model choice and self-hosted models
Your data may need to stay on your own servers, which means the model layer must also be replaceable. Onyx connects to self-hosted models through Ollama, LiteLLM and vLLM, as well as hosted providers. Confirm which models your legal and data handling rules allow, and whether a model can be switched without reindexing content. In a pilot, run the same question set against one hosted model and one self-hosted model, and record quality, latency and where each request is processed.
Query history and audit evidence
Compliance and security teams need to answer who asked what, which sources were used, and how long records are kept. Onyx lists query history auditing and usage analytics among its enterprise features, so confirm which of these are in the edition you deploy. Ask your assessor what evidence they will request, such as access logs and retention settings, and build an export of sample records during the pilot. Check that deleted conversations are removed according to your stated retention policy.
Operation inside a restricted network
Some workloads must run with no outbound internet access. Onyx documents an air-gappable, self-hosted deployment whose index, database and processing run in a self-contained set of services, deployable with Docker, Kubernetes, Helm or Terraform. Confirm with the vendor which features need external calls, such as hosted model APIs, connector sign-in or update checks, and what your environment must allow. Test the full stack in an isolated network segment before you retire the Q Business application.
Where Amazon Quick meets the requirements and where to verify it
The vendor path is Amazon Quick, which AWS names as the successor for customers who used Amazon Q Business. Whether that path meets your requirements depends on details that the public topic material does not settle for your tenant. The index bridge may not carry over Q Apps, Actions and guardrails, and permissions may be flattened during migration, so an application that looked equivalent in the console can answer questions differently once it lands. Treat the successor as a candidate to test, not a conclusion to accept on the strength of the name.
Get the following in writing from AWS or your account team before you commit. Ask which data sources and permission models carry over unchanged, and which need to be reconnected or re-mapped, with specific attention to document-level access in SharePoint, Confluence and S3. Ask how each guardrail and action is rebuilt, who does the rebuild, and whether any behavior is lost. Ask for the contract term, notice periods, data export format and exit terms, and confirm in which region and storage location your indexed content, logs and conversation history are kept. Compare the written answers with a test run in your own tenant using accounts that hold different access levels.
If the written answers leave gaps in permissions, guardrails or residency, the self-hosted route with Onyx is the comparison to run in parallel. Keep a short decision record that lists each requirement, the vendor's written answer, and the test result. That record is what your security, legal and procurement reviewers will need, and it is the input for any independent assessment your auditors perform.
Amazon Q Business alternatives compared on permissions and models
This table compares Onyx, LibreChat, Open WebUI, AnythingLLM and Amazon Quick, the paths teams weigh now that Amazon Q Business is closed to new customers. Read each row across three questions: whether the option keeps data and model choice under your control, how it handles permissions on company content, and what its license or vendor relationship asks of you. The main takeaway is that only connector-based options keep permission-synced search inside your own environment, so confirm each claim against your identity setup before you commit.
| Option | Continuity requirements | Permission-synced enterprise search | Licensing and trade-offs |
|---|---|---|---|
| Onyx | Runs in your cloud or air-gapped network; models via Ollama, LiteLLM or vLLM. | Connectors for 50+ apps sync source permissions; SSO via Google OAuth, OIDC or SAML. Confirm which edition includes SCIM and RBAC. | MIT Community Edition; ee directories fall under the Onyx Enterprise License. Confirm which features you need. |
| LibreChat | Self-hosted with Docker; connects OpenAI, Azure OpenAI, Anthropic, Bedrock, Vertex AI and Ollama. | Chat-first with no built-in connector index; confirm how content retrieval and access rules would be built. | MIT licensed. Multi-user login via OAuth2, LDAP and email; MCP support for agents. |
| Open WebUI | Self-hosted with Docker, pip or Kubernetes; runs offline with Ollama or OpenAI-compatible APIs. | Chat interface for users; confirm how document access is handled before using it for company search. | Open WebUI License limits branding changes above 50 users in a rolling 30-day period unless permission or an enterprise license applies. Have counsel confirm. |
| AnythingLLM | Docker deployment or desktop app for macOS, Windows and Linux; connects local or cloud LLMs. | Multi-user with document ingestion into built-in vector databases; confirm per-user source permissions. | MIT licensed. Trade-off: confirm how ingested documents stay current and access-controlled after upload. |
| Amazon Quick | AWS-managed service; AWS controls upgrades and the roadmap, and Q Business customers are directed here. | Index bridge can flatten permissions and drops Q Apps, Actions and guardrails; confirm the mapping before migrating. | Commercial AWS terms and pricing; request a written quote and confirm feature parity with your current setup. |
How to move from Q Business to Onyx in your own environment
This sequence moves Q Business users, sources and permissions into a self-hosted Onyx deployment you control, with each stage ending in a check the team can verify before the next one starts. The result is a tested cutover and an archived record of how the old application behaved.
Inventory applications, sources and permissions
The Q Business administrator and the cloud platform team export the current state using the AWS console or the AWS CLI, covering each application, its data sources and plugins, the users and groups with access, any Q Apps, and the guardrail and topic settings in use. Record which source systems hold the content people actually search, such as S3, SharePoint, Confluence or Salesforce, and who owns each one. The step is done when the team has a signed-off inventory that maps every source to an owner and every guardrail to a stated purpose. Confirm the exact export commands and their output formats against current AWS documentation before scripting them.
Deploy Onyx in your own account or cluster
The platform team deploys Onyx inside the organization's own AWS account, data center or Kubernetes cluster using Docker, Kubernetes, Helm or Terraform, following the deployment overview in Onyx's documentation. They choose between Onyx Standard, which includes the vector and keyword index, background sync workers and model servers, and Onyx Lite, which omits the vector database and background workers. The step is complete when the services start, the admin console loads from inside the network, and the database, index and object storage are confirmed to sit in the chosen environment. Ask Onyx to confirm which edition covers the features you need, such as RBAC and query history auditing.
Connect identity and verify group mapping
The identity team connects Onyx to the corporate identity provider using SSO through OIDC or SAML, or Google OAuth if that is the directory in use, and configures SCIM provisioning so group membership flows in automatically. Test with a small set of accounts whose access is known in the source systems, and compare what each account sees in Onyx against its effective permissions in the source. The step is done when every test account returns only the documents it can already open at the source, and the results are saved with the change record. Confirm that the directory groups used for source permissions are the same groups SCIM sends to Onyx.
Reconnect priority connectors one at a time
The data owners and platform engineers add connectors in priority order, starting with the sources that carry the most-used or most sensitive content, and let each finish its initial sync before adding the next. Onyx's connectors directory lists supported sources such as SharePoint, OneDrive, Confluence, Jira, Slack and Google Drive, and the team confirms each source's permission sync behavior in its own environment. For each source, a restricted test user with no access to a specific sensitive document must be unable to retrieve that document through chat or search. The step closes when every priority source passes this negative test and the results are logged.
Choose the model path and set network controls
The architecture and security teams decide whether answers come from a self-hosted model served through vLLM or Ollama, from an approved API such as OpenAI, Anthropic or Gemini, or from a mix, and document the data handling terms for any external provider. For a self-hosted vLLM endpoint, the team must place nodes on an isolated network, put a reverse proxy in front of the API that allowlists only the endpoints users need, and keep the internal /metrics and /health routes off the user path, since the --api-key option does not protect every route. The step is complete when outbound traffic rules are tested and the model endpoint is reachable only from the Onyx services.
Rebuild required guardrails and actions
The Onyx owner and the business sponsor review the inventory from the first step and decide which Q Apps, actions and guardrails still matter. Each required behavior is rebuilt either as an Onyx agent with its own instructions and actions, or as an upstream control, such as a source permission, a DLP rule, a prompt filter in the gateway or a data classification label applied before indexing. Behaviors that are no longer needed are retired and recorded as such. The step is done when every item on the inventory has a named replacement or a documented retirement decision approved by the owner.
Run a parallel pilot, then cut over with rollback
A defined group of real users works in Onyx alongside Q Business for an agreed period, with the sponsor and security lead reviewing query results, permission exceptions and user feedback. Before cutover, the team exports and archives the Q Business query history and application configuration for retention, and writes a rollback plan that names the trigger, the owner and the steps to restore the previous assistant access. The cutover is complete when users are switched, monitoring confirms normal use, the rollback has been rehearsed, and the archive has been verified as readable. Agree the pilot length and retention period with compliance before the pilot begins, because neither is set by the product.
How vLLM keeps model serving inside your boundary
Onyx can call models that you host yourself through Ollama, LiteLLM or vLLM, and vLLM is the option to evaluate when you need high-throughput serving on your own GPUs. vLLM is Apache-2.0 licensed and has no paid edition, so its cost is the GPU or other accelerator capacity, the surrounding infrastructure, the implementation work and the staff who operate it. Because the server exposes OpenAI-compatible endpoints such as /v1/chat/completions, /v1/embeddings and /v1/responses, you point Onyx at your server's base URL rather than rebuilding connectors. Confirm which endpoints your Onyx version calls before you lock the proxy rules described below.
Multi-GPU sizing is a design decision. vLLM splits a model across GPUs with tensor parallelism within a node and pipeline parallelism across nodes, and multi-node runs use Ray or its own multiprocessing backend. The vLLM security documentation states that communication between nodes is insecure by default, with no authorization or encryption, so every multi-node deployment must sit on an isolated network. The --api-key option protects only the /v1, /v2, /inference and /cohere paths. It does not cover /invocations, /pause, /resume, /abort_requests, /metrics or /health, so place a reverse proxy in front of the server that allowlists only the user-facing endpoints and keeps the management routes off the network Onyx and users can reach.
Operations need the same care. vLLM exposes Prometheus-format metrics at /metrics covering request counts, token throughput, latency histograms and KV cache use, so scrape them from inside your monitoring network only. vLLM ships minor releases about every two weeks, and the latest release supplied for this page is v0.31.0 on October 5, 2026, so set a dated upgrade and regression-test routine. The vLLM docs list Kubernetes options including native manifests, Helm and KubeRay. Before you commit hardware, confirm GPU sizing with the model vendor's published requirements and run your own load tests with realistic prompt lengths and concurrency.
Evidence to collect for a continuity review
When an AI assistant replaces a managed service, the questions shift from features to proof: who can see what, how access is provisioned, what was logged, and how the system is recovered. The cards below list the evidence a CISO, auditor or regulator is likely to request when Amazon Q Business closed to new customers: move to Amazon Quick or self-host is reviewed.
Permission sync test results
Keep dated test records showing that a user who lacks access to a restricted document in the source system never sees it in an answer. Use test accounts from each permission group in SharePoint, Confluence, Google Drive and any other connected source, and include negative cases such as a removed group membership. Ask the vendor or your own team to confirm how permissions are synced after the initial crawl, and how long a revoked permission takes to take effect in the index.
SSO and SCIM provisioning logs
Collect the identity provider configuration for SAML or OIDC sign-in, the SCIM provisioning settings, and logs showing users created, updated and deactivated. Auditors typically sample leavers to confirm that a deprovisioned account can no longer sign in or retrieve content. Confirm which role-based access control settings are included in your edition, since some enterprise features sit in separately licensed code.
Query history and audit log exports
Export query history and usage records for a defined review window, and document who can read them and where they are stored. Map each field to the question it answers, such as which user asked what and which sources were retrieved. Confirm retention periods with your own policy, because the log store is now part of your system of record rather than a vendor console.
Model endpoint network policy
Document the network policy that governs traffic between the assistant, the model servers and any external model providers, including firewall rules and the reverse proxy allowlist. For a self-hosted vLLM server, the docs advise a reverse proxy that exposes only the user-facing endpoints, because the API key option does not cover every route. Keep the rule set under change control and capture a test showing that blocked paths are refused.
License and branding review
Maintain a register listing each component, its license and the version you deploy, such as MIT for Onyx Community Edition and the Onyx Enterprise License for code in ee directories. Check whether a candidate such as Open WebUI, whose license restricts removing or altering branding beyond a user threshold, requires a commercial grant for your deployment size. Have counsel confirm the conclusions before the review.
Index and database restore test
Record a backup schedule for the Postgres database, the search index and object storage, plus a restore exercise with its measured result. A backup that has never been restored is weak evidence for a continuity review. Ask whether the index can be rebuilt from source systems if a restore fails, and document the time and staff needed for that rebuild in your own environment.
What moving off Q Business costs in effort and what it needs from your team
What does moving off Q Business to a self-hosted Onyx deployment actually cost?
The cost comes from several separate components, and only some of them are one-time. Onyx Community Edition is MIT licensed, so the software itself has no license fee, while the Enterprise Edition is a paid, separately priced option whose cost you must get in writing. Recurring costs include the servers or cloud accounts that run the index, database, Redis and model servers, the GPU capacity or API fees for the language model, and the staff who operate the stack. One-time costs include planning, connector setup, permission testing, hardening and documentation. Ask any provider to separate these lines in a quote so you can see which costs recur and which shrink as usage changes.
Which cost components grow the most with company size and document volume?
Three components usually drive the total upward as the deployment grows. The first is index storage and compute, since the number of connected sources and documents determines how much the vector and keyword index must hold. The second is model inference, which is either GPU capacity you run yourself or per-token API charges from a hosted provider, and it rises with query volume and context size. The third is operations time, which grows with the number of connectors, users and upgrades. Ask for a sizing assumption tied to your document count, user count and query pattern, and ask how the quote changes if any of those numbers double.
Can our own team do the migration without an outside partner?
Yes, some teams do it in-house, but the work needs skills across several areas at once. You need people comfortable deploying containers with Docker or Kubernetes and Helm, operating Postgres and Redis, and managing object storage. You also need identity engineers who can configure SSO through OIDC or SAML and SCIM provisioning, and someone who understands how source-system permissions map to the index. If you run a self-hosted model, you need GPU operations experience. Check whether these skills already exist in your team before you commit. A fixed-scope engagement from DeployOpen can cover planning, implementation, hardening and documentation, with ongoing support available as a retainer.
How long does a migration from Q Business take and what sets the timeline?
The timeline depends on the work involved, not on a fixed duration, so confirm it in a written scope rather than relying on a general estimate. The biggest variables are the number and type of data sources you need to reconnect, how much permission mapping and testing is required, whether you need a self-hosted model or will use an API, and how many Q Apps, actions or guardrails must be rebuilt. Internal approvals, security review, procurement and hardware lead times often add more time than the technical build. Ask the provider to list the milestones, the decisions you must make and the dependencies on your side.
What should a written quote for this migration include?
A useful quote lists the scope in concrete terms and states what is excluded. Ask for the following in writing:
- The list of data sources to connect, with the connector and the permission model for each
- The Onyx edition, identity method and model provider assumed, and the cost of any Enterprise Edition features
- The infrastructure you will provision, including who pays for it and whether it is sized from stated assumptions
- Testing and acceptance criteria for permission checks, retrieval quality and audit logging
- Documentation, handover, training and the support options that follow go-live
Also ask which costs you pay directly to cloud providers or model vendors so they are not hidden in the implementation fee.
Can we verify that permissions carry over correctly before cutover?
Yes, and you should test this before any user depends on the new system. Onyx syncs document permissions from connected applications, so answers should only draw on documents the user can already see in the source. Build a test matrix of representative users and groups, then confirm that a sample of restricted documents never appears in their answers, including documents shared through groups and inherited folders. Repeat the tests after each connector sync, because permission changes in the source system must flow through. Record the results as evidence for your access review. Confirm the exact sync behavior for each connector during scoping, since some sources handle nested groups differently.
Does the Open WebUI branding clause or the Onyx edition choice change the plan?
The Open WebUI clause only matters if you choose Open WebUI as your interface. Its license forbids removing or altering its branding unless the deployment has 50 or fewer users in a rolling 30-day period, the copyright holder grants permission, or an enterprise license is bought, so check that clause against your user count before you select it. Onyx is a different case. Onyx Community Edition is MIT licensed, but code in the ee directories falls under the Onyx Enterprise License, and features such as RBAC and certain enterprise controls sit in the Enterprise Edition. Map each required feature to the edition that provides it, and confirm licensing terms in writing with your legal team before the design is final.
Can we export our data and configuration from the current Q Business application?
Export depends on what the current Q Business application stores, so confirm each item with AWS and with your own records before you plan the cutover. Your source documents usually remain in their original systems such as S3, SharePoint or Confluence, which means the content itself is reconnected rather than exported. What needs inventory is the application configuration, the list of connected data sources and plugins, the user and group mappings, and any Q Apps, actions and guardrail settings you rely on. The AWS CLI can help list these resources, but verify which items can be retrieved in a usable form. Plan to recreate the guardrails and workflows manually, and document their original behavior so the new system can be tested against it.
What do ongoing operations look like after go-live?
After go-live, your team or a retainer partner runs the platform, which means upgrades, connector maintenance, index health, model capacity and access reviews. Onyx publishes regular releases, so you need a schedule for testing and applying them. The vLLM model server, if you use it, also ships minor releases about every two weeks, and its security documentation says that multi-node traffic is insecure by default and that the API key alone is insufficient, so you need a reverse proxy that allowlists user endpoints. Monitor request counts, latency and cache use through the Prometheus metrics. Agree on who owns each of these tasks, how incidents escalate and how often permissions are re-tested.
How DeployOpen plans and deploys a Q Business replacement
DeployOpen plans and deploys self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For a move off Amazon Q Business, we start from a written scope that maps your current data sources, permissions and workflows to a self-hosted Onyx deployment you control.
How we scope
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
- We inventory the connected sources, user groups and permission rules that your Q Business application relies on today.
- We confirm which Q Apps, Actions and guardrails need a replacement, and which can be retired without loss.
How we build
- We deploy Onyx in your environment with Docker, Kubernetes, Helm or Terraform, matching your existing infrastructure standards.
- We connect sources such as SharePoint, Confluence, Salesforce and S3, then test that answers respect source-side permissions.
- We connect the model layer you choose, whether a self-hosted model served through Ollama, LiteLLM or vLLM, or a proprietary provider.
How we hand over
- We document the architecture, configuration, connector settings, permission sync checks and the operating runbook.
- We set up backups and upgrade procedures, so your team knows how Onyx is patched and how its index is restored.
- We walk your operators through the deployment and record evidence that supports your internal or external compliance reviews.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover.
- Retainers can cover Onyx version upgrades, connector maintenance and periodic permission checks against your source systems.
- We do not issue audit reports or certifications. Independent auditors and certification bodies do that, and we prepare the evidence they review.
