Migrate from ConfigCat to Flagsmith

Migrate from ConfigCat to Flagsmith: what the move involves

A team that wants flag evaluation and flag data inside its own infrastructure and has chosen Flagsmith should expect the move to be an export, a rebuild of projects, environments, segments and remote config values in Flagsmith, an SDK swap in each application, and a parallel run before ConfigCat is switched off. Most of the risk sits in targeting rules and in client-side evaluation, where a rule that reads cleanly in one vendor's console can behave differently once it is recreated. Platform or application teams usually do the work, since they own the SDK calls and the release process. An implementation partner is useful for scoping the export, agreeing the target architecture and hardening the self-hosted Flagsmith deployment, but the application owners still have to confirm that each flag behaves as before.

Effort is driven less by the number of flags than by how many of them carry logic. Simple boolean switches and remote config values map across with little interpretation. Percentage rollouts, attribute-based rules and segments need a person to confirm the bucketing and the evaluation context each application sends. Because the self-hosted Flagsmith edition has no API request limits, the usual reason to rush the cutover disappears, which gives teams room to run both systems side by side for each application. Confirm with your own engineers which environments each service reads from, and whether any mobile or browser client caches flag values long enough to hide a change.

Before you start, decide who owns the Flagsmith environments after go-live, how the Helm chart and PostgreSQL will be operated, and which governance features your roles require. Some of those features, such as SAML single sign-on, role-based access control and audit logs, are Enterprise features in Flagsmith, so confirm them against the current Flagsmith pricing page and your compliance needs before you commit to a design. Plan the cutover as a series of applications rather than a single switch, and keep ConfigCat readable until every consumer has been verified against Flagsmith.

Which ConfigCat capabilities map to Flagsmith, and which need rework

This table compares the main ConfigCat capabilities with their closest Flagsmith equivalents and marks each row as clean, needs rework or gap. Use it to scope the migration, then check every row against your own ConfigCat products, configs and targeting rules before committing to a date. Most rows need a confirmation step, and the governance rows depend on which Flagsmith tier you choose.

Capability	ConfigCat	Flagsmith equivalent and status
Feature flags (boolean on/off)	Boolean feature flags per config and environment	Clean: Flagsmith features map to flags per environment. Confirm the on/off state of each flag in every environment after import.
Remote config values	Typed settings (string, number, boolean, JSON) per environment	Needs rework: Flagsmith features carry remote config values, but typed values and JSON payloads must be re-entered or checked by hand.
Products and configs	Products contain configs, which contain flags and settings	Needs rework: Flagsmith uses projects and environments, so ConfigCat products and configs must be mapped to a project structure you design.
Environments	Named environments within each config	Clean: Flagsmith environments hold per-environment flag states and keys. Recreate them and confirm SDK keys point to the right environment.
Segments and targeting rules	Targeting rules on user attributes, evaluated in order	Needs rework: Flagsmith segments and rules differ in rule ordering and operators. Test each targeted flag against sample users.
Percentage rollouts	Percentage options keyed on a user attribute	Needs rework: Flagsmith supports percentage-based values, but hashing and bucketing may move users. Plan for re-bucketing during rollout.
SDK evaluation	Client and server SDKs with local evaluation	Needs rework: Flagsmith SDKs evaluate flags differently in local and remote modes. Swap SDKs per service and test each one.
ConfigCat Proxy	Self-hosted proxy that caches config for local evaluation	Needs rework: Flagsmith Edge Proxy is optional and only needed for lower latency. Confirm your latency need before deploying it.
Governance: SSO, RBAC and audit logs	Team roles and audit history within your plan	Gap on Free and Start-Up: SAML, roles, permissions, change requests and audit logs start at the Scale-Up plan or Enterprise. Confirm scope with Flagsmith.

What data moves, what is rebuilt, and which exports are documented

A ConfigCat to Flagsmith move carries over flag definitions and targeting logic, but not everything in the account. Configuration is rebuilt by hand in Flagsmith, while history and audit records stay with ConfigCat unless you archive them first.

Exporting flags through the API

ConfigCat has no single bulk export, so flag definitions have to be read through its Public Management API, covering products, configs, environments, flags and targeting rules. Script the reads, store the raw responses, and keep a snapshot of each environment before the plan changes. Confirm with ConfigCat which fields the API returns for your plan and whether percentage rules and segments are included in full.

Rebuilding projects and environments

Flagsmith organizes work into projects, each with its own environments and flags. Map each ConfigCat product and config to a Flagsmith project, then recreate each environment such as development, staging and production. Naming and environment boundaries should be settled before any flag is created, because they determine which API keys and SDK keys each team uses.

Segments, remote config and targeting

Flag targeting in ConfigCat, including user attribute rules and percentage splits, must be translated into Flagsmith segments and feature overrides. Remote config values, which ConfigCat stores as settings, become Flagsmith feature values with their own per-environment overrides. Test each translated rule against known test users, since differences in how the two products evaluate percentages can change which users see a value.

API keys and SDK integrations

Each Flagsmith environment issues its own server-side and client-side keys, which replace the ConfigCat SDK keys in application configuration. Plan the swap environment by environment, and remove the ConfigCat SDK only after every service reads from Flagsmith. Check whether any ConfigCat Proxy or relay in your network needs an equivalent, and confirm with Flagsmith whether the Edge Proxy fits your latency and deployment needs.

History, audit logs and analytics

User history, audit logs and any evaluation analytics typically remain in ConfigCat and are not carried into Flagsmith by the flag definitions. Export what your auditors or change managers need while the account is active, and store it in your own retained archive. Confirm the retention window your ConfigCat plan provides before the subscription ends.

Tooling and importer checks

Do not assume an automated importer exists for ConfigCat. Flagsmith's documented built-in importer covers LaunchDarkly, not ConfigCat, so the ConfigCat move is a scripted export and rebuild. Ask Flagsmith in writing which migration tooling, if any, it supports for ConfigCat, and agree on who owns the script, the validation and the cutover checks.

How the migration sequence runs from inventory to decommission

The sequence moves ConfigCat flags into Flagsmith one low-risk flag and one service at a time, with a parallel run and recorded checks before ConfigCat is switched off. Each step produces a written artifact that the next step depends on.

Build the inventory of products, configs and flags
Working through the Public Management API, record every ConfigCat product, config, environment, flag, targeting rule, percentage option and remote config value, along with the SDK key and the services that call each one. Most teams keep this as a spreadsheet with one row per flag, showing its owner, default value, type and the code paths that evaluate it. The step is done when the inventory has been reviewed by the application owners and every flag is marked as migrate, retire or keep in ConfigCat for now. Ask your ConfigCat account team to confirm how the API handles your plan's limits before you run large reads.
Pilot one low-risk flag in a non-production environment
Pick one boolean flag with no segments and a clear owner, then recreate it in a Flagsmith development environment in a new or existing project. Confirm that the on and off state, default value and any remote config value match ConfigCat for the same test identities. The output is a short pilot report listing the flag, the environment, the SDK version used, the evaluation results compared and any differences found. Do not move to the next step until the team agrees the report explains every difference.
Recreate projects, environments, segments and remote config
Create the Flagsmith projects and environments that mirror your ConfigCat structure, then rebuild segments and targeting rules by hand from the inventory. Remote config values that hold JSON or text move into Flagsmith's remote config fields, and each environment gets its own server-side and client-side keys. If you use the built-in LaunchDarkly importer as a reference, remember that it is for LaunchDarkly, not ConfigCat, so this work is manual. The output is a configuration record per environment that a second engineer has checked against the inventory.
Swap SDKs in one service at a time
Replace the ConfigCat SDK with the Flagsmith SDK for one service, usually one with low traffic and a team that can respond quickly to issues. Keep the flag keys and default values in code identical so that only the client initialization and evaluation calls change. Check the Flagsmith SDK documentation for your language, and if you plan to use OpenFeature as the application-facing API, confirm that a Flagsmith provider exists for your stack before you commit. The step ends when the service runs in staging with the new SDK and its evaluation logs show the expected values.
Run both systems in parallel and compare results
While the service still reads from ConfigCat for production decisions, have it also evaluate each migrated flag against Flagsmith and log both results with a request identifier. Review mismatches daily, focusing on segments, percentage rollouts and any flag that depends on a user attribute that may be missing. Plan for users to be bucketed differently if hashing or identifiers differ between the two systems, and decide in advance whether that is acceptable for each flag. The output is a comparison report with each mismatch classified as a defect, an expected difference or an open question.
Cut over flag by flag or service by service
Move production reads for each flag or service to Flagsmith after its parallel-run report is clean. Use a change record per flag that names the owner, the rollback value, the time of the switch and the person who approved it. For percentage rollouts, record the expected share of users in each variation before and after the switch so that any shift can be explained. The output is a signed-off cutover checklist for each flag or service, kept with the inventory.
Decommission ConfigCat after the audit and export window
Before you cancel or downgrade ConfigCat, export the final flag definitions, targeting rules and audit history through the API, store them in your own records system, and confirm that your compliance owner accepts the retained copy. Revoke the ConfigCat SDK keys, remove the SDK from code, and confirm that no service still reads from it by checking logs for the old key over a period your team agrees. Ask your ConfigCat contact to confirm how long audit logs remain available after cancellation, since that window determines how much you need to export. The output is a decommission record that lists the revoked keys, the retained exports and the date ConfigCat was closed.

How Flagsmith's Kubernetes and database setup shapes the move

The first planning decision is the database. The official Flagsmith Helm chart, from the flagsmith/flagsmith chart published at flagsmith.github.io/flagsmith-charts, creates its own PostgreSQL server inside the cluster by default. That default is convenient for a test install but is not what the Flagsmith Kubernetes documentation recommends for production, where an externally managed PostgreSQL instance is the expected design. Before you copy any ConfigCat flags, decide who will own that database, who holds its backups and restore procedure, and whether your platform team already runs a managed PostgreSQL service you can point the chart at. The documentation also describes optional PgBouncer for connection pooling, so confirm with your DBA whether your database tier can absorb the connection pattern of the Flagsmith API and task workers during the import and the parallel-run period.

The rest of the stack adds components you will need to size and monitor. The self-hosting documentation describes Redis caching options and an asynchronous task processor for background work, so a production install is more than one web deployment and one database. Each of these has its own resource settings, failure modes and logs. The Edge Proxy is optional and only needed where lower latency matters for your SDK clients, so decide early whether your ConfigCat Proxy workloads actually require a replacement. For OpenShift, Flagsmith runs through its Helm charts, but the Flagsmith OpenShift Operator is supported only with an Enterprise plan. If your standard is OpenShift, plan to own the Helm-based deployment and its upgrades yourself, or price the Enterprise option into your comparison before the migration is scheduled.

For sizing, the practical step is a short load test of your own traffic profile against a staging install that mirrors the production database, Redis and worker layout. Ask the vendor or your DeployOpen scope lead which resource profile the documentation assumes, and confirm the current chart values for your chosen Flagsmith release, since the chart changes between releases. Record who is on call for each component, and agree in writing who handles chart upgrades, database minor versions and task queue backlogs. Those ownership decisions, more than the software itself, determine whether the move stays on schedule.

What drives migration cost and duration, and how to keep each down

This table lists the main drivers of effort in a ConfigCat to Flagsmith move, why each one changes the bill, and how to reduce it. Read it before writing a scope, because the drivers you confirm in the inventory decide most of the one-time work, while hosting and upgrades set the recurring cost.

Driver	Why it changes cost or effort	How to keep it down
Number of flags and environments	Each flag needs its state, variations and defaults checked in Flagsmith, and each ConfigCat environment must map to a Flagsmith environment. Inventory, rebuild and verification time grow with both counts.	Retire stale flags in ConfigCat before export, archive deprecated flags, and migrate only the flags that code still evaluates.
Depth of targeting rules and segments	Nested targeting rules and percentage options need manual translation into Flagsmith segments and rule conditions. Complex rules are the most common source of rework during testing.	Simplify rules where the business intent allows, and document each rule's expected result so testers can compare both systems.
Remote config values	Config values that carry application settings, not just on and off states, need their types and defaults recreated and each consuming service retested. Flagsmith's importer does not cover every ConfigCat setting, so confirm what transfers.	Group remote config by owning service, and check each value against the code that reads it before cutover.
Number of SDKs and services	Every service, language and client SDK in use needs its ConfigCat integration replaced with a Flagsmith or OpenFeature-based call and a regression test. Cost rises with each runtime, not with each flag.	Inventory SDK use early, standardize on fewer runtimes where possible, and consider OpenFeature so future provider changes touch less code.
SAML or RBAC needs on Flagsmith Enterprise	Flagsmith's FAQ states that SAML single sign-on and RBAC are Enterprise Edition features. Governance features such as roles, change requests and audit logs start at the Scale-Up plan on the Flagsmith pricing page. Requiring them adds a licensing decision and a configuration task.	Confirm in writing which access and approval controls are mandatory, then choose between the free edition with process controls and a paid plan. Ask Flagsmith for current plan terms before fixing the scope.
Production database and Kubernetes design	The Flagsmith Helm chart creates its own PostgreSQL server by default, while the docs recommend an externally managed database in production. Choosing and hardening that database, backups and any PgBouncer layer is additional one-time work and an ongoing operating cost.	Decide early whether the database is a managed service in your cloud or an existing internal platform, and include backup and restore tests in the scope.
Length of the parallel run	Running ConfigCat and Flagsmith side by side means two systems to keep consistent, two sets of evaluations to compare and two sets of charges until ConfigCat is cancelled. The longer the overlap, the higher the cost.	Set exit criteria for the parallel run in writing, such as flag evaluation parity checks, and confirm the ConfigCat plan end date before cutover.
Upgrades on the v2.286.0 release line	Flagsmith v2.286.0 was released on October 15, 2026, according to the Flagsmith GitHub releases page. Self-hosted upgrades, Helm chart changes and database migrations recur for as long as you run the platform, and each one needs regression testing.	Pin chart and image versions, test upgrades in a non-production environment, and ask for an upgrade procedure as a deliverable.

What usually goes wrong and how to prevent it

Most failed ConfigCat-to-Flagsmith moves fail on details rather than on the platform itself: rules that look equivalent but are not, data that gets overwritten, and assumptions about what the open-source edition includes. Each card below names one risk and a prevention step you can check before cutover.

Targeting rules that do not translate exactly

ConfigCat targeting conditions, percentage options and segment logic do not map one to one onto Flagsmith segments and feature overrides. A rule that reads correctly in one tool can match a different set of users in the other, especially around attribute types, case sensitivity and missing attributes. Export each ConfigCat rule, recreate it in Flagsmith, and test it against a fixed list of sample users covering every branch before you switch traffic.

Client-side evaluation drift in parallel runs

During a parallel run, the SDK in each application evaluates flags locally, so two platforms can disagree for the same user if their identifiers, hashing or percentage bucketing differ. Percentage rollouts are the most likely place for users to flip between variants when you change platforms. Log the flag value each platform returns for a shared test set of identifiers, and agree in writing which platform is authoritative for each flag during the overlap.

Importers that overwrite existing data

Built-in importers in other flag platforms document that they overwrite existing environments and flags in the target project. ConfigCat import support is not documented, so treat any importer or script you use as a general overwrite risk. Point the import at an empty Flagsmith project in a non-production instance first, and confirm in writing what each step replaces before running it against a project that already holds flags.

Missing environment-specific keys

ConfigCat products hold separate SDK keys for each environment, and applications often read the wrong key after a copy-paste or config change. In Flagsmith, each environment has its own server-side and client-side keys, so a flag that is correct in staging can be missing or stale in production. Build an inventory of every key in every service, replace them in one change per environment, and check each environment's flag list after cutover.

Running without an external database

The official Flagsmith Helm chart creates its own PostgreSQL server in the cluster by default. Flagsmith's Kubernetes documentation recommends an externally managed database for production, with optional PgBouncer. Teams that keep the default database often discover late that backups, failover and upgrades are now their responsibility. Decide the database owner, backup schedule and restore test before go-live, and document them in the runbook.

Assuming Enterprise features are included

The open-source edition of Flagsmith is mostly BSD 3-Clause licensed, but SAML single sign-on, role-based access control, change requests and audit logs sit in the closed-source Enterprise edition. Teams that rely on those controls for compliance may find they are missing after migration. List every control your ConfigCat setup uses today, then confirm each one against the open-source feature set or budget for the licensed edition.

Decommissioning before audit logs are exported

Switching off the ConfigCat account before exporting its change history removes the record of who changed which flag and when. Those records matter for internal reviews and for assessors who ask how a control changed over time. Export the audit log and product configuration to your own storage, verify that the files open and contain the expected entries, and only then cancel the plan.

How the migration differs by team size and starting point

A small team with a handful of flags, one product and a single environment set usually has the simplest migration. The work is mostly recreating flag definitions by hand or with a short script, confirming that each SDK call still returns the expected value, and retiring the ConfigCat keys. Because the surface is small, a short parallel run is often enough, and the main question is who will run the server after go-live.

Scope: one Flagsmith project and a few environments, with flags recreated from the ConfigCat export.
Parallel run: a short window where both services return the same values for a test cohort before the old keys are removed.
Governance: Flagsmith's free edition has no role-based access control or audit logs, so changes rely on team discipline.
Hosting: a single Docker Compose host may be enough, but the team must own backups and upgrades.
Hidden cost: one person becomes the operator, which is a recurring cost even if the software is free.

Check the Flagsmith pricing page for the request and team member limits that apply to your plan before you commit to a hosting model.

Questions teams ask before moving from ConfigCat to Flagsmith

How much effort and cost does a ConfigCat to Flagsmith migration involve?

The cost is mostly labor, plus the running cost of the Flagsmith server you choose to host. The main drivers are how many projects, environments and flags you have, how many targeting rules and segments need to be rebuilt by hand, how many SDKs your services use, and whether Flagsmith is hosted in your own cluster or on Flagsmith's cloud. One-time work covers export, rebuild, SDK changes and testing. Recurring costs cover hosting, a PostgreSQL database, backups and upgrades. Flagsmith's free tier is limited to 50,000 requests per month, according to the Flagsmith pricing page, so request volume matters if you use the hosted service. Ask any partner for a written scope that lists each project, environment and SDK included, along with who owns the hosting after handover.

How long does the migration take, and what sets the timeline?

The timeline depends on the size of your ConfigCat estate and how much of it needs manual rebuilding. Flagsmith's built-in importer is documented for LaunchDarkly, not ConfigCat, so ConfigCat flags are usually exported through its Public Management API and recreated in Flagsmith by hand or by script. Expect the schedule to be set by the number of products, configs, environments and targeting rules, the number of services that must change SDKs, the need to run both systems in parallel, and any change freeze in your release calendar. Ask for milestones in the written scope so you can see where the schedule could slip.

What does the migration need from our own staff?

Your team needs to supply access and decisions that only your organization can make. Typically this includes a ConfigCat account owner who can create a Public Management API token, engineers who know which flags gate which code paths, product owners who confirm targeting rules and rollout percentages, and someone who can approve SDK changes in each service. Platform or infrastructure staff are needed if Flagsmith will run in your Kubernetes cluster, since its Helm chart creates its own PostgreSQL server by default and the documentation recommends an externally managed database in production. Confirm these named roles in the scope before work starts.

Can our internal team do the migration without a partner?

Yes, an internal team can run the migration if it has engineers who can call an API, write a mapping script, deploy Flagsmith and change SDK calls, and if it has time to test each flag. Flagsmith's documentation is public, and its open-source edition has no API request limits, according to its FAQ. A partner adds value when the estate is large, when the rebuild must be tested against production traffic, or when hosting, backup, upgrades and security hardening must be run to a documented standard. DeployOpen plans, implements, hardens, backs up, upgrades and documents self-hosted platforms in your own infrastructure, and works from a fixed scope agreed in writing.

Does the open-source edition cover our needs, or do we need Enterprise features?

The open-source edition covers flags, remote config and segments for many teams, and Flagsmith's FAQ states that its self-hosted version has no API request limits. The Enterprise features are the ones to check. According to Flagsmith's FAQ and pricing page, SAML single sign-on, role-based access control, change requests and audit logs require an Enterprise edition or the Scale-Up plan, and SAML and Okta are not configured out of the box for LDAP. Also note that Flagsmith's Kubernetes OpenShift Operator support is limited to Enterprise. List the access controls and approval workflows you currently rely on in ConfigCat, then compare them against the Flagsmith edition you plan to run before you commit.

What happens to our ConfigCat audit history during the move?

Audit history stays in ConfigCat and does not move automatically with the flags. Before the plan ends or access is reduced, export the records you need for compliance, incident review or change tracking, and keep them in your own retention system. Check the retention window that applies to your ConfigCat plan, because older entries may not be available later. Flagsmith's audit logs are an Enterprise feature according to its pricing page, so an open-source deployment will need a separate record of changes made in Flagsmith from the first day. Ask your compliance lead which evidence an assessor will need, and confirm the approach with them and with your auditor.

What changes for your engineers and operators after cutover

The biggest shift after cutover is that someone on your team now operates the flag service. ConfigCat handled hosting, upgrades, uptime and database work for you. With self-hosted Flagsmith, your platform team owns the container images or the Helm release, the PostgreSQL instance behind it, the Redis caching layer, the asynchronous task processor, and any optional Edge Proxies. Decide before cutover who is on call for flag evaluation outages, who approves upgrades, and who owns the backup schedule. The Flagsmith Kubernetes documentation notes that the Helm chart creates its own PostgreSQL server by default and recommends an externally managed database in production, so confirm which option your design uses and who restores it if it fails.

Operators also inherit monitoring for the API and any Edge Proxy tier that sits between your services and Flagsmith. Set alerts on API availability, latency and error rates, on database connections and storage, and on the freshness of environment data that SDKs receive. Your team also takes over SDK key management. Each Flagsmith environment issues keys that server and client SDKs use, so define who can create, rotate and revoke them, where they are stored (for example, in your existing secrets manager), and how a leaked key is replaced without a release. Governance features such as roles, change requests and audit logs are Enterprise features on Flagsmith's pricing page, so confirm whether your access controls depend on them before you rely on the open-source edition.

For application engineers, the expected change is narrow: replacing the ConfigCat SDK initialization and key configuration with Flagsmith equivalents, plus any calls that read flags or remote config values. Flag evaluation logic, targeting and segments should be defined in Flagsmith, not in application code. Whether that holds for every service depends on the SDK language and on how each service caches and evaluates flags, so run a per-SDK review and a staging test before you change production. Plan a regression pass on flag-dependent code paths, because the importer copies boolean states and multivariate values but teams should still verify them by hand.

How DeployOpen scopes, runs and supports this migration

DeployOpen plans and implements the move from ConfigCat to a self-hosted Flagsmith in your own infrastructure, starting from a written scope. The work covers exporting flag definitions, recreating projects, environments, segments and remote config values, swapping SDKs and checking the result before cutover.

How we scope

Inventory every ConfigCat product, environment, flag and remote config value in use today.
Map each targeting rule and segment to its Flagsmith equivalent, and record which need manual rebuilding.
Confirm whether the Flagsmith Edge Proxy or Enterprise features such as SAML and RBAC are in the written scope.
Agree deliverables, timelines and acceptance checks in writing before any migration work starts.

How we build

Deploy Flagsmith with Docker Compose or the official Helm chart, using an externally managed PostgreSQL database.
Recreate projects, environments and segments, then verify flag states against the ConfigCat source.
Swap SDKs in each application and test flag evaluation in staging before production rollout.
Run security checks on the deployment, access controls and API keys as part of the build.

How we hand over

Document the deployment, configuration, environment layout and the flag inventory with owners.
Provide a cutover runbook with rollback steps and a checklist for the ConfigCat plan end date.
Walk through the reconciliation evidence so your team can review the migrated flags by hand.
Confirm which archived or deprecated ConfigCat flags were retained, retired or left out.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after handover.
Retainers can cover Flagsmith version upgrades, such as tracking releases on the project's GitHub page.
Ask for the support model, response expectations and upgrade process in the written quote.

Migrate from ConfigCat to Flagsmith