Migrate from ChatGPT Enterprise to LibreChat: what the move involves
Moving from ChatGPT Enterprise to LibreChat is a platform rebuild plus a history transfer, not a file copy. ChatGPT Enterprise runs only as an OpenAI-hosted service, so there is no workspace to lift and shift. You stand up LibreChat in your own infrastructure, rebuild the identity, model, retention and sharing settings there, and then bring across the conversation history you are entitled to export. The reason to do this is usually a renewal, a residency requirement or lock-in to one model vendor, and the real goal is taking control of where conversations live, who sets retention and how users sign in. Platform engineering usually owns the deployment, security owns retention, logging and secrets, and identity owns OAuth2 or LDAP sign-in, with a business owner accepting the cutover date and the user group that moves first. LibreChat is MIT licensed and is deployed with Docker, using the reference docker-compose file that runs the app with MongoDB, Meilisearch and a separate RAG API service, or with the Helm chart for Kubernetes. The effort is moderate and concentrated in three places: the production stack (database backups, search index, TLS, secrets), the authentication integration, and the model routing. Effort rises with the number of identity groups you must map, the number of custom GPTs your users depend on, and whether you need a gateway such as LiteLLM in front of several providers. Confirm your own sizing and support requirements with the LibreChat maintainers or your implementation partner before you commit to a schedule, because those depend on your user count and usage pattern, which this page cannot know. The main risk is assuming that export gives you a complete archive. Confirm with your OpenAI account team exactly what the Enterprise Compliance API returns for your workspace, and test an import of a sample export into a staging LibreChat before you retire anything. Plan for the parts that do not move cleanly, such as custom GPT instructions and file attachments, and record which conversations you must retain for legal hold so that the new retention policy is set before the old workspace is closed.
Which ChatGPT Enterprise capabilities map cleanly to LibreChat
This table maps the main ChatGPT Enterprise capabilities to their nearest LibreChat equivalent and marks each as clean, needs rework or gap. Read the status column first, then the notes on retention and sign-in, which depend on how you configure and operate the stack.
| ChatGPT Enterprise capability | LibreChat equivalent | Status |
|---|---|---|
| Chat with a model in a browser interface | Chat interface with conversation history, run in your own Docker or Kubernetes deployment | Clean |
| Access to multiple models | One interface across OpenAI, Azure OpenAI, Anthropic, Google, Vertex AI, AWS Bedrock, Ollama and custom OpenAI-compatible endpoints | Clean |
| SAML SSO sign-in | OAuth2, LDAP or email sign-in. SAML is not the documented path, so identity provider setup and group mapping need rework | Needs rework |
| Admin console for users and settings | Admin panel for user and configuration management, with your own role decisions to confirm | Clean |
| Search and export of conversations | Message search and conversation import and export. Confirm how ChatGPT exports land and whether bulk admin export meets your needs | Needs rework |
| Custom GPTs with instructions and files | Agents with MCP tool support, which need to be rebuilt and their sharing settings reviewed | Needs rework |
| Code interpreter | Sandboxed code interpreter is listed in the README. Confirm sandbox isolation and resource limits in your environment | Needs rework |
| Image generation | Image generation and editing is listed in the README, depending on the provider you connect | Needs rework |
| Retention and audit logs | Retention and audit depend on your database, backup and log configuration, which you own and must define | Not applicable |
What data and identity work the migration needs
A ChatGPT Enterprise to LibreChat move is mostly data and identity work: getting history out of OpenAI, mapping people into a sign-in method you run, rebuilding custom GPTs, and deciding how model calls are routed. Each card below is a decision or check that has to close before cutover.
Export history through the Compliance API
The documented export path is the Enterprise Compliance API, which gives workspace admins an audit log of conversations and GPTs. Ask OpenAI and your workspace admin which fields, date ranges and attachments that export actually returns for your plan, because the API output is not guaranteed to match the format LibreChat imports. LibreChat can import ChatGPT conversation exports, so run a test import of a small sample before planning the full move.
Confirm what leaves OpenAI
Files, uploaded images, shared links and GPT configuration may not all come back in an export. Record what is covered and what is left behind, and confirm with OpenAI how deleted conversations are handled on their side, since OpenAI states deleted conversations are removed within 30 days unless legally required. Legal hold and retention obligations should be settled before any deletion in the source workspace.
Map identities to OAuth2 or LDAP
ChatGPT Enterprise users sign in through SAML SSO, while LibreChat supports OAuth2, LDAP and email login. Decide which directory is the source of truth, then map groups and roles to LibreChat's admin panel before any user logs in. Test that offboarded users lose access, since local accounts created during a pilot can outlive the directory record.
Rebuild custom GPTs as agents with MCP tools
Custom GPTs bundle instructions, files and actions, and each has to be recreated as a LibreChat agent with its own tools. MCP servers replace GPT actions, so each external tool needs an MCP endpoint your team hosts and secures. Inventory which GPTs are shared with whom, because sharing rules in LibreChat are configured separately and must be checked again.
Route model calls through LiteLLM
LiteLLM can sit between LibreChat and model providers, giving one OpenAI-format endpoint with per-key budgets and model restrictions. Its production guide names PostgreSQL as the primary database and requires Redis 7.0 or newer once more than one proxy instance runs, so both become stateful services you back up and patch. Confirm the LITELLM_MASTER_KEY storage in your secret manager and who owns the Redis and database upgrade path.
Settle SSO for the LiteLLM admin UI
The LiteLLM admin UI supports SSO through Google, Microsoft Entra ID, Okta and generic OIDC, but SSO is free only up to 5 users from v1.76.0 and needs an Enterprise license beyond that. Confirm the user count and whether SCIM provisioning is required before choosing the admin sign-in design. This cost belongs in the quote alongside the LibreChat and infrastructure work.
How to sequence the migration from inventory to decommission
This sequence moves a ChatGPT Enterprise workspace to LibreChat in controlled stages, so each change is tested with a small group, runs alongside the old workspace, and is cut over only after sign-in, model routing and retention have been checked.
Inventory users, GPTs, models and retention duties
Start by listing every workspace user and group, every custom GPT with its instructions, files and actions, the models people rely on, and the retention or legal hold obligations that apply to conversations. Assign an owner for each line, usually a workspace admin with input from legal and records management. Confirm with your compliance lead which retention periods must survive the move. The output is an inventory register that maps each user group to its sign-in method, each GPT to a LibreChat agent or MCP tool, and each model to a provider you will route through LiteLLM. The step is done when every GPT has a disposition (rebuild, retire or keep in use) and the register has been signed off.
Run a pilot with a small group
Stand up LibreChat in a non-production environment using the reference Docker setup, which runs the app with MongoDB, Meilisearch and the RAG API service. Connect one or two model providers and sign in a small pilot group through the authentication method you plan to use, either OAuth2, LDAP or email. Ask pilot users to rebuild two or three of their most important GPTs as LibreChat agents and to test MCP tools they need. Record what breaks, including missing features, sign-in edge cases and prompt differences between models. The output is pilot acceptance notes listing accepted behaviors, defects with owners and open questions for the security team. Do not move production data until those notes are reviewed.
Import history and validate the archive
Retrieve conversation and GPT records for the in-scope users through the Enterprise Compliance API, then import the ChatGPT export into LibreChat in the pilot environment. Check that imported conversations are searchable, attributed to the right users and complete for a sample of threads. Keep the original export as a separate, access-controlled archive so the source record is preserved even if an import is partial. The output is a validated export archive with a checksum or manifest, a list of anything that did not import and sign-off from the records owner. Confirm with OpenAI which export scope your admin role receives before you start.
Operate both systems in parallel
Keep ChatGPT Enterprise available for all users while a wider group uses LibreChat for real work. Route LibreChat models through LiteLLM with virtual keys that carry per-team budgets and model restrictions, and watch spend, error rates and latency. Track support requests by category, and confirm that new conversations in LibreChat are retained under the policy in your inventory. The output is a parallel run log with usage figures, incident records and a go or no-go recommendation for cutover. The parallel period should last as long as the pilot notes require, and not for a fixed duration.
Cut over sign-in and model routing
Write a cutover runbook that sets the order of changes: final history import, DNS or link changes, switching the identity provider application for LibreChat, and moving users from ChatGPT Enterprise to the new endpoint. Enable SSO for the LiteLLM admin UI if your team needs it, noting that the free SSO tier is limited to 5 users from v1.76.0 and an Enterprise license is needed beyond that. Define the rollback steps before you start. The output is an approved cutover runbook with a named owner, a rollback procedure and a post-cutover checklist that includes access verification for each group.
Decommission the ChatGPT Enterprise workspace after export
Once LibreChat has carried production use through the agreed period and the export archive is verified, remove users from the ChatGPT Enterprise workspace and disable GPT sharing. Apply the retention settings your inventory requires before deletion, and confirm with OpenAI how deleted conversations are handled under its enterprise privacy terms. Revoke API keys and SSO connections that are no longer needed, and record the decision in your change log. The output is a decommission record with the final export archive location, the date access ended, the revocation checklist and sign-off from the compliance owner.
What drives the cost and duration of the move
This table lists the cost components of moving from ChatGPT Enterprise to a self-hosted LibreChat stack and the drivers that move each one. Read it as a checklist for a written quote: confirm who is paid for each line, which lines recur, and which drivers you can reduce before work starts.
| Cost component | Who is paid or who carries it | One-time or recurring | What drives it up or down |
|---|---|---|---|
| Platform build and configuration | Implementation partner or internal platform team | One-time | Scope of the LibreChat deployment, Docker or Kubernetes choice, and how many environments you need (production, staging, test) |
| Identity integration | Identity team and implementation partner | One-time, with periodic review | Number of identity providers, whether you use OAuth2, LDAP or email login, and how group mapping replaces the SSO setup you have in ChatGPT Enterprise |
| Agent rebuild | Internal product owners and implementation partner | One-time per agent, then ongoing change | Number of custom GPTs in use, their files and actions, and whether you rebuild them as LibreChat agents with MCP tools or retire them |
| LiteLLM and database operations | Platform team and database administrator | Recurring | Whether you run one proxy instance or several (which adds Redis 7.0 or newer), PostgreSQL sizing, and the number of virtual keys and team budgets you configure |
| Model API or GPU usage | Your cloud account, model vendor, or hardware owner | Recurring, usage-based or capital | Model choice, token volume per user, and whether inference runs on hosted APIs or local GPUs; request a usage forecast with the quote |
| Hosting and storage | Your cloud account or data center | Recurring | Residency requirements that fix the region, retention period for conversation history, and backup frequency |
| Audit and retention depth | Compliance team and platform team | One-time design, recurring evidence | How much conversation logging, export and access review you need, since audit depth determines log storage and review effort |
| Upgrades and support | Platform team or retained support provider | Recurring | LibreChat release cadence, LiteLLM minor version support window, and how often you test upgrades in staging before production |
What usually goes wrong and how to prevent it
Most failed ChatGPT Enterprise to LibreChat moves do not fail in the software. They fail in the data handoff, the identity mapping, the assumptions about custom GPTs, and the operating model left behind after cutover. Each card below names one failure and the check that prevents it.
Incomplete conversation exports
Admins retrieve conversations and GPT records through the Enterprise Compliance API, and the export is only as complete as the query and date range used to pull it. Gaps often appear in shared or archived threads and in files attached to messages, which do not always come across in the import. Before cutover, compare conversation counts per user against a sample reviewed by hand, and keep the raw export files as the record of truth.
Users not mapped to one identity
LibreChat signs users in through OAuth2, LDAP or email, while ChatGPT Enterprise used SAML SSO. If the same person gets a second account under a different username or email format, their imported history lands in an account they cannot see. Decide the unique identifier first, typically the directory email or UPN, and test sign-in for a pilot group before importing anything.
Custom GPT behavior not reproduced
A custom GPT bundles instructions, knowledge files and tools, and a LibreChat agent does not inherit them automatically. Teams often assume the agent answers like the GPT and find differences in tone, file grounding and tool calls only after users complain. Export each GPT's instructions and files, rebuild the agent with MCP tools, and run the same test prompts against both systems with written acceptance criteria.
LiteLLM run on one instance without Redis
LiteLLM is the gateway that routes requests and enforces virtual key budgets, and it needs PostgreSQL for virtual keys. Once more than one proxy instance runs, shared rate limits, router state and cache depend on Redis 7.0 or newer, so a single instance without Redis will give inconsistent limits under load. Put the proxy behind a load balancer only after Redis is in place, and load test the budget and rate limit behavior before go-live.
Unclear retention ownership after cutover
ChatGPT Enterprise retention was set by workspace admins and deleted conversations were removed within 30 days, under OpenAI's terms. After cutover, the organization owns the database, backups and logs, so retention rules, backup expiry and deletion requests become its own duty. Name one owner for retention, write the periods for chats, backups and logs, and confirm that deletion reaches the database, search index and backups.
Unpinned LibreChat versions
The latest tagged LibreChat release, v0.8.8, was published on October 1, 2026 and is marked as a pre-release, so it is not a stable line to deploy by default. Pulling the latest image or tracking the main branch can change behavior between restarts. Pin an explicit image tag that you have tested, read the release notes before each upgrade, and keep MongoDB, Meilisearch and the RAG API on versions tested together.
How the migration changes by team size and starting point
A small team on one Docker host has the simplest path. LibreChat's reference docker-compose file runs the app with MongoDB, Meilisearch for search and a separate RAG API service, so the first milestone is a working stack on one machine with local accounts or email login. Conversation history can be imported from a ChatGPT export, and the main decisions are backup and model keys rather than identity integration.
- Stack footprint: Confirm the three containers from the reference compose file start cleanly and that MongoDB data sits on a volume you back up.
- Sign-in: Email login is often enough at this size, so defer OAuth2 or LDAP until the team grows.
- Model keys: Store provider keys in the environment or a secret store, and decide whether all users share one key or each user brings their own.
- Backups: Schedule backups of the database and volumes, then test a restore on a second host before cutover.
- Upgrades: Pin an image tag and read release notes before each update, since the latest tagged release may be a pre-release.
Before cutover, confirm that the export you imported contains the conversations your users expect and that the restore procedure works.
An enterprise migration starts with identity, not the chat interface. LibreChat supports multi-user authentication with OAuth2, LDAP and email login, and its admin panel manages users and configuration. Directory groups, offboarding and access reviews have to be designed before the platform reaches a wider audience, because ChatGPT Enterprise access today follows the identity setup your organization already runs.
- Identity design: Map your existing SAML or OIDC identity provider to LibreChat's OAuth2 or LDAP options, and confirm which group attributes reach the application.
- Role mapping: Decide which directory groups become administrators, which can create agents and which only chat.
- Model routing: Place LiteLLM in front of providers when you need per-team budgets, virtual keys or SSO for the gateway itself, since LiteLLM's free SSO covers up to 5 users.
- Data plane: Plan PostgreSQL and Redis for the gateway once more than one proxy instance runs.
- Pilot group: Migrate one department first and review admin logs and access before wider rollout.
Confirm with your identity team how group membership will be synchronized and who approves changes to admin roles.
A regulated team needing EU residency or air-gapped operation changes where every component runs. ChatGPT Enterprise runs only as an OpenAI-hosted service, with regional data residency offered to eligible customers and inference residency available in some regions. A self-hosted LibreChat design moves the conversation store, retrieval and model endpoints under your control, but the model endpoint choice then decides whether data leaves the network.
- Hosting location: Deploy in infrastructure you control and document which region holds the MongoDB store and search index.
- Model endpoints: Use Ollama or another local runtime for air-gapped use, or an approved in-region cloud endpoint, and record which providers are enabled.
- Offline distribution: Plan how container images and model files reach an isolated network, and how updates are verified before import.
- Logging and retention: Define retention for conversations, which you now own, and how deletion is evidenced.
- Compliance readiness: Prepare controls and evidence for your assessor. DeployOpen does not issue audit reports, and independent auditors decide conformity.
Ask your compliance lead which evidence the assessor expects before choosing a model endpoint.
A team with many custom GPTs needs a translation step before migration. Custom GPTs bundle instructions, files and tools, and LibreChat replaces them with agents that support MCP tools. Each GPT must be reviewed for the behavior it depends on, because tool connections and file knowledge do not move automatically from OpenAI to a self-hosted agent.
- Inventory: List every GPT, its owner, its instructions, its attached files and its tool actions, using the Compliance API audit data where available.
- Prioritization: Migrate GPTs with active users first and retire unused ones deliberately.
- Tool replacement: Identify which actions map to MCP servers you host, and which need custom integration work.
- Sharing: Define who can publish agents to others and how shared agents are reviewed.
- Parity testing: Compare answers for a set of representative prompts before users switch.
Before cutover, confirm with each GPT owner which behavior is required and who signs off on the rebuilt agent.
Questions buyers ask before moving from ChatGPT Enterprise to LibreChat
How much effort and cost does moving from ChatGPT Enterprise to LibreChat involve?
The move has one-time work and recurring costs, and the mix depends on your environment. The one-time items are planning, deploying the LibreChat stack, configuring sign-in, rebuilding custom GPTs as agents, testing and cutover. The recurring items are the infrastructure to run MongoDB, Meilisearch and the RAG API, the model usage you pay providers for, and upgrades and patching that you or a support partner carry. ChatGPT Enterprise is billed per seat, so your savings depend on your seat count, usage volume and how many providers you route to. Ask any implementation partner for a fixed-scope quote that lists each component separately, including who pays for model usage, hosting and ongoing support. DeployOpen does not publish prices and quotes follow from a written scope.
How long does a migration from ChatGPT Enterprise to LibreChat take?
The pace is set by scope and by your internal approvals, not by LibreChat itself. The main drivers are how many custom GPTs need rebuilding as agents, how many identity sources and groups must map to LibreChat sign-in, how much of the conversation history you need to carry over, and whether you require EU or other residency for the new stack. Security review, change windows and user communication often take longer than the technical setup. No duration is set in this guide, so ask for a timeline in the written scope, and confirm with your team how long your own change and risk processes take.
What does the migration need from our internal team?
You need named owners in four areas. Identity owners configure OAuth2 or LDAP sign-in and confirm group membership and admin roles. Platform owners provide the hosting target, container runtime or Kubernetes cluster, storage, backups and network rules. Security and compliance owners decide retention periods, approve the data flows and review access. Business owners list which custom GPTs and workflows matter, and they test the rebuilt agents against real tasks. Plan for your team to take part in acceptance testing and to hold the operational runbook after handover, since the stack needs ongoing patching and monitoring.
Can our own engineers do the LibreChat migration without an outside partner?
Your engineers can do it if they have Docker or Kubernetes experience, can operate MongoDB and can own identity integration. LibreChat is MIT licensed and documents Docker deployment and a Helm chart, so the software itself is accessible. The harder parts are usually the operating model: backups, upgrades, security hardening, evidence for audits and handling of model provider keys. Ask whether your team has capacity for these tasks after go-live. If not, a fixed-scope engagement can cover the build and the handover, and retainers can cover upgrades and continuous testing. DeployOpen implements, hardens, backs up, upgrades and documents self-hosted platforms in your own infrastructure, but it does not issue audit reports or certifications.
Does LibreChat import the full ChatGPT Enterprise conversation history?
LibreChat supports conversation import and export, so you can bring conversation records into it, but you should test the import on a copy before relying on it. The source data comes from the Enterprise Compliance API, which is the documented export path for admins, and it covers conversations and GPT records. Check what your export contains, how attachments and metadata are handled, and whether timestamps and user mapping survive the import. Confirm these points in a test import with your own export files, and keep the original export as the record of truth for your retention obligations.
How do LiteLLM licensing and enterprise SSO limits affect the choice?
LiteLLM is dual licensed, with code under its enterprise directory under a separate license and the rest under MIT. Its admin UI supports SSO with Google, Microsoft Entra ID, Okta and generic OIDC, and from v1.76.0 SSO is free for up to 5 users, with an Enterprise license needed beyond that. SCIM, JWT authentication, audit logs, organization and team RBAC, IP allowlisting and secret manager integrations are listed under LiteLLM Enterprise. If your user count is above that limit or you need these controls, budget for an Enterprise license or choose a different gateway path. Confirm the current terms in the LiteLLM Enterprise documentation before you decide.
What does running LiteLLM alongside LibreChat require to operate?
LiteLLM's production guide names PostgreSQL as the primary supported database, and virtual keys need PostgreSQL to support per-key, per-user and per-team budgets. Redis 7.0 or newer becomes required once more than one proxy instance runs, for shared rate limits, router state and cache. The guide suggests 1 vCPU and 4 GiB memory per worker, and it recommends one Uvicorn worker per pod on Kubernetes with horizontal scaling. Keep the master key, which must start with sk-, in a secret manager. These are extra components to size, back up and monitor, so include them in your quote and operating plan.
Which LibreChat release should we plan to deploy?
The latest tagged release on the LibreChat GitHub releases page is v0.8.8, published on October 1, 2026 and marked as a pre-release after release candidates in September 2026. Because pre-releases can change, most teams should test on a staging copy and confirm whether a stable release exists before production go-live. Check the LibreChat GitHub releases page on the day you plan the build, and write your chosen version into the scope so upgrades are tracked.
How DeployOpen scopes, runs and supports the migration
DeployOpen is a Chainscore Labs company that plans, implements, integrates, hardens, backs up, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For a move from ChatGPT Enterprise to LibreChat, that means the work covers the LibreChat deployment itself, its MongoDB and Meilisearch services, the RAG API, the connection to identity providers for OAuth2 or LDAP sign-in, and the routing layer if you choose to put LiteLLM in front of your model providers. Before any work starts, the scope is agreed in writing, including the deliverables, the environments involved and the timeline. Most engagements are fixed-scope, so the decisions about which conversations to import, which agents and MCP tools to rebuild, and which user groups to migrate first are settled in that document rather than discovered mid-project.
DeployOpen does not publish a price list. A quote follows from the written scope, so the inputs that drive it are the number of users and groups, how many custom GPTs and knowledge files need to be rebuilt as LibreChat agents, the number of identity sources, the hosting model you choose, and whether you need backup, hardening or documentation delivered alongside the build. Ask for the quote to separate one-time work (design, deployment, data import, testing and cutover) from recurring items such as upgrades, monitoring and support. Ask also who holds the infrastructure accounts, who owns the backups and encryption keys, and which evidence you will receive for your own compliance reviews. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications, so independent auditors and certification bodies remain responsible for those outcomes.
After cutover, ongoing support, upgrades and continuous testing are available as retainers, which suits a team that expects to track LibreChat releases and review its configuration on a schedule. Confirm the release channel you will run before the retainer starts, since the latest tagged LibreChat release on GitHub at the time of writing was a pre-release, and agree how upgrades are tested against your imported data. Ask for the runbook, the backup and restore procedure and the list of settings that differ from defaults to be delivered as part of the project, so your own staff can operate the stack if the engagement ends.
