Open WebUI migration services

What an Open WebUI migration involves

A migration onto Open WebUI usually starts from one of two places: a hosted chat assistant that a team has used without owning the data path, or an earlier single-container install that ran on one host with its default SQLite database and local file storage. The first case is mostly a question of where conversations, prompts and uploaded documents will live after cutover. The second is an infrastructure change. Confirm which of these applies to you before any planning, because the work list differs sharply.

At the platform level, the largest change is the state layer. The scaling guide requires PostgreSQL instead of SQLite for multi-instance deployments, because SQLite does not handle concurrent writes from several processes well. Multiple replicas also need Redis for sessions, websocket connections and application state, shared file storage so uploads and knowledge stay reachable from every replica, and an external vector database, since the default ChromaDB is warned to crash in multi-process setups. Each of these is a component your team must provision, back up and operate.

A migration is therefore more than copying a container. Chat history, users, groups, permissions, model connections, API keys and knowledge bases sit in different places, and some must be exported, transformed or re-ingested rather than moved byte for byte. Without Redis, signing out does not revoke tokens, which remain valid until they expire, by default after 4 weeks. Access rules, provider keys and retrieval settings also need to be re-verified after cutover.

In-house or partner delivery: a team with container, database and identity experience can run this internally, especially for a single-replica move. A partner is worth comparing when you need several replicas, identity control through SSO and SCIM, or a timed exit from a hosted service with user data to preserve. Common triggers include moving to a multi-replica setup, bringing users under identity control, and leaving a hosted service. Ask any partner for a written scope that names each data set and how it will be verified.

What the migration work includes

Each package lists what the client receives at the end. Work not named here, such as model provider contracts, GPU capacity and end-user training, is out of scope unless agreed in writing.

Source inventory

Record how the current deployment or hosted assistant is set up: Open WebUI version, database file location, environment settings, model connections, identity settings, uploaded files, knowledge collections and user counts. Confirm which decisions the client must make, such as which conversations to keep. Deliverables: an inventory workbook and a decision log signed off by the client before any export starts.

Target architecture

Design the multi-replica target with PostgreSQL as the database, Redis for sessions, websocket connections and application state, and shared file storage so uploads and knowledge stay reachable from every replica. Without Redis, sign-out does not revoke tokens, which stay valid until they expire, by default after 4 weeks. Deliverables: an architecture diagram, a configuration baseline and a sizing note.

SQLite to PostgreSQL move

Move users, chats, settings and metadata from the SQLite file into PostgreSQL. The scaling guide notes that SQLite does not handle concurrent writes from multiple processes well, so this step is required for multi-instance deployments. Rehearse the import on a staging copy, then compare row counts and test sign-in afterward. Deliverables: the migration script, a validation report and a retained copy of the original SQLite file.

Knowledge base reimport

Re-ingest knowledge collections into the external vector database chosen in the design, since the default ChromaDB will crash in multi-process setups. Compare document and chunk counts and sample retrieval results against the source before users see them. List any documents that fail extraction instead of dropping them silently. Deliverables: a reimport runbook, a per-collection reconciliation report and a list of documents needing manual handling.

User and group provisioning

Create users and groups through the identity path the client chose, such as OIDC, LDAP or SCIM 2.0, and map groups to roles and per-resource permissions. Transfer conversations only where the source export allows it. Where it does not, agree in writing whether the old instance stays online as a read-only archive. Deliverables: the provisioning configuration, a group-to-role mapping and a conversation transfer report.

Cutover, rollback and handover

Plan the switch of DNS, sign-in and model connections to a dated cutover window with a rollback point and a tested path back to the source. Keep the source read-only during the window. Deliverables at handover: runbooks for operation, backup and restore, the upgrade procedure, and an open-issues log. Model provider contracts, custom tool development and end-user training are excluded unless agreed in writing.

What drives migration cost and duration

Each row names one factor that changes how much work an Open WebUI migration takes, why it matters, and how to keep it under control.

Driver	Why it changes effort	How to keep it down
Number of users and groups	Every user and group must be recreated, mapped to roles and tested, and per-resource permissions multiply the checks. Group structure drives most of the access review work.	Confirm the target group model before migration. Retire inactive accounts first, and move only groups that map to current roles.
Volume and format of conversation history	Large or long chat histories take longer to export, transform and validate, and some formats need custom conversion before import. Attachments and embedded files add more to move.	Decide with stakeholders what history must move. Archive older chats in the source system and migrate only the active retention window.
Size and type of knowledge bases and documents	Documents must be re-extracted, chunked and re-embedded in the target vector store, so reimport time scales with corpus size and file type. Scanned or unusual formats need extra handling.	Inventory knowledge bases by size and format. Remove duplicates and obsolete files, and pilot a representative subset before the full reimport.
Number of model provider connections	Each provider connection needs its own endpoint, credentials, model list and access rules, and each must be tested against the target. Mismatched model names often break saved presets.	List every provider and model in use. Consolidate connections where possible and confirm which presets and tools reference each one.
Identity source and provisioning method	Moving from local accounts to OIDC, LDAP or SCIM 2.0 changes how users sign in and how accounts are created or deactivated. Identity mapping errors are the most common cause of access problems at cutover.	Confirm the identity source and whether provisioning will be automatic. Test sign-in and group mapping with a pilot group before cutover.
Number of environments	Each environment (development, test, staging, production) needs its own install, configuration, data copy and test cycle. Drift between them adds rework.	Keep environment configuration in version-controlled files. Limit the number of environments to those your change process requires.
Compliance evidence needs	Assessors may ask for records of data moved, access decisions, change approvals and test results. Producing this evidence takes planning and reviewer time. DeployOpen prepares evidence but does not issue audit reports.	Agree the evidence list with your compliance lead and auditor before work starts. Capture logs, reconciliation reports and sign-offs during each step, not afterward.
Target install method: Docker Compose, Kubernetes with Helm or pip	Docker Compose suits single-host targets with simpler operations. Helm on Kubernetes adds cluster, secrets, storage and ingress work. A pip install is generally for evaluation and small setups. The choice sets how much platform work surrounds the migration.	Confirm the target install method early, based on the scaling and availability needs of your users. Reuse existing platform tooling where your team already runs it.

Migration phases and outputs

The sequence moves users from a hosted assistant or single-container install onto a tested, multi-service Open WebUI environment without losing knowledge bases, accounts or the ability to roll back.

Audit the source installation
Inventory the current deployment, including the SQLite database file, uploaded files, knowledge bases, model connections, users and groups, and any hosted assistant data to export. The output is a source audit that lists what moves, what is rebuilt and what is retired, and the decision is whether the data volume is complete enough to design against.
Design the target environment
Choose the target topology for PostgreSQL, Redis, shared file storage and an external vector database, along with identity, network exposure and backup scope. The output is a signed-off design document, and the gate is agreement that a single SQLite file on network storage is not carried forward for multi-replica use.
Build the staging stack
Deploy the staging environment with PostgreSQL, Redis, shared storage and the external vector database in place of the default ChromaDB, then confirm sessions, uploads and retrieval work from every replica. The output is a working staging instance, and the gate is a passing functional check on sign-in, token revocation and knowledge search.
Rehearse the data migration
Run the SQLite to PostgreSQL move and the knowledge base reimport against copies of production data, then compare user counts, chats, files and vector collections with the source. The output is a reconciliation report listing any gaps, and the gate is a rehearsal that reconciles cleanly with the gaps accepted in writing.
Provision users and groups
Set up identity integration, group mappings and role-based permissions so accounts are created with the right access before any user signs in. The output is a provisioning test log showing each test group receives its intended roles, and the gate is sign-off from the identity owner.
Pilot with a small group
Move a small, defined user group onto the new environment for real work and collect issues on sign-in, retrieval quality, model access and performance. The output is a pilot defect list with fixes applied, and the gate is the sponsor's decision to widen access based on that list.
Cut over and rehearse rollback
Freeze the source, run the final data move, switch users to the production instance and rehearse returning to the previous system before the cutover is treated as complete. The output is a cutover record and a tested rollback runbook, and the gate is confirmation that the rollback steps worked in rehearsal.
Hand over operations
Transfer runbooks, backup and restore procedures, upgrade steps and access records to the team that will operate the platform, and confirm they can perform a restore. The output is an accepted handover pack, and the gate is the operating team's signed acceptance.

What teams keep in-house and what they outsource

This table shows which migration tasks internal staff usually own and which a partner often runs, with the skills each side needs, so you can decide where to staff up.

Migration part	Usually kept in-house	Often run by a partner	Skills required
User communication	Yes: announcements, cutover dates, training invitations and help desk scripts	No, unless a partner is asked to draft materials	Internal communications, service desk management, knowledge of your user population
Knowledge content owners	Yes: business owners decide which documents, collections and knowledge bases move and which are retired	No, though a partner can run the reimport once owners confirm the list	Domain knowledge of each content set, data classification awareness, ownership of source systems
Access rules sign-off	Yes: approvers confirm group-to-role mapping, per-resource permissions and who may use which models	Partner drafts the mapping and configures groups, roles and permissions for approval	Identity administration, role design, familiarity with your access review process
Model and provider choices	Yes: your organization decides which Ollama, OpenAI, Anthropic or OpenAI-compatible providers are approved and who holds the keys	Partner connects the approved providers and documents the configuration	Vendor contract knowledge, security review of provider data handling, API key management
Schema and data moves	Review and acceptance of migrated data, including row counts and spot checks by business owners	Partner plans and runs the SQLite to PostgreSQL move, including schema setup and data transfer	PostgreSQL administration, SQLite export tooling, data validation scripting
Vector store and knowledge reimport	Confirm which documents must be re-indexed and which can be retired	Partner selects the external vector database, reimports knowledge and checks retrieval results	Vector database operations, document extraction tuning, storage capacity planning
Container and cluster build	Approve the target platform, network exposure and hosting location	Partner builds the Docker Compose, Helm or Kubernetes deployment, Redis and shared file storage	Container orchestration, Helm, Redis operations, shared storage administration
Provisioning integration	Owners of the identity provider approve the SSO, SCIM 2.0 and MFA configuration before it goes live	Partner configures OIDC or LDAP, SCIM 2.0 provisioning and group sync in a test tenant first	Identity provider administration, OIDC and LDAP, SCIM 2.0, MFA policy design
Rehearsal and cutover	Business owners run acceptance tests and make the go or no-go decision	Partner rehearses the full migration, times the data move and runs the production cutover and rollback plan	Migration runbook writing, test automation, change management, incident response

What usually goes wrong and how to prevent it

Each of these failures tends to appear after cutover if the migration does not address it. The checks below belong in your pre-cutover test plan.

Several replicas on SQLite

Running more than one replica against a SQLite file is a common first mistake. The scaling guide requires PostgreSQL for multi-instance deployments because SQLite does not handle concurrent writes from several processes well. Before cutover, confirm that every replica uses the PostgreSQL connection and that no instance still writes to a local SQLite file.

Default ChromaDB in multi-process setups

The scaling guide warns that the default ChromaDB will crash in multi-process setups, so an external vector database is required once several workers or replicas run. Choose a supported option such as PGVector, Qdrant or Milvus during planning, then rebuild embeddings in that store. Test retrieval from each replica before cutover.

Uploads and knowledge on local disk

Each replica must reach the same uploads and knowledge files. If files stay on one node's local disk, a user who uploads through one replica may see errors on another, and knowledge retrieval fails intermittently. Move file storage to shared storage before cutover, then upload a test file through one replica and query it through another.

Tokens valid after sign-out without Redis

Without Redis, signing out does not revoke tokens. They stay valid until they expire, by default after 4 weeks. Deploy Redis as the shared state store and confirm that sign-out invalidates an existing token used in a second browser or API client. Include this check in the cutover test plan.

Users provisioned twice through login and SCIM

When users are created at first login and also pushed by SCIM 2.0, the same person can end up with duplicate accounts or with role assignments that one path overwrites. Decide which system is the source of truth for each attribute, match accounts on the identifier your identity provider sends, and test one user through both paths before go-live.

Knowledge reimported without permissions

Reimporting knowledge bases during migration can drop per-resource permissions and group access, leaving content visible to the wrong users or hidden from the right ones. Record the access model for each knowledge base before export, reimport into matching groups, and check access as a test user in each group before cutover.

How the work changes by starting point

Moving from a hosted chat assistant is mostly a data and people problem. The main work is deciding what history, files and settings can leave the vendor, and then bringing users across without losing their trust in the tool.

Export limits: Confirm with the vendor what conversation history, uploaded files, custom instructions and shared assistants can be exported, in what format, and whether there are caps on volume or time range.
Re-onboarding users: Plan how accounts, groups and permissions will be recreated in Open WebUI, and whether provisioning will come from your identity provider rather than manual invitations.
Model connections: Map which models users relied on in the hosted service to the providers you approve, and confirm that the replacement models behave acceptably for your prompts.
Knowledge content: Identify documents that were uploaded to the hosted service, decide which ones must be reimported, and confirm who owns and may move them.
Client provides: Written approval on what data may be moved, a list of user groups, the approved model providers and a named owner for user communication.

What you need to provide before work starts

Most delays in an Open WebUI migration come from inputs the client has not yet decided, not from the technical move itself. Before work starts, the client needs to provide administrative access to the current system, including rights to export users, chats and knowledge bases. Without an export path agreed up front, the team cannot confirm what will move and what will be rebuilt by hand.

The client also supplies a current inventory of users, groups and knowledge bases, with a named owner for each knowledge collection. The IT lead signs off the inventory and the business owner signs off which knowledge content stays in scope. Groups in the inventory should match the roles you plan to map in Open WebUI, so permissions are not invented during cutover. Confirm whether the current system uses per-resource sharing, because that affects how access is recreated.

On the infrastructure side, the client confirms the target environment, the storage plan and the identity provider details. Identify the OIDC, LDAP or SCIM 2.0 source, who administers it and whether group membership is maintained there. Security owns the decisions on which model providers are approved, where provider keys are stored, and how long chat history and uploads are retained. Legal or the data protection owner should sign off retention before any data is imported.

Finally, name a test user group that can exercise migrated chats and knowledge retrieval, and agree a cutover window with the business. Confirm with the vendor and your own change board which Open WebUI release and migration path you will target, and document the rollback owner who approves reverting to the old system if the test group finds blocking issues.

Frequently asked questions

What drives the cost and effort when moving users onto Open WebUI?

Scope is the main driver: the number of source systems, how much history and knowledge base content must move, and how many users and groups need provisioning. Effort also rises with the SQLite to PostgreSQL move, the identity integration, and whether the target runs several replicas, which adds Redis, shared file storage and an external vector database. Cost has one-time parts (discovery, migration build, testing and cutover) and recurring parts (hosting, licensing and support after go-live). Ask each quote to itemize these components, state who is paid for each, and list the assumptions behind them.

How long does a move onto Open WebUI take, and why is no duration quoted?

Duration depends on the scope written into the engagement, so no fixed timeline is given before that scope exists. The main variables are the number of users and groups, the volume of conversation history and knowledge base files to reimport, the quality of identity data, and whether the target runs one replica or several. Each change to these inputs moves the schedule. Time also depends on how quickly your owners answer questions, approve test results and schedule a cutover window. Ask for a written plan that lists the dependencies and assumptions behind each phase.

Can our own team run the Open WebUI move without outside help?

Yes, a capable internal team can run the move, particularly a single-instance move with a modest user base. The harder parts are the PostgreSQL migration, vector database setup, Redis and shared storage for multiple replicas, and user provisioning through SCIM 2.0 or OIDC, which need platform and identity skills. Check whether your team has run a database migration with a tested rollback path, has operated Redis and shared file storage, and can test against production-like data. Where gaps exist, a fixed-scope engagement can cover the specific parts you name, with deliverables agreed in writing first.

Can conversation history and knowledge base files move to Open WebUI?

Often, but the answer depends on what the source system exposes and what the target accepts, so confirm it for each source before promising it. Chat history from an earlier Open WebUI install sits in the database you are moving, which makes the SQLite to PostgreSQL step central. Hosted assistants vary in their export options, so confirm with the vendor which formats and date ranges they provide. Knowledge base content is usually reimported from source documents, which means reprocessing files and rebuilding retrieval data in the chosen vector database. Confirm retention and privacy requirements for any history that moves.

Does the 50-user branding clause apply to a migration?

It can, because the license clause applies to any deployment that exceeds 50 users in a rolling 30-day period, and a migration may move the whole user base onto that deployment at once. The license forbids altering or removing Open WebUI branding above that threshold unless the operator holds an enterprise license or written contributor permission. Settle the branding decision before cutover, since a logo or name change in the new environment may be restricted. Enterprise licenses allow white-labeling, and pricing is quoted after contacting enterprise sales with an expected seat count. Have your legal team confirm your position.

What must our team provide before the migration work starts?

Your team provides access, decisions and sign-off, and the implementation partner provides the plan, build and verification within the agreed scope. Typical inputs include details and export access for the current system, identity provider configuration with an owner for group mapping, the target cloud account or data center, the list of approved model providers, and named approvers for testing and cutover. Confirm each input in the written scope, along with the change window and who authorizes a rollback.

How do cutover and rollback work for an Open WebUI move?

Cutover moves users to the new instance during an agreed window, and rollback returns them to the previous system if acceptance checks fail. The plan should freeze or sync source data, take a verified backup of the source and target databases, and test a restore before the window opens. Sessions need attention too: without Redis, sign-out does not revoke tokens, which stay valid until they expire, by default after 4 weeks. Decide in advance how long the old system stays available and who can trigger a rollback. Confirm these steps with the environment owner.

How DeployOpen delivers Open WebUI migrations

DeployOpen plans and builds Open WebUI migrations inside infrastructure you control, moving users from a hosted chat assistant or an earlier single-container install onto a deployment you operate. Each engagement starts from a written, fixed scope that covers the data moves, identity and provisioning work agreed with your team.

How we scope

Inventory the current source: user count, groups, model connections, chat history and any existing knowledge bases.
Confirm the target design, including whether the database moves from SQLite to PostgreSQL and which vector database is used.
Agree in writing which data is migrated, which is archived, and which is recreated by users after go-live.
Confirm identity sources, user provisioning method and the cutover window with your team before work begins.

How we build

Stand up the target Open WebUI deployment with the chosen install method in your cloud account, data center or air-gapped network.
Move the SQLite data to PostgreSQL in a rehearsed sequence, then verify row counts and user records against the source.
Reimport knowledge bases into the chosen vector store and test retrieval results against a set of agreed reference questions.
Configure model provider connections, groups and permissions, then test sign-in and access for each role before cutover.

How we hand over

Deliver runbooks for the cutover, the rollback path and the steps to repeat the database and knowledge base moves.
Document the final configuration, environment variables, secrets locations and the list of open items agreed in scope.
Run a handover session with the operators who will own the platform, covering routine tasks and known failure points.
Provide a sign-off record listing completed deliverables, test results and any items moved to a follow-on change.

How we support

Post-cutover support covers the agreed defect window and questions raised by your operators after go-live.
Ongoing support, upgrades and continuous testing are available as a retainer, scoped separately from the migration.
Ask any support proposal to state which Open WebUI release versions, database changes and provider tests it includes.
Confirm response expectations, escalation contacts and the handling of security fixes in writing before signing.

Open WebUI migration