Skip to main content

Community To Enterprise Migration

Most teams do not adopt AxonFlow in one step. They start in Community, prove that the control plane helps real workflows, then hit the moment where local validation is no longer enough.

This guide explains that transition in practical terms. It is written for engineers and platform teams who need to decide when to stay on Community, when to use Evaluation, and when Enterprise becomes the right operating model. If you have already decided, Moving a self-hosted Community deployment to Enterprise on v11 is the procedure.

The Three Stages​

Stage 1: Community​

Community is the best place to:

  • wire AxonFlow into one or two applications
  • validate SDK calls and request flows
  • test MCP connectors, policy enforcement, and orchestration
  • observe the control plane locally with Prometheus and Grafana

Stage 2: Evaluation​

Evaluation is the bridge from “it works on a laptop” to “we can run a serious pilot.” It raises limits and turns on selected governance features, including:

  • higher policy and provider limits
  • higher execution and SSE limits
  • policy simulation
  • evidence export

Stage 3: Enterprise​

Enterprise becomes the right answer when the organization needs:

  • portal-backed operations
  • human approval of workflow steps
  • identity and provisioning
  • broader enterprise connectors
  • Bedrock or custom provider operations
  • long retention and stronger operational guarantees

The Signals That You Have Outgrown Community​

Community is usually no longer enough when one or more of these are true:

  • more than two governed connector estates are needed
  • your team needs more than two configured providers
  • approval holds are part of the intended workflow, which needs Enterprise
  • a compliance or security team wants simulation and evidence, not just logs
  • the platform is moving from one engineer’s project to a shared internal service

That is the moment Evaluation becomes valuable. It is not only an upsell tier. It is the tier where production-readiness validation becomes realistic.

What Changes Operationally​

AreaCommunityEvaluationEnterprise
Policies your organization authors (typed)2050unlimited
LLM providers23unlimited
Pending approvalsn/a, no queuen/a, no queueunlimited
Policy simulationnoyes, limitedyes
Evidence exportnoyes, limitedyes
Protected portal workflowsnonoyes
Approval requirements and the HITL approval queueno: an approval requirement cannot be publishedno: an approval requirement cannot be publishedyes, 24h expiry, unlimited
Identity and SCIMnonoyes

A Practical Migration Pattern​

Community to Evaluation​

Move to Evaluation when the engineering team needs to prove:

  • governance changes can be simulated before rollout
  • the control plane still behaves well under a more realistic workload

This is usually the step that helps an engineer make the internal case for broader adoption.

Evaluation to Enterprise​

Move to Enterprise when the platform is no longer only an engineering experiment and becomes part of a real operating model:

  • shared across teams
  • workflow steps that need a human approval
  • connected to identity systems
  • expected to satisfy procurement and compliance review
  • expected to support broader connectors and provider operations

What Senior Engineers Usually Need To Tell Their Stakeholders​

At large organizations, the internal conversation is rarely “does the tool exist?” It is usually:

  • can we operate it responsibly?
  • can security review it?
  • can multiple teams share it?
  • can we route real business workflows through it without ad hoc glue?

Community proves the developer value. Evaluation proves production-readiness potential. Enterprise proves organizational fit.

Moving a self-hosted Community deployment to Enterprise on v11​

A self-hosted Community deployment runs the Docker Compose stack built from the public repository. Self-hosted Enterprise is a different deployment: the Enterprise install bundle, which pulls the Agent, Orchestrator, Customer Portal, Customer Portal UI, Prometheus and Grafana images by digest from a private registry. Moving between them is a new installation, not a licence key change.

  1. Plan what you keep. Nothing in the Community stack's database is carried into the new installation automatically. Policies you wrote on Community are re-authored as typed policies on Enterprise (see step 5). Keep an export of anything else you need, such as audit records, before you stop the old stack. If you would rather import your policies than re-author them, read Importing Legacy Policies into the Typed Model first: the import starts from a capture of the database that holds them, so take it while the Community stack still runs.
  2. Stop the Community stack before you start the bundle. Both bind the same host ports on 127.0.0.1 (5432, 6379, 8080, 8081 and 9090, and 3000, which is Grafana on Community and the Customer Portal on Enterprise), and the Community compose file gives every service a fixed container_name. docker compose -p does not separate host ports, so the two stacks cannot run side by side unchanged. Stop the Community stack (docker compose down in its directory), or change one stack's host ports if you need both running.
  3. Install the Enterprise bundle from your welcome bundle: authenticate to the registry, copy .env.example to .env, fill in the six image digests, your organization ID, licence key, database, Grafana and portal passwords and at least one LLM provider key, then run ./install.sh. The bundle's README is the procedure. Leave DEPLOYMENT_MODE as the bundle ships it.
  4. Do not carry your old .env across. v11 refuses to boot while certain retired variables are set, and an older .env may carry them; the v10 → v11 Migration Guide lists them. An unrecognised DEPLOYMENT_MODE also stops the platform at boot: the accepted values are community, community-saas, enterprise, evaluation, in-vpc-banking, in-vpc-enterprise, in-vpc-healthcare, in-vpc-travel, invpc and saas, matched exactly. The licence must carry an organization (org_id) or deployment (deployment_id) identifier, or v11 refuses to boot.
  5. Re-author or import your policies as typed policies. v11 decides from typed policy documents, and the legacy policy tables are read-only; see Your own legacy policies. On Enterprise, publish and promote in the customer portal (Typed Policy Authoring). A step that needs a human approval is an approval requirement.
  6. Point your clients at the new stack. The Enterprise bundle authenticates with HTTP Basic base64(AXONFLOW_ORG_ID:AXONFLOW_LICENSE_KEY). Use the client versions listed in the v11.0.0 release notes.

Operational Readiness Checklist​

Before relying on this page in a production rollout, pair it with the core operations docs:

Last updated on