Dify Community to Dify Enterprise migration

Dify Enterprise SSO documentation lists OpenID Connect, SAML and OAuth2, so the choice follows what your identity provider supports best and what your security team already operates. Confirm the supported providers and setup steps against the SSO documentation for the exact Enterprise version you will deploy, since configuration screens and options differ between releases. Pick one protocol per identity provider, record the callback and metadata values, and test sign-in with a pilot group before any production user is redirected.

The Enterprise SSO documentation names identity providers such as Microsoft Entra ID, Okta and GitHub, but support for your specific tenant setup, group claims and admin consent flows must be confirmed with the documentation and your identity team. Ask which providers are listed for your target version, whether group claims can drive role mapping, and how sign-out and session lifetime behave. Treat any provider not explicitly named in the documentation as an open question, not a given.

Dify separates SSO scopes for workspace access, meaning builders and administrators signing into the console, from web app access, meaning end users of published apps. Decide them separately because the populations, risk levels and identity sources usually differ. An employee who builds workflows may need workspace roles, while a customer-facing or partner-facing app may need a different sign-in path or no workspace access at all. Map each population to its scope before configuring either one.

Confirm SCIM provisioning against the Enterprise documentation for your target version before you plan around it, because the scope of automated user and group sync can change between releases. If it is supported and you adopt it, users and groups are created and removed from your identity provider rather than by hand. If it is not available or not yet proven in your environment, plan manual user creation and a documented offboarding step instead. Either way, decide who owns deprovisioning, since stale accounts are the main access risk after a move.

Community accounts are local to one workspace, so every existing user needs a matching identity in the Enterprise provider before cutover. Build a mapping table that links each current email or account to the identity provider subject, the target workspace and the role it should hold. Decide which roles stay, which are merged and who approves exceptions. Test the mapping with a copy of the user list and resolve duplicates, shared accounts and service accounts before the cutover window opens.

The window depends on the number of users, how many identity providers and scopes you configure, how many roles need review and whether SCIM is in use, so ask any partner for a written plan rather than a generic duration. Schedule a pilot, a freeze on role changes, a cutover date and a rollback point where the Community login is kept available until sign-in is confirmed. Keep the Community instance readable during the window so that owners can check apps and data.

Ask for a written scope that names the protocol, each identity provider, the workspace and web app scopes, the SCIM version and the role mapping method, all checked against the documentation for your target Enterprise release. Ask who configures the identity provider, who owns test accounts, how rollback works and what happens to sessions when the SECRET_KEY or cookie settings change. Ask how the team will verify that deprovisioned users lose access to both workspaces and published apps.

Yes, a capable platform team can attempt it, but the work spans three areas that rarely sit with one person: Kubernetes and Helm, the PostgreSQL, storage and vector data move, and identity administration for SSO and SCIM. Check the Enterprise prerequisites first. The resources checklist calls for Kubernetes 1.24 or later, Helm 3.14 or later, PostgreSQL 14 or later, Redis 6 or later, a Qdrant vector database and S3-compatible or cloud object storage. If your team lacks one of these, or lacks a test environment that mirrors production, a partner or Dify's own enterprise support path becomes the practical choice. Ask Dify which parts of the move they support directly.

A quote should separate the one-time work from the recurring spend. One-time items include inventory of the current Compose install, the Kubernetes cluster build or review, data migration planning and execution, SSO and SCIM configuration, validation and cutover. Recurring items include the Enterprise subscription, the cluster capacity that runs it, object storage, backups and ongoing support. Dify does not publish Enterprise pricing, so the subscription figure must come from Dify's quote. The Dify pricing page lists the self-hosted Enterprise edition as custom priced. Ask for each line item in writing and for the assumptions behind it, including the size of the vector data and the number of workspaces.

Duration depends on scope rather than on a standard number, so treat any fixed figure with caution. The main drivers are the number of workspaces and apps, the size of PostgreSQL, uploaded files and the vector store, how many knowledge bases need re-indexing, how many identity providers and roles must be configured, and how many change windows your organization allows. A small single-workspace instance with few knowledge bases is far quicker to move than a multi-team deployment with large document sets. Ask any provider to name the assumptions behind its timeline and to list which items depend on your change calendar.

Your team should provide four things. First, an inventory of workspaces, apps, knowledge bases, model provider credentials, plugins and API clients. Second, identity administration access to configure OpenID Connect, SAML or OAuth2 with your provider, and to map groups for SCIM. Third, cluster access, including namespaces, storage classes, ingress, secrets handling and network rules to reach model endpoints. Fourth, fixed change windows for the cutover and a named owner who can approve it. Without the inventory, scope cannot be priced accurately, so start there.

No, a single export is not enough. Dify apps can be exported and imported as YAML DSL files, which carry app configuration, workflow nodes, model parameters, prompts and knowledge base connections. The export does not include third-party API keys, knowledge base content or usage logs. That means provider credentials must be re-entered, knowledge base documents must be re-uploaded or re-indexed, and API clients must receive new keys where applicable. Confirm with Dify how workspace-level data, PostgreSQL and file storage are carried across for the Enterprise install, since the DSL export alone does not move them.

Confirm this with Dify before you schedule the cutover. The Community edition is free and limited to a single workspace, and the Dify Open Source License prohibits operating a multi-tenant environment without written authorization. Enterprise licensing is different. An Enterprise license is bound to the Kubernetes namespace, and that namespace must not change after activation. Activation can be online, or offline using a Cluster ID exchanged for an offline code. Plan the namespace name before activation, and ask Dify what happens to the Community instance once Enterprise is live, including whether it can be kept for rollback.

Keep the Community instance as the system of record until the Enterprise install passes validation. Run the Enterprise cluster alongside it on a separate namespace, load a copy of the database and file storage, and test apps, knowledge base retrieval and SSO login against the copy. Freeze or limit changes on the Community side during the final sync, then repeat the sync at cutover. Take a backup before each step, following the same discipline Dify recommends before every upgrade. Keep the Community host available for rollback until the business signs off, and remember that the Enterprise namespace cannot change once the license is activated.